From 3a5ec581a2717fea32322bbd7fb05f19e774ebe3 Mon Sep 17 00:00:00 2001 From: Carlos Holguera Date: Sat, 18 Jul 2026 17:54:25 +0200 Subject: [PATCH 01/70] minor fixes --- weaknesses/MASVS-CRYPTO/MASWE-0014.md | 4 ++-- weaknesses/MASVS-PLATFORM/MASWE-0065.md | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0014.md b/weaknesses/MASVS-CRYPTO/MASWE-0014.md index 1440d84..5ff7f5a 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0014.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0014.md @@ -31,8 +31,8 @@ Attackers can decompile or reverse-engineer the app to extract hardcoded keys. ## Modes of Introduction - **Insecure Storage Locations**: Storing cryptographic keys in locations that are not designed for secure storage, such as regular configuration or user preferences files, application data directories, or other areas lacking encryption and access control mechanisms. -- **Hardcoded Keys**: Including cryptographic keys directly in the application code, making them susceptible to extraction through decompilation and reverse-engineering. -- **Lack of Encryption**: Exporting cryptographic keys in plain text without encrypting them using a secure method. +- **Hardcoded Cryptographic Keys**: Including cryptographic keys directly in the application code, making them susceptible to extraction through decompilation and reverse-engineering. +- **Insecure Imported Keys**: Importing cryptographic keys from untrusted sources or without validating their integrity, which can lead to the introduction of malicious or compromised keys into the application environment. ## Mitigations diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0065.md b/weaknesses/MASVS-PLATFORM/MASWE-0065.md index 5f0b2c2..481adb0 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0065.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0065.md @@ -22,7 +22,7 @@ draft: - content providers - FLAG_GRANT_READ_URI_PERMISSION - FLAG_GRANT_WRITE_URI_PERMISSION - - FLAG_GRANT_PERSISTABLE + - FLAG_GRANT_PERSISTABLE_URI_PERMISSION - content URIs - file URIs status: placeholder From 93f0d957a73ee12d999526e715877b81e2729589 Mon Sep 17 00:00:00 2001 From: Carlos Holguera Date: Sun, 19 Jul 2026 10:33:57 +0200 Subject: [PATCH 02/70] full refactor --- weaknesses/MASVS-AUTH/MASWE-0005.md | 47 -------------- weaknesses/MASVS-AUTH/MASWE-0017.md | 36 +++++++++++ weaknesses/MASVS-AUTH/MASWE-0018.md | 33 ++++++++++ weaknesses/MASVS-AUTH/MASWE-0019.md | 43 +++++++++++++ weaknesses/MASVS-AUTH/MASWE-0020.md | 51 +++++++++++++++ weaknesses/MASVS-AUTH/MASWE-0021.md | 40 ++++++++++++ .../{MASWE-0045.md => MASWE-0022.md} | 3 +- .../{MASWE-0046.md => MASWE-0023.md} | 3 +- weaknesses/MASVS-AUTH/MASWE-0024.md | 41 ++++++++++++ weaknesses/MASVS-AUTH/MASWE-0028.md | 24 ------- weaknesses/MASVS-AUTH/MASWE-0029.md | 31 --------- weaknesses/MASVS-AUTH/MASWE-0030.md | 27 -------- weaknesses/MASVS-AUTH/MASWE-0031.md | 20 ------ weaknesses/MASVS-AUTH/MASWE-0032.md | 37 ----------- weaknesses/MASVS-AUTH/MASWE-0033.md | 34 ---------- weaknesses/MASVS-AUTH/MASWE-0034.md | 14 ----- weaknesses/MASVS-AUTH/MASWE-0035.md | 34 ---------- weaknesses/MASVS-AUTH/MASWE-0036.md | 26 -------- weaknesses/MASVS-AUTH/MASWE-0037.md | 21 ------- weaknesses/MASVS-AUTH/MASWE-0038.md | 27 -------- weaknesses/MASVS-AUTH/MASWE-0039.md | 22 ------- weaknesses/MASVS-AUTH/MASWE-0040.md | 21 ------- weaknesses/MASVS-AUTH/MASWE-0041.md | 23 ------- weaknesses/MASVS-AUTH/MASWE-0042.md | 24 ------- weaknesses/MASVS-AUTH/MASWE-0043.md | 20 ------ weaknesses/MASVS-AUTH/MASWE-0044.md | 27 -------- weaknesses/MASVS-CODE/MASWE-0040.md | 26 ++++++++ .../{MASWE-0076.md => MASWE-0041.md} | 5 +- weaknesses/MASVS-CODE/MASWE-0042.md | 28 +++++++++ .../{MASWE-0078.md => MASWE-0043.md} | 3 +- weaknesses/MASVS-CODE/MASWE-0044.md | 28 +++++++++ .../{MASWE-0116.md => MASWE-0045.md} | 3 +- weaknesses/MASVS-CODE/MASWE-0046.md | 33 ++++++++++ weaknesses/MASVS-CODE/MASWE-0047.md | 45 +++++++++++++ weaknesses/MASVS-CODE/MASWE-0048.md | 48 ++++++++++++++ weaknesses/MASVS-CODE/MASWE-0075.md | 34 ++++++---- weaknesses/MASVS-CODE/MASWE-0077.md | 29 ++++++--- weaknesses/MASVS-CODE/MASWE-0079.md | 18 ------ weaknesses/MASVS-CODE/MASWE-0080.md | 21 ------- weaknesses/MASVS-CODE/MASWE-0081.md | 20 ------ weaknesses/MASVS-CODE/MASWE-0082.md | 27 -------- weaknesses/MASVS-CODE/MASWE-0083.md | 22 ------- weaknesses/MASVS-CODE/MASWE-0084.md | 22 ------- weaknesses/MASVS-CODE/MASWE-0085.md | 19 ------ weaknesses/MASVS-CODE/MASWE-0086.md | 21 ------- weaknesses/MASVS-CODE/MASWE-0087.md | 19 ------ weaknesses/MASVS-CODE/MASWE-0088.md | 28 --------- weaknesses/MASVS-CRYPTO/MASWE-0007.md | 48 ++++++++++++++ weaknesses/MASVS-CRYPTO/MASWE-0008.md | 35 +++++++++++ weaknesses/MASVS-CRYPTO/MASWE-0009.md | 54 +++++++--------- weaknesses/MASVS-CRYPTO/MASWE-0010.md | 41 +++++++++--- weaknesses/MASVS-CRYPTO/MASWE-0011.md | 55 ++++++++++++---- weaknesses/MASVS-CRYPTO/MASWE-0012.md | 33 ++++++---- weaknesses/MASVS-CRYPTO/MASWE-0013.md | 38 ++++++++--- weaknesses/MASVS-CRYPTO/MASWE-0014.md | 61 ++++++++---------- weaknesses/MASVS-CRYPTO/MASWE-0015.md | 31 +++++---- weaknesses/MASVS-CRYPTO/MASWE-0016.md | 58 ++++++++++------- weaknesses/MASVS-CRYPTO/MASWE-0017.md | 25 -------- weaknesses/MASVS-CRYPTO/MASWE-0018.md | 36 ----------- weaknesses/MASVS-CRYPTO/MASWE-0019.md | 56 ----------------- weaknesses/MASVS-CRYPTO/MASWE-0020.md | 44 ------------- weaknesses/MASVS-CRYPTO/MASWE-0021.md | 25 -------- weaknesses/MASVS-CRYPTO/MASWE-0022.md | 27 -------- weaknesses/MASVS-CRYPTO/MASWE-0023.md | 51 --------------- weaknesses/MASVS-CRYPTO/MASWE-0024.md | 33 ---------- weaknesses/MASVS-CRYPTO/MASWE-0025.md | 23 ------- weaknesses/MASVS-CRYPTO/MASWE-0026.md | 22 ------- weaknesses/MASVS-CRYPTO/MASWE-0027.md | 41 ------------ .../{MASWE-0050.md => MASWE-0025.md} | 12 ++-- .../{MASWE-0052.md => MASWE-0026.md} | 3 +- .../{MASWE-0047.md => MASWE-0027.md} | 3 +- weaknesses/MASVS-NETWORK/MASWE-0048.md | 22 ------- weaknesses/MASVS-NETWORK/MASWE-0049.md | 38 ----------- weaknesses/MASVS-NETWORK/MASWE-0051.md | 39 ------------ weaknesses/MASVS-PLATFORM/MASWE-0028.md | 28 +++++++++ weaknesses/MASVS-PLATFORM/MASWE-0029.md | 25 ++++++++ .../{MASWE-0055.md => MASWE-0030.md} | 3 +- weaknesses/MASVS-PLATFORM/MASWE-0031.md | 31 +++++++++ .../{MASWE-0058.md => MASWE-0032.md} | 3 +- weaknesses/MASVS-PLATFORM/MASWE-0033.md | 35 +++++++++++ .../{MASWE-0061.md => MASWE-0034.md} | 5 +- weaknesses/MASVS-PLATFORM/MASWE-0035.md | 36 +++++++++++ weaknesses/MASVS-PLATFORM/MASWE-0036.md | 30 +++++++++ weaknesses/MASVS-PLATFORM/MASWE-0037.md | 34 ++++++++++ weaknesses/MASVS-PLATFORM/MASWE-0038.md | 32 ++++++++++ weaknesses/MASVS-PLATFORM/MASWE-0039.md | 34 ++++++++++ weaknesses/MASVS-PLATFORM/MASWE-0053.md | 22 ------- weaknesses/MASVS-PLATFORM/MASWE-0054.md | 19 ------ weaknesses/MASVS-PLATFORM/MASWE-0056.md | 24 ------- weaknesses/MASVS-PLATFORM/MASWE-0057.md | 22 ------- weaknesses/MASVS-PLATFORM/MASWE-0059.md | 19 ------ weaknesses/MASVS-PLATFORM/MASWE-0060.md | 21 ------- weaknesses/MASVS-PLATFORM/MASWE-0062.md | 27 -------- weaknesses/MASVS-PLATFORM/MASWE-0063.md | 26 -------- weaknesses/MASVS-PLATFORM/MASWE-0064.md | 30 --------- weaknesses/MASVS-PLATFORM/MASWE-0065.md | 31 --------- weaknesses/MASVS-PLATFORM/MASWE-0066.md | 31 --------- weaknesses/MASVS-PLATFORM/MASWE-0068.md | 21 ------- weaknesses/MASVS-PLATFORM/MASWE-0069.md | 24 ------- weaknesses/MASVS-PLATFORM/MASWE-0070.md | 17 ----- weaknesses/MASVS-PLATFORM/MASWE-0071.md | 23 ------- weaknesses/MASVS-PLATFORM/MASWE-0072.md | 24 ------- weaknesses/MASVS-PLATFORM/MASWE-0073.md | 22 ------- weaknesses/MASVS-PLATFORM/MASWE-0074.md | 21 ------- weaknesses/MASVS-PLATFORM/MASWE-0118.md | 63 ------------------- weaknesses/MASVS-PLATFORM/MASWE-0119.md | 23 ------- .../{MASWE-0109.md => MASWE-0065.md} | 5 +- .../{MASWE-0110.md => MASWE-0066.md} | 6 +- .../{MASWE-0111.md => MASWE-0067.md} | 3 +- .../{MASWE-0112.md => MASWE-0068.md} | 8 ++- .../{MASWE-0113.md => MASWE-0069.md} | 3 +- .../{MASWE-0114.md => MASWE-0070.md} | 4 +- .../{MASWE-0115.md => MASWE-0071.md} | 7 ++- .../{MASWE-0117.md => MASWE-0072.md} | 4 +- weaknesses/MASVS-PRIVACY/MASWE-0073.md | 34 ++++++++++ weaknesses/MASVS-PRIVACY/MASWE-0074.md | 43 +++++++++++++ weaknesses/MASVS-PRIVACY/MASWE-0108.md | 45 ------------- .../{MASWE-0008.md => MASWE-0049.md} | 3 +- .../{MASWE-0067.md => MASWE-0050.md} | 15 +++-- weaknesses/MASVS-RESILIENCE/MASWE-0051.md | 25 ++++++++ .../{MASWE-0090.md => MASWE-0052.md} | 3 +- .../{MASWE-0091.md => MASWE-0053.md} | 3 +- weaknesses/MASVS-RESILIENCE/MASWE-0054.md | 39 ++++++++++++ weaknesses/MASVS-RESILIENCE/MASWE-0055.md | 28 +++++++++ .../{MASWE-0097.md => MASWE-0056.md} | 10 +-- .../{MASWE-0098.md => MASWE-0057.md} | 3 +- .../{MASWE-0099.md => MASWE-0058.md} | 10 +-- .../{MASWE-0100.md => MASWE-0059.md} | 3 +- .../{MASWE-0101.md => MASWE-0060.md} | 3 +- .../{MASWE-0102.md => MASWE-0061.md} | 3 +- weaknesses/MASVS-RESILIENCE/MASWE-0062.md | 40 ++++++++++++ .../{MASWE-0105.md => MASWE-0063.md} | 5 +- .../{MASWE-0107.md => MASWE-0064.md} | 8 ++- weaknesses/MASVS-RESILIENCE/MASWE-0076.md | 32 ++++++++++ weaknesses/MASVS-RESILIENCE/MASWE-0089.md | 23 ------- weaknesses/MASVS-RESILIENCE/MASWE-0092.md | 18 ------ weaknesses/MASVS-RESILIENCE/MASWE-0093.md | 19 ------ weaknesses/MASVS-RESILIENCE/MASWE-0094.md | 22 ------- weaknesses/MASVS-RESILIENCE/MASWE-0095.md | 20 ------ weaknesses/MASVS-RESILIENCE/MASWE-0096.md | 21 ------- weaknesses/MASVS-RESILIENCE/MASWE-0103.md | 18 ------ weaknesses/MASVS-RESILIENCE/MASWE-0104.md | 28 --------- weaknesses/MASVS-RESILIENCE/MASWE-0106.md | 18 ------ weaknesses/MASVS-STORAGE/MASWE-0001.md | 1 + weaknesses/MASVS-STORAGE/MASWE-0002.md | 55 +++++++++------- weaknesses/MASVS-STORAGE/MASWE-0003.md | 60 +++++++++++++----- weaknesses/MASVS-STORAGE/MASWE-0004.md | 56 ++++++++++------- weaknesses/MASVS-STORAGE/MASWE-0005.md | 46 ++++++++++++++ weaknesses/MASVS-STORAGE/MASWE-0006.md | 60 +++++++++++------- weaknesses/MASVS-STORAGE/MASWE-0007.md | 51 --------------- 150 files changed, 1626 insertions(+), 2273 deletions(-) delete mode 100644 weaknesses/MASVS-AUTH/MASWE-0005.md create mode 100644 weaknesses/MASVS-AUTH/MASWE-0017.md create mode 100644 weaknesses/MASVS-AUTH/MASWE-0018.md create mode 100644 weaknesses/MASVS-AUTH/MASWE-0019.md create mode 100644 weaknesses/MASVS-AUTH/MASWE-0020.md create mode 100644 weaknesses/MASVS-AUTH/MASWE-0021.md rename weaknesses/MASVS-AUTH/{MASWE-0045.md => MASWE-0022.md} (94%) rename weaknesses/MASVS-AUTH/{MASWE-0046.md => MASWE-0023.md} (95%) create mode 100644 weaknesses/MASVS-AUTH/MASWE-0024.md delete mode 100644 weaknesses/MASVS-AUTH/MASWE-0028.md delete mode 100644 weaknesses/MASVS-AUTH/MASWE-0029.md delete mode 100644 weaknesses/MASVS-AUTH/MASWE-0030.md delete mode 100644 weaknesses/MASVS-AUTH/MASWE-0031.md delete mode 100644 weaknesses/MASVS-AUTH/MASWE-0032.md delete mode 100644 weaknesses/MASVS-AUTH/MASWE-0033.md delete mode 100644 weaknesses/MASVS-AUTH/MASWE-0034.md delete mode 100644 weaknesses/MASVS-AUTH/MASWE-0035.md delete mode 100644 weaknesses/MASVS-AUTH/MASWE-0036.md delete mode 100644 weaknesses/MASVS-AUTH/MASWE-0037.md delete mode 100644 weaknesses/MASVS-AUTH/MASWE-0038.md delete mode 100644 weaknesses/MASVS-AUTH/MASWE-0039.md delete mode 100644 weaknesses/MASVS-AUTH/MASWE-0040.md delete mode 100644 weaknesses/MASVS-AUTH/MASWE-0041.md delete mode 100644 weaknesses/MASVS-AUTH/MASWE-0042.md delete mode 100644 weaknesses/MASVS-AUTH/MASWE-0043.md delete mode 100644 weaknesses/MASVS-AUTH/MASWE-0044.md create mode 100644 weaknesses/MASVS-CODE/MASWE-0040.md rename weaknesses/MASVS-CODE/{MASWE-0076.md => MASWE-0041.md} (99%) create mode 100644 weaknesses/MASVS-CODE/MASWE-0042.md rename weaknesses/MASVS-CODE/{MASWE-0078.md => MASWE-0043.md} (93%) create mode 100644 weaknesses/MASVS-CODE/MASWE-0044.md rename weaknesses/MASVS-CODE/{MASWE-0116.md => MASWE-0045.md} (97%) create mode 100644 weaknesses/MASVS-CODE/MASWE-0046.md create mode 100644 weaknesses/MASVS-CODE/MASWE-0047.md create mode 100644 weaknesses/MASVS-CODE/MASWE-0048.md delete mode 100644 weaknesses/MASVS-CODE/MASWE-0079.md delete mode 100644 weaknesses/MASVS-CODE/MASWE-0080.md delete mode 100644 weaknesses/MASVS-CODE/MASWE-0081.md delete mode 100644 weaknesses/MASVS-CODE/MASWE-0082.md delete mode 100644 weaknesses/MASVS-CODE/MASWE-0083.md delete mode 100644 weaknesses/MASVS-CODE/MASWE-0084.md delete mode 100644 weaknesses/MASVS-CODE/MASWE-0085.md delete mode 100644 weaknesses/MASVS-CODE/MASWE-0086.md delete mode 100644 weaknesses/MASVS-CODE/MASWE-0087.md delete mode 100644 weaknesses/MASVS-CODE/MASWE-0088.md create mode 100644 weaknesses/MASVS-CRYPTO/MASWE-0007.md create mode 100644 weaknesses/MASVS-CRYPTO/MASWE-0008.md delete mode 100644 weaknesses/MASVS-CRYPTO/MASWE-0017.md delete mode 100644 weaknesses/MASVS-CRYPTO/MASWE-0018.md delete mode 100644 weaknesses/MASVS-CRYPTO/MASWE-0019.md delete mode 100644 weaknesses/MASVS-CRYPTO/MASWE-0020.md delete mode 100644 weaknesses/MASVS-CRYPTO/MASWE-0021.md delete mode 100644 weaknesses/MASVS-CRYPTO/MASWE-0022.md delete mode 100644 weaknesses/MASVS-CRYPTO/MASWE-0023.md delete mode 100644 weaknesses/MASVS-CRYPTO/MASWE-0024.md delete mode 100644 weaknesses/MASVS-CRYPTO/MASWE-0025.md delete mode 100644 weaknesses/MASVS-CRYPTO/MASWE-0026.md delete mode 100644 weaknesses/MASVS-CRYPTO/MASWE-0027.md rename weaknesses/MASVS-NETWORK/{MASWE-0050.md => MASWE-0025.md} (90%) rename weaknesses/MASVS-NETWORK/{MASWE-0052.md => MASWE-0026.md} (99%) rename weaknesses/MASVS-NETWORK/{MASWE-0047.md => MASWE-0027.md} (99%) delete mode 100644 weaknesses/MASVS-NETWORK/MASWE-0048.md delete mode 100644 weaknesses/MASVS-NETWORK/MASWE-0049.md delete mode 100644 weaknesses/MASVS-NETWORK/MASWE-0051.md create mode 100644 weaknesses/MASVS-PLATFORM/MASWE-0028.md create mode 100644 weaknesses/MASVS-PLATFORM/MASWE-0029.md rename weaknesses/MASVS-PLATFORM/{MASWE-0055.md => MASWE-0030.md} (98%) create mode 100644 weaknesses/MASVS-PLATFORM/MASWE-0031.md rename weaknesses/MASVS-PLATFORM/{MASWE-0058.md => MASWE-0032.md} (95%) create mode 100644 weaknesses/MASVS-PLATFORM/MASWE-0033.md rename weaknesses/MASVS-PLATFORM/{MASWE-0061.md => MASWE-0034.md} (84%) create mode 100644 weaknesses/MASVS-PLATFORM/MASWE-0035.md create mode 100644 weaknesses/MASVS-PLATFORM/MASWE-0036.md create mode 100644 weaknesses/MASVS-PLATFORM/MASWE-0037.md create mode 100644 weaknesses/MASVS-PLATFORM/MASWE-0038.md create mode 100644 weaknesses/MASVS-PLATFORM/MASWE-0039.md delete mode 100644 weaknesses/MASVS-PLATFORM/MASWE-0053.md delete mode 100644 weaknesses/MASVS-PLATFORM/MASWE-0054.md delete mode 100644 weaknesses/MASVS-PLATFORM/MASWE-0056.md delete mode 100644 weaknesses/MASVS-PLATFORM/MASWE-0057.md delete mode 100644 weaknesses/MASVS-PLATFORM/MASWE-0059.md delete mode 100644 weaknesses/MASVS-PLATFORM/MASWE-0060.md delete mode 100644 weaknesses/MASVS-PLATFORM/MASWE-0062.md delete mode 100644 weaknesses/MASVS-PLATFORM/MASWE-0063.md delete mode 100644 weaknesses/MASVS-PLATFORM/MASWE-0064.md delete mode 100644 weaknesses/MASVS-PLATFORM/MASWE-0065.md delete mode 100644 weaknesses/MASVS-PLATFORM/MASWE-0066.md delete mode 100644 weaknesses/MASVS-PLATFORM/MASWE-0068.md delete mode 100644 weaknesses/MASVS-PLATFORM/MASWE-0069.md delete mode 100644 weaknesses/MASVS-PLATFORM/MASWE-0070.md delete mode 100644 weaknesses/MASVS-PLATFORM/MASWE-0071.md delete mode 100644 weaknesses/MASVS-PLATFORM/MASWE-0072.md delete mode 100644 weaknesses/MASVS-PLATFORM/MASWE-0073.md delete mode 100644 weaknesses/MASVS-PLATFORM/MASWE-0074.md delete mode 100644 weaknesses/MASVS-PLATFORM/MASWE-0118.md delete mode 100644 weaknesses/MASVS-PLATFORM/MASWE-0119.md rename weaknesses/MASVS-PRIVACY/{MASWE-0109.md => MASWE-0065.md} (79%) rename weaknesses/MASVS-PRIVACY/{MASWE-0110.md => MASWE-0066.md} (98%) rename weaknesses/MASVS-PRIVACY/{MASWE-0111.md => MASWE-0067.md} (98%) rename weaknesses/MASVS-PRIVACY/{MASWE-0112.md => MASWE-0068.md} (87%) rename weaknesses/MASVS-PRIVACY/{MASWE-0113.md => MASWE-0069.md} (98%) rename weaknesses/MASVS-PRIVACY/{MASWE-0114.md => MASWE-0070.md} (89%) rename weaknesses/MASVS-PRIVACY/{MASWE-0115.md => MASWE-0071.md} (83%) rename weaknesses/MASVS-PRIVACY/{MASWE-0117.md => MASWE-0072.md} (99%) create mode 100644 weaknesses/MASVS-PRIVACY/MASWE-0073.md create mode 100644 weaknesses/MASVS-PRIVACY/MASWE-0074.md delete mode 100644 weaknesses/MASVS-PRIVACY/MASWE-0108.md rename weaknesses/MASVS-RESILIENCE/{MASWE-0008.md => MASWE-0049.md} (97%) rename weaknesses/MASVS-RESILIENCE/{MASWE-0067.md => MASWE-0050.md} (55%) create mode 100644 weaknesses/MASVS-RESILIENCE/MASWE-0051.md rename weaknesses/MASVS-RESILIENCE/{MASWE-0090.md => MASWE-0052.md} (91%) rename weaknesses/MASVS-RESILIENCE/{MASWE-0091.md => MASWE-0053.md} (90%) create mode 100644 weaknesses/MASVS-RESILIENCE/MASWE-0054.md create mode 100644 weaknesses/MASVS-RESILIENCE/MASWE-0055.md rename weaknesses/MASVS-RESILIENCE/{MASWE-0097.md => MASWE-0056.md} (55%) rename weaknesses/MASVS-RESILIENCE/{MASWE-0098.md => MASWE-0057.md} (93%) rename weaknesses/MASVS-RESILIENCE/{MASWE-0099.md => MASWE-0058.md} (52%) rename weaknesses/MASVS-RESILIENCE/{MASWE-0100.md => MASWE-0059.md} (96%) rename weaknesses/MASVS-RESILIENCE/{MASWE-0101.md => MASWE-0060.md} (90%) rename weaknesses/MASVS-RESILIENCE/{MASWE-0102.md => MASWE-0061.md} (92%) create mode 100644 weaknesses/MASVS-RESILIENCE/MASWE-0062.md rename weaknesses/MASVS-RESILIENCE/{MASWE-0105.md => MASWE-0063.md} (84%) rename weaknesses/MASVS-RESILIENCE/{MASWE-0107.md => MASWE-0064.md} (65%) create mode 100644 weaknesses/MASVS-RESILIENCE/MASWE-0076.md delete mode 100644 weaknesses/MASVS-RESILIENCE/MASWE-0089.md delete mode 100644 weaknesses/MASVS-RESILIENCE/MASWE-0092.md delete mode 100644 weaknesses/MASVS-RESILIENCE/MASWE-0093.md delete mode 100644 weaknesses/MASVS-RESILIENCE/MASWE-0094.md delete mode 100644 weaknesses/MASVS-RESILIENCE/MASWE-0095.md delete mode 100644 weaknesses/MASVS-RESILIENCE/MASWE-0096.md delete mode 100644 weaknesses/MASVS-RESILIENCE/MASWE-0103.md delete mode 100644 weaknesses/MASVS-RESILIENCE/MASWE-0104.md delete mode 100644 weaknesses/MASVS-RESILIENCE/MASWE-0106.md create mode 100644 weaknesses/MASVS-STORAGE/MASWE-0005.md delete mode 100644 weaknesses/MASVS-STORAGE/MASWE-0007.md diff --git a/weaknesses/MASVS-AUTH/MASWE-0005.md b/weaknesses/MASVS-AUTH/MASWE-0005.md deleted file mode 100644 index 276476d..0000000 --- a/weaknesses/MASVS-AUTH/MASWE-0005.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -title: API Keys Hardcoded in the App Package -id: MASWE-0005 -alias: api-keys-hardcoded-app-package -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v2: [MASVS-AUTH-1] - mastg-v1: [] - cwe: [798] - android-risks: - - https://developer.android.com/privacy-and-security/risks/insecure-api-usage -status: new -refs: -- https://cloud.google.com/docs/authentication/api-keys#securing -- https://cloud.google.com/docs/authentication/api-keys#api_key_restrictions ---- - -## Overview - -API keys hardcoded in the app package, source code, or compiled binaries, can be easily extracted through reverse engineering. - -## Impact - -Hardcoding API keys in the app can lead to a variety of security issues, including but not limited to: - -- **Financial Loss**: Attackers can exploit the compromised hardcoded API keys to make unauthorized API calls and abuse services that are billed on a per-use basis (e.g., AI or ML API services), resulting in unexpected charges to the app owner. -- **Compromise of System Integrity and Business Operations**: Extracted API keys can give attackers unauthorized access to sensitive resources and services. This directly impacts developers and enterprises by compromising app integrity, privacy, and service continuity - potentially leading to disruptions such as Denial of Service (DoS) or service suspension due to policy violations. Such incidents can significantly impact the user experience, erode user trust, and negatively impact business reputation and operations. -- **Bypass Protection Mechanism**: Hardcoded API keys can make it easier to bypass app protection mechanisms. Attackers can use this to access restricted content, cheat in app functionality, or unlock features that are intended for purchase, impacting both revenue and user experience. - -## Modes of Introduction - -API keys can be hardcoded in several areas: - -- **App Source Code**: directly embedded in the app source code. -- **App Assets**: included in files that are destined for the final deliverable app package (typically APK/IPA), such as configuration files, manifest files, and resource files. -- **Libraries**: configuration files or source code for third-party, first-party libraries or any other app dependencies. - -## Mitigations - -- Use a stateful API service that provides secure authentication, client validation, and session controls. Implement dynamic tokens that expire after a reasonably short time (e.g., 1 hour). This can help reduce the impact of key exposure. Also, ensure proper error handling and logging to detect and respond to unauthorized access attempts. Consider using OAuth 2.0 and security libraries like AppAuth to simplify secure OAuth flows. -- If a stateful API service is not viable, consider using a stateless API service with a middleware solution (sometimes known as API proxy or API Gateway). This involves proxying requests between the app and API endpoint. Use JSON Web Tokens (JWT) and JSON Web Signature (JWS) to store the vulnerable static key server-side rather than in the application (client). Implement secure key management practices and consider using a cloud key management service. -- If API keys must be hardcoded, be sure to configure them with the minimum required permissions to reduce the impact in case of exposure. Many services allow you to create keys with restricted access, which limits the operations that can be performed. -- Consider using a [Key Management Service](https://cloud.google.com/kms/docs/key-management-service) to get API keys on runtime after validating app integrity. -- Regularly audit the codebase and dependencies for hardcoded sensitive data (e.g. using tools such as [gitLeaks](https://github.com/gitleaks/gitleaks)). -- Use white-box cryptography techniques to encrypt API keys and sensitive data within the app, ensuring that the cryptographic algorithms and keys remain protected even if the app is reverse-engineered. -- While not foolproof, and **to be used as a last resort** when no other secure options are available, code and resource obfuscation and encryption can deter attackers by making it more difficult to analyze your app and discover hardcoded secrets. Avoid custom implementations and use well-established solutions such as RASP (Runtime Application Self-Protection) which can ensure that the API keys are only fully assembled in memory when necessary, keeping them obfuscated or split across different components otherwise. RASP can also dynamically retrieve and manage keys securely at runtime by integrating with secure key management solutions. diff --git a/weaknesses/MASVS-AUTH/MASWE-0017.md b/weaknesses/MASVS-AUTH/MASWE-0017.md new file mode 100644 index 0000000..e493f50 --- /dev/null +++ b/weaknesses/MASVS-AUTH/MASWE-0017.md @@ -0,0 +1,36 @@ +--- +title: Step-Up Authentication Not Implemented for Sensitive Actions +id: MASWE-0017 +alias: step-up-auth +platform: [android, ios] +profiles: [L2] +mappings: + masvs-v1: [MSTG-AUTH-10] + masvs-v2: [MASVS-AUTH-3, MASVS-PLATFORM-3] + cwe: [306] + +refs: +- https://developer.apple.com/documentation/localauthentication +- https://auth0.com/blog/what-is-step-up-authentication-when-to-use-it/ +- https://tdcolvin.medium.com/is-firebase-auth-secure-dace0563d41b +- https://github.com/WICG/trust-token-api +- https://blog.cloudflare.com/eliminating-captchas-on-iphones-and-macs-using-new-standard/ +beta-coverage: [MASWE-0029] +draft: + description: | + Step-up authentication requires the user to re-authenticate or provide an additional + authentication factor before performing a sensitive action, even within an already + authenticated session. An example is a user logged into their bank account (with or + without MFA) who requests a sensitive action such as transferring a large sum of money: + they should be required to re-confirm their identity (e.g. via MFA or biometrics) so + that only the legitimate user can complete the action. When step-up authentication is + missing, an attacker who gains access to an active session (e.g. an unlocked device) + can perform sensitive operations unchallenged. + topics: + - re-authentication before sensitive transactions or when displaying sensitive PII (ioXt UP107) + - additional factor / MFA prompt for high-risk actions + - binding the step-up challenge to the specific action +status: placeholder + +--- + diff --git a/weaknesses/MASVS-AUTH/MASWE-0018.md b/weaknesses/MASVS-AUTH/MASWE-0018.md new file mode 100644 index 0000000..a1680a0 --- /dev/null +++ b/weaknesses/MASVS-AUTH/MASWE-0018.md @@ -0,0 +1,33 @@ +--- +title: Sensitive Data Accessible After Session Termination +id: MASWE-0018 +alias: reauth-state-changes +platform: [android, ios] +profiles: [L2] +mappings: + masvs-v2: [MASVS-AUTH-3] + cwe: [285, 287, 613] + +refs: +- https://developers.google.com/identity/sign-in/android/disconnect +- https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html +beta-coverage: [MASWE-0030] +draft: + description: | + When a session is terminated (explicit logout, timeout, or a contextual state change such + as the app moving to the background, a remarkable change in the user's location, or a + change to the user's profile), the app must invalidate the session and ensure that + sensitive data is no longer accessible. This weakness occurs when the app fails to + re-authenticate on such transitions or leaves sensitive data (session tokens, cached PII, + in-memory state, on-screen content) reachable after the session should have ended, letting + an attacker with access to the device resume access without authenticating. + topics: + - session invalidation on logout, timeout, and inactivity + - re-authentication when returning from background to foreground + - re-authentication on remarkable changes in the user's location or profile (IEEE) + - clearing sensitive data and tokens on session termination + - ASVS V3.3 Session Logout and Timeout Requirements; NIST 800-63 +status: placeholder + +--- + diff --git a/weaknesses/MASVS-AUTH/MASWE-0019.md b/weaknesses/MASVS-AUTH/MASWE-0019.md new file mode 100644 index 0000000..92f09d8 --- /dev/null +++ b/weaknesses/MASVS-AUTH/MASWE-0019.md @@ -0,0 +1,43 @@ +--- +title: Lack of Non-Repudiation for Critical Actions +id: MASWE-0019 +alias: insecure-android-confirmation +platform: [android, ios] +profiles: [L2] +mappings: + masvs-v2: [MASVS-AUTH-3] + cwe: [287, 778] + +refs: +- https://developer.android.com/training/articles/security-android-protected-confirmation +- https://source.android.com/docs/security/features/protected-confirmation +beta-coverage: [MASWE-0031] +draft: + description: | + Critical actions (e.g. confirming a payment or a high-value transaction) should be + non-repudiable: the user must be shown exactly what they are approving, through a + trusted, hardware-protected confirmation path, and the app should obtain + cryptographic evidence that this specific prompt was confirmed by the user. Without + such a path, a compromised OS, overlay attack, or tampered UI could get the user to + approve something different from what they saw, and the user could later plausibly + deny having authorized the action. + + On Android, the only known way to achieve this today is Android Protected Confirmation, + which displays a prompt via a Trusted UI and signs the confirmed message with a + hardware-backed key. Note that Android Protected Confirmation does not provide a secure + information channel, so it must not be used to display sensitive information that + wouldn't ordinarily be shown on the device. Equivalent trusted-confirmation paths on + iOS/GrapheneOS and other platforms need to be evaluated. The essential requirement is + that the confirmation goes through a Trusted UI / hardware-protected confirmation path. + + This weakness should also minimally cover the legal context of non-repudiation (e.g. + the evidentiary value of a signed, user-confirmed action). + topics: + - Android Protected Confirmation (Trusted UI + hardware-backed signature) + - hardware-protected confirmation paths on iOS / GrapheneOS and other platforms + - cryptographic evidence binding the confirmed message to the user's approval + - legal context of non-repudiation +status: placeholder + +--- + diff --git a/weaknesses/MASVS-AUTH/MASWE-0020.md b/weaknesses/MASVS-AUTH/MASWE-0020.md new file mode 100644 index 0000000..8c7eb8d --- /dev/null +++ b/weaknesses/MASVS-AUTH/MASWE-0020.md @@ -0,0 +1,51 @@ +--- +title: Lack of Authentication or Authorization on App Components +id: MASWE-0020 +alias: missing-auth-app-components +platform: [android, ios] +profiles: [L1, L2] +mappings: + masvs-v1: [MSTG-PLATFORM-4, MSTG-AUTH-3, MSTG-NETWORK-2, MSTG-STORAGE-6] + masvs-v2: [MASVS-AUTH-1, MASVS-PLATFORM-1, MASVS-STORAGE-2] + cwe: [200, 276, 284, 285, 287, 732, 749, 923, 925, 926] + +refs: +- https://developer.android.com/privacy-and-security/security-tips#IPNetworking +- https://developer.android.com/privacy-and-security/security-tips#Services +- https://developer.android.com/privacy-and-security/security-tips#BroadcastReceivers +- https://developer.android.com/privacy-and-security/security-tips#ContentProviders +- https://developer.android.com/privacy-and-security/security-tips#binder-and-messenger-interfaces +- https://developer.android.com/topic/security/risks/content-resolver +- https://developer.android.com/topic/security/risks/file-providers +beta-coverage: [MASWE-0033, MASWE-0038, MASWE-0040, MASWE-0051, MASWE-0059, MASWE-0062, MASWE-0063, MASWE-0064, MASWE-0065, MASWE-0119] +draft: + description: | + App components that expose functionality or data must enforce proper authentication and + authorization on their callers. This weakness covers any app component that is reachable + by other apps or processes without adequate access control, including Android services, + broadcast receivers, activities, and content providers, as well as a local web service or + open port exposed by the app (which is also considered an app component). + + Typical problems include components unintentionally exported, components exported with + unrestricted or missing permissions, exposed Binder/Messenger interfaces that don't verify + the caller (e.g. not calling `checkCallingPermission()`), sticky broadcasts, over-broad URI + permission grants (e.g. `FLAG_GRANT_PERSISTABLE_URI_PERMISSION` and other + `FLAG_GRANT_*_URI_PERMISSION` flags), content providers exposing data without proper + permission tags or protection levels, and locally bound network services (open ports) + accepting connections without authentication. It also covers auth-material handling on such + surfaces, such as authentication tokens not being validated and insecure authentication + handled inside WebViews. + topics: + - unintentionally exported services, broadcast receivers, activities, and content providers + - unrestricted or missing permissions and protection levels on exported components + - exposed Binder/Messenger interfaces not verifying the caller (checkCallingPermission) + - sticky broadcasts + - over-broad URI permission grants (FLAG_GRANT_READ/WRITE/PERSISTABLE_URI_PERMISSION) + - content providers (database- and file-based, FileProvider) exposing data without access control + - one-time vs. persistent data sharing with other apps + - local web service / unprotected open ports treated as an app component + - authentication tokens not validated (e.g. OAuth2/JWT client-side checks, none algorithm, PKCE) + - insecure authentication handled in WebViews (e.g. WebViewClient.onReceivedHttpAuthRequest) +status: placeholder + +--- diff --git a/weaknesses/MASVS-AUTH/MASWE-0021.md b/weaknesses/MASVS-AUTH/MASWE-0021.md new file mode 100644 index 0000000..187e131 --- /dev/null +++ b/weaknesses/MASVS-AUTH/MASWE-0021.md @@ -0,0 +1,40 @@ +--- +title: Local Authentication Can Be Bypassed +id: MASWE-0021 +alias: event-bound-biometric-auth +platform: [android, ios] +profiles: [L2] +mappings: + masvs-v1: [MSTG-AUTH-8, MSTG-AUTH-1, MSTG-AUTH-12] + masvs-v2: [MASVS-AUTH-2, MASVS-CRYPTO-2] + cwe: [285, 287, 312, 319, 326, 602, 603, 863, 922] + +refs: +- https://developer.android.com/training/sign-in/biometric-auth#crypto +- https://labs.withsecure.com/publications/how-secure-is-your-android-keystore-authentication +- https://developer.apple.com/documentation/localauthentication/accessing_keychain_items_with_face_id_or_touch_id +- https://github.com/sensepost/objection/issues/136#issuecomment-419664574 +- https://github.com/sensepost/objection/wiki/Understanding-the-iOS-Biometrics-Bypass +- https://developer.apple.com/documentation/security/secaccesscontrolcreateflags/applicationpassword +beta-coverage: [MASWE-0034, MASWE-0044, MASWE-0041, MASWE-0042, MASWE-0043] +draft: + description: | + Local authentication (biometrics, device credential, a custom app PIN/password, or + Confirm Credentials) is bypassable when it is only an event-bound UI check rather than + being cryptographically tied to a resource. Local authentication should gate access to a + key in the platform keystore and use a `CryptoObject`/keychain access control so that the + protected operation cannot proceed without a successful authentication that the OS/hardware + enforces. This weakness also covers authentication and authorization that is enforced only + locally instead of on the server-side (for connected apps), and custom PINs/passwords that + are not bound to the platform keystore, both of which allow an attacker to bypass the check + by tampering with the client. + topics: + - result-only (event-bound) biometric checks with no CryptoObject + - keychain items protected with weak access control flags (e.g. kSecAccessControlTouchIDAny) + - Confirm Credentials / device-credential fallback implemented insecurely + - authentication or authorization enforced only locally instead of on the server-side + - custom app PIN/password not bound to the platform keystore (e.g. applicationPassword) +status: placeholder + +--- + diff --git a/weaknesses/MASVS-AUTH/MASWE-0045.md b/weaknesses/MASVS-AUTH/MASWE-0022.md similarity index 94% rename from weaknesses/MASVS-AUTH/MASWE-0045.md rename to weaknesses/MASVS-AUTH/MASWE-0022.md index e7cf977..5a93f21 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0045.md +++ b/weaknesses/MASVS-AUTH/MASWE-0022.md @@ -1,6 +1,6 @@ --- title: Fallback to Non-biometric Credentials Allowed for Sensitive Transactions -id: MASWE-0045 +id: MASWE-0022 alias: no-biometric-fallback platform: [android, ios] profiles: [L2] @@ -12,6 +12,7 @@ refs: - https://developer.android.com/training/sign-in/biometric-auth#allow-fallback - https://developer.apple.com/documentation/localauthentication/logging_a_user_into_your_app_with_face_id_or_touch_id#3148834 - https://developer.apple.com/documentation/localauthentication/lapolicy/deviceownerauthenticationwithbiometrics/ +beta-coverage: [MASWE-0045] draft: description: e.g. via DEVICE_CREDENTIAL on Android and LAPolicy.deviceOwnerAuthentication on iOS diff --git a/weaknesses/MASVS-AUTH/MASWE-0046.md b/weaknesses/MASVS-AUTH/MASWE-0023.md similarity index 95% rename from weaknesses/MASVS-AUTH/MASWE-0046.md rename to weaknesses/MASVS-AUTH/MASWE-0023.md index 7822f9c..1ab8c18 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0046.md +++ b/weaknesses/MASVS-AUTH/MASWE-0023.md @@ -1,6 +1,6 @@ --- title: Crypto Keys Not Invalidated on New Biometric Enrollment -id: MASWE-0046 +id: MASWE-0023 alias: crypto-keys-biometric-enrollment platform: [android, ios] profiles: [L2] @@ -8,6 +8,7 @@ mappings: masvs-v2: [MASVS-AUTH-2, MASVS-CRYPTO-2] cwe: [287, 522] +beta-coverage: [MASWE-0046] draft: description: Biometric related crypto keys should be is invalidated by default whenever new biometric enrollments are added. diff --git a/weaknesses/MASVS-AUTH/MASWE-0024.md b/weaknesses/MASVS-AUTH/MASWE-0024.md new file mode 100644 index 0000000..a3e7325 --- /dev/null +++ b/weaknesses/MASVS-AUTH/MASWE-0024.md @@ -0,0 +1,41 @@ +--- +title: Lack of Auto-fill Support for Authenticators +id: MASWE-0024 +alias: autofill-authenticators +platform: [android, ios] +profiles: [L2] +mappings: + masvs-v1: [MSTG-AUTH-9] + masvs-v2: [MASVS-AUTH-1, MASVS-AUTH-3] + cwe: [287, 522] + +refs: +- https://developer.apple.com/documentation/security/password_autofill +- https://developer.apple.com/documentation/authenticationservices/aswebauthenticationsession +- https://developer.android.com/guide/topics/text/autofill +- https://developer.apple.com/documentation/authenticationservices/public-private_key_authentication/supporting_passkeys +beta-coverage: [MASWE-0028, MASWE-0032, MASWE-0035, MASWE-0039] +draft: + description: | + Apps should support the platform's auto-fill mechanisms for authenticators so that + credentials, one-time codes, and passkeys can be provided securely without the user + resorting to insecure workarounds such as copy/paste from other apps. Lacking auto-fill + support pushes users toward weaker practices and misses the platform's secure credential + flows. + + This consolidates several related best practices: credential and one-time-code auto-fill + (e.g. platform auto-fill from SMS) to avoid copy/paste; iOS Password AutoFill, which + streamlines logging into web services associated with the app's domain (and, for + third-party services, using `ASWebAuthenticationSession` instead of Password AutoFill); + passwordless authentication such as passkeys / multi-device FIDO credentials and + WebAuthn/`ASAuthorization`; and shared web credentials / website association so that + credentials can be shared securely between an app and its website counterpart. + topics: + - credential and one-time-code auto-fill to avoid copy/paste (e.g. platform auto-fill from SMS) + - iOS Password AutoFill for the app's associated domain + - ASWebAuthenticationSession for third-party services instead of Password AutoFill + - passwordless authentication (passkeys, multi-device FIDO, WebAuthn/ASAuthorization) + - shared web credentials and website association +status: placeholder + +--- diff --git a/weaknesses/MASVS-AUTH/MASWE-0028.md b/weaknesses/MASVS-AUTH/MASWE-0028.md deleted file mode 100644 index 9f4a9d4..0000000 --- a/weaknesses/MASVS-AUTH/MASWE-0028.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: MFA Implementation Best Practices Not Followed -id: MASWE-0028 -alias: mfa-best-practices -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v1: [MSTG-AUTH-9] - masvs-v2: [MASVS-AUTH-3] - cwe: [287] - -draft: - description: e.g. not using auto-fill - topics: - - platform auto-fill from SMS - - use of Sign-in with Apple - - MFA best practices - - (IEEE) unreliable channels such as voice mails and phone numbers must be avoided - - is not enforced only locally but server-side - - check if relies on static responses from the remote endpoint such as `"message":"Success"` -status: placeholder - ---- - diff --git a/weaknesses/MASVS-AUTH/MASWE-0029.md b/weaknesses/MASVS-AUTH/MASWE-0029.md deleted file mode 100644 index 6b8ca4f..0000000 --- a/weaknesses/MASVS-AUTH/MASWE-0029.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: Step-Up Authentication Not Implemented After Login -id: MASWE-0029 -alias: step-up-auth -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v1: [MSTG-AUTH-10] - masvs-v2: [MASVS-AUTH-3, MASVS-PLATFORM-3] - cwe: [306] - -refs: -- https://developer.apple.com/documentation/localauthentication -- https://auth0.com/blog/what-is-step-up-authentication-when-to-use-it/ -- https://tdcolvin.medium.com/is-firebase-auth-secure-dace0563d41b -- https://github.com/WICG/trust-token-api -- https://blog.cloudflare.com/eliminating-captchas-on-iphones-and-macs-using-new-standard/ -draft: - description: An example of step-up authentication is when a user is logged into - their bank account (with or without MFA) and requests an action that is considered - sensitive, such as the transfer of a large sum of money. In such cases, the user - will be required to provide additional information to authenticate their identity - (e.g. using MFA) and ensure only the legitimate user is requesting the action. - topics: - - (ioXt) UP107 App shall re-authenticate the user when displaying sensitive PII - data or conducting sensitive transactions. - - null -status: placeholder - ---- - diff --git a/weaknesses/MASVS-AUTH/MASWE-0030.md b/weaknesses/MASVS-AUTH/MASWE-0030.md deleted file mode 100644 index 93503f0..0000000 --- a/weaknesses/MASVS-AUTH/MASWE-0030.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: Re-Authenticates Not Triggered On Contextual State Changes -id: MASWE-0030 -alias: reauth-state-changes -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v2: [MASVS-AUTH-3] - cwe: [285, 287] - -refs: -- https://developers.google.com/identity/sign-in/android/disconnect -draft: - description: Re-authentication means forcing a new login after e.g. timeout, changing - state from running in the background to running in the foreground, remarkable - changes in a user's location, profile, etc. - topics: - - timeout - - changing state from running in the background to running in the foreground - - (IEEE) remarkable changes in a user's location - - ASVS V3.3 Session Logout and Timeout Requirements - - NIST 800-63 - - etc. -status: placeholder - ---- - diff --git a/weaknesses/MASVS-AUTH/MASWE-0031.md b/weaknesses/MASVS-AUTH/MASWE-0031.md deleted file mode 100644 index be99d6d..0000000 --- a/weaknesses/MASVS-AUTH/MASWE-0031.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: Insecure use of Android Protected Confirmation -id: MASWE-0031 -alias: insecure-android-confirmation -platform: [android] -profiles: [L2] -mappings: - masvs-v2: [MASVS-AUTH-3] - cwe: [287] - -draft: - description: Android Protected Confirmation doesn't provide a secure information - channel for the user. Don't use it to display sensitive information that you wouldn't - ordinarily show on the user's device. - topics: - - Android Protected Confirmation -status: placeholder - ---- - diff --git a/weaknesses/MASVS-AUTH/MASWE-0032.md b/weaknesses/MASVS-AUTH/MASWE-0032.md deleted file mode 100644 index 3f1db13..0000000 --- a/weaknesses/MASVS-AUTH/MASWE-0032.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: Platform-provided Authentication APIs Not Used -id: MASWE-0032 -alias: platform-auth-apis -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v2: [MASVS-AUTH-1, MASVS-CODE-3] - cwe: [287] - -refs: -- https://developer.android.com/privacy-and-security/security-tips#Credentials -- https://developer.apple.com/documentation/security/password_autofill -- https://developer.apple.com/videos/play/wwdc2017/206 -- https://developer.android.com/guide/topics/text/autofill-optimize -draft: - description: AKA don't roll your own authentication security. Platform-provided - APIs are designed and implemented by experts who have deep knowledge of the platform's - security features and considerations. These APIs often incorporate security best - practices and are regularly updated to address new threats and vulnerabilities. - Not using platform-provided authentication APIs in mobile apps can result in security - vulnerabilities, inconsistent user experience, missed integration opportunities, - and increased development and maintenance efforts. - topics: - - credential auto-fill to avoid copy/paste - - correct use of Android AccountManager (e.g. invoke a cloud-based service and don't - store passwords on the device). AccountManager data stored in clear in some Android - versions. - - use of CREATOR afterretrieving an account with AccountManager - - use of Authentication Services framework on iOS - - iOS Password AutoFill streamlines logging into web services at your domain. However, - if you need to log into a third-party service, use ASWebAuthenticationSession - instead -status: placeholder - ---- - diff --git a/weaknesses/MASVS-AUTH/MASWE-0033.md b/weaknesses/MASVS-AUTH/MASWE-0033.md deleted file mode 100644 index 79f9530..0000000 --- a/weaknesses/MASVS-AUTH/MASWE-0033.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: Authentication or Authorization Protocol Security Best Practices Not Followed -id: MASWE-0033 -alias: auth-protocol-best-practices -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v2: [MASVS-AUTH-1] - cwe: [285, 287] - -refs: -- https://mobidev.biz/blog/single-sign-on-sso-implementation-benefits-enterprise -- https://developers.google.com/identity/protocols/risc -- https://developer.apple.com/documentation/authenticationservices/aswebauthenticationsession/3237231-prefersephemeralwebbrowsersessio?language=objc -- https://developer.apple.com/videos/play/tech-talks/301 -- https://developers.google.com/identity/protocols/oauth2 -draft: - description: For example, when using oauth2, the app does not use PKCE, etc. See - RFC-8252. Focus on client-side best practices. - topics: - - best practices from RFC-8252 - - SSO -> OpenID Connect (OIDC) - - use of Google Service Accounts - - use of RISC - - use of Apple Redirect extensions for Enterprise - - using use SFAuthenticationSession (deprecated) instead of ASWebAuthenticationSession - - secure mutual authentication using X.509v3 certificates - - use of context to add security to authentication e.g. via IP or location data - - set prefersEphemeralWebBrowserSession to true before calling start for a session - on iOS -status: placeholder - ---- - diff --git a/weaknesses/MASVS-AUTH/MASWE-0034.md b/weaknesses/MASVS-AUTH/MASWE-0034.md deleted file mode 100644 index c1cc737..0000000 --- a/weaknesses/MASVS-AUTH/MASWE-0034.md +++ /dev/null @@ -1,14 +0,0 @@ ---- -title: Insecure Implementation of Confirm Credentials -id: MASWE-0034 -alias: insecure-confirm-credentials -platform: [android] -profiles: [L2] -mappings: - masvs-v2: [MASVS-AUTH-2] - cwe: [287, 319] - -status: deprecated -covered_by: [MASWE-0044] -deprecation_note: Content overlap. Confirm Credentials is a form of local authentication that will have a dedicated MASTG test. ---- diff --git a/weaknesses/MASVS-AUTH/MASWE-0035.md b/weaknesses/MASVS-AUTH/MASWE-0035.md deleted file mode 100644 index 9057036..0000000 --- a/weaknesses/MASVS-AUTH/MASWE-0035.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: Passwordless Authentication Not Implemented -id: MASWE-0035 -alias: no-passwordless-auth -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v2: [MASVS-AUTH-1, MASVS-STORAGE-1] - cwe: [287] - -refs: -- https://developer.apple.com/documentation/authenticationservices/public-private_key_authentication -- https://www.w3.org/TR/webauthn-2/ -- https://fidoalliance.org/white-paper-multi-device-fido-credentials/ -- https://developers.google.com/identity/fido -- https://developers.google.com/identity/fido#what_are_passkeys -- https://fidoalliance.org/developers/ -- https://fidoalliance.org/product-category/android-client/ -- https://fidoalliance.org/product-category/ios-client/ -- https://developer.apple.com/documentation/authenticationservices/public-private_key_authentication/supporting_passkeys -- https://techcommunity.microsoft.com/t5/azure-active-directory-identity/expansion-of-fido-standard-and-new-updates-for-microsoft/ba-p/3290633 -- https://developer.apple.com/documentation/authenticationservices/public-private_key_authentication/supporting_security_key_authentication_using_physical_keys -- https://developer.apple.com/videos/play/wwdc2021/10106/ -draft: - description: there's no use of passwordless authentication mechanisms e.g. passkeys - topics: - - passkeys or multi-device FIDO credentials - - WebAuthn/ASAuthorization - - use of Physical Security Keys which stored the public-private key pair on a physical - medium, such as a security card or a USB key -status: placeholder - ---- - diff --git a/weaknesses/MASVS-AUTH/MASWE-0036.md b/weaknesses/MASVS-AUTH/MASWE-0036.md deleted file mode 100644 index cddcb48..0000000 --- a/weaknesses/MASVS-AUTH/MASWE-0036.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: Authentication Material Stored Unencrypted on the Device -id: MASWE-0036 -alias: auth-material-unencrypted -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v2: [MASVS-AUTH-1, MASVS-STORAGE-1] - cwe: [312] - -refs: -- https://developers.google.com/identity/blockstore/android?hl=en -- https://cloud.google.com/docs/authentication/best-practices-applications#semi-trusted_or_restricted_environments -- https://cloud.google.com/docs/authentication/best-practices-applications#security_considerations -- https://developer.apple.com/documentation/signinwithapplerestapi -draft: - description: General authentication material management best practices. Note that API keys are covered separately. - topics: - - session IDs - - tokens - - passwords - - use of sign-in with Apple/Google -status: placeholder - ---- - diff --git a/weaknesses/MASVS-AUTH/MASWE-0037.md b/weaknesses/MASVS-AUTH/MASWE-0037.md deleted file mode 100644 index 31202cf..0000000 --- a/weaknesses/MASVS-AUTH/MASWE-0037.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: Authentication Material Sent over Insecure Connections -id: MASWE-0037 -alias: auth-material-over-insecure-connections -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v2: [MASVS-AUTH-1, MASVS-NETWORK-1] - cwe: [319] - -draft: - description: General authentication best practice. - topics: - - session IDs - - tokens - - passwords - - API keys -status: placeholder - ---- - diff --git a/weaknesses/MASVS-AUTH/MASWE-0038.md b/weaknesses/MASVS-AUTH/MASWE-0038.md deleted file mode 100644 index 5778437..0000000 --- a/weaknesses/MASVS-AUTH/MASWE-0038.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: Authentication Tokens Not Validated -id: MASWE-0038 -alias: unvalidated-auth-tokens -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v1: [MSTG-AUTH-3] - masvs-v2: [MASVS-AUTH-1, MASVS-CODE-4] - cwe: [287] - -refs: -- https://developers.google.com/identity/sign-in/android/backend-auth#verify-the-integrity-of-the-id-token -- https://developers.google.com/identity/protocols/oauth2/openid-connect#validatinganidtoken -- https://developer.apple.com/documentation/sign_in_with_apple/generate_and_validate_tokens -draft: - description: e.g. oauth2/jwt client-side checks - topics: - - code grant - - expiration - - none algorithm - - PKCE - - implicit grant -status: placeholder - ---- - diff --git a/weaknesses/MASVS-AUTH/MASWE-0039.md b/weaknesses/MASVS-AUTH/MASWE-0039.md deleted file mode 100644 index fef285d..0000000 --- a/weaknesses/MASVS-AUTH/MASWE-0039.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: Shared Web Credentials and Website-association Not Implemented -id: MASWE-0039 -alias: no-shared-web-credentials -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v2: [MASVS-AUTH-1, MASVS-PLATFORM-1] - cwe: [287] - -refs: -- https://developer.apple.com/documentation/security/shared_web_credentials -draft: - description: Best practice for sharing credentials between apps and their website - counterparts. - topics: - - Website-association - - Shared Web Credentials -status: placeholder - ---- - diff --git a/weaknesses/MASVS-AUTH/MASWE-0040.md b/weaknesses/MASVS-AUTH/MASWE-0040.md deleted file mode 100644 index ba9ab8a..0000000 --- a/weaknesses/MASVS-AUTH/MASWE-0040.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: Insecure Authentication in WebViews -id: MASWE-0040 -alias: insecure-webview-auth -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v2: [MASVS-AUTH-1, MASVS-PLATFORM-2] - cwe: [287] - -refs: - - https://developer.android.com/reference/android/webkit/WebView#getHttpAuthUsernamePassword(java.lang.String,%20java.lang.String) - - https://developer.android.com/reference/android/webkit/WebViewClient#onReceivedHttpAuthRequest(android.webkit.WebView,%20android.webkit.HttpAuthHandler,%20java.lang.String,%20java.lang.String) -draft: - description: e.g. via WebView.getHttpAuthUsernamePassword / WebViewClient.onReceivedHttpAuthRequest - topics: - - Using WebView.getHttpAuthUsernamePassword / WebViewClient.onReceivedHttpAuthRequest -status: placeholder - ---- - diff --git a/weaknesses/MASVS-AUTH/MASWE-0041.md b/weaknesses/MASVS-AUTH/MASWE-0041.md deleted file mode 100644 index 2f45b7a..0000000 --- a/weaknesses/MASVS-AUTH/MASWE-0041.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: Authentication Enforced Only Locally Instead of on the Server-side -id: MASWE-0041 -alias: local-auth-enforcement -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v1: [MSTG-AUTH-1] - masvs-v2: [MASVS-AUTH-2] - cwe: [603, 287] - -draft: - description: General authentication best practice. Only for apps with connection. - The app performs local authentication involving the remote endpoint and according - to the platform best practices. - topics: - - (IEEE) Since client-side security controls are capable of being invaded, authentication - and authorization controls should be implemented on the server-side. - - biometry only used as part of MFA authentication and not as the only auth method -status: placeholder - ---- - diff --git a/weaknesses/MASVS-AUTH/MASWE-0042.md b/weaknesses/MASVS-AUTH/MASWE-0042.md deleted file mode 100644 index 51f254e..0000000 --- a/weaknesses/MASVS-AUTH/MASWE-0042.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: Authorization Enforced Only Locally Instead of on the Server-side -id: MASWE-0042 -alias: local-authz-enforcement -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v1: [MSTG-AUTH-12] - masvs-v2: [MASVS-AUTH-2] - cwe: [285, 602, 863] - -refs: -- https://developers.google.com/identity/smartlock-passwords/android/associate-apps-and-sites -draft: - description: General authentication best practice. Only for apps with connection. - topics: - - Authorization Enforced Locally - - use of oauth - - use of SharedWebcredentials - - use of WebAuthn/ASAuthorization -status: placeholder - ---- - diff --git a/weaknesses/MASVS-AUTH/MASWE-0043.md b/weaknesses/MASVS-AUTH/MASWE-0043.md deleted file mode 100644 index 86cd3ff..0000000 --- a/weaknesses/MASVS-AUTH/MASWE-0043.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: App Custom PIN Not Bound to Platform KeyStore -id: MASWE-0043 -alias: custom-pin-keystore -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v2: [MASVS-AUTH-2, MASVS-CRYPTO-2] - cwe: [922, 326, 312] - -draft: - description: It's better to use the OS Local Auth / bind to a key stored in the platform KeyStore. Consider new title App Custom Password Not Bound to Platform KeyStore where password could be password or PIN. - topics: - - use the OS Local Auth - - binding to keys stored in the platform KeyStore - - https://developer.apple.com/documentation/security/secaccesscontrolcreateflags/applicationpassword -status: placeholder - ---- - diff --git a/weaknesses/MASVS-AUTH/MASWE-0044.md b/weaknesses/MASVS-AUTH/MASWE-0044.md deleted file mode 100644 index 06f55b1..0000000 --- a/weaknesses/MASVS-AUTH/MASWE-0044.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: Biometric Authentication Can Be Bypassed -id: MASWE-0044 -alias: event-bound-biometric-auth -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v1: [MSTG-AUTH-8] - masvs-v2: [MASVS-AUTH-2] - cwe: [287] - -refs: -- https://developer.android.com/training/sign-in/biometric-auth#crypto -- https://labs.withsecure.com/publications/how-secure-is-your-android-keystore-authentication -- https://developer.apple.com/documentation/localauthentication/accessing_keychain_items_with_face_id_or_touch_id -- https://github.com/sensepost/objection/issues/136#issuecomment-419664574 -- https://github.com/sensepost/objection/wiki/Understanding-the-iOS-Biometrics-Bypass -draft: - description: It should be based on unlock platform KeyStore / crypto, use CryptoObject - topics: - - no use of CryptoObject - - keychain items protected with access control flags such as kSecAccessControlTouchIDAny - or kSecAccessControlTouchIDCurrentSet -status: placeholder - ---- - diff --git a/weaknesses/MASVS-CODE/MASWE-0040.md b/weaknesses/MASVS-CODE/MASWE-0040.md new file mode 100644 index 0000000..15d2c4e --- /dev/null +++ b/weaknesses/MASVS-CODE/MASWE-0040.md @@ -0,0 +1,26 @@ +--- +title: Enforced Updating Not Implemented +id: MASWE-0040 +alias: enforced-updating +platform: [android, ios] +profiles: [L2] +mappings: + masvs-v1: [MSTG-ARCH-9] + masvs-v2: [MASVS-CODE-2] + cwe: [602, 693] + +refs: +- https://developer.android.com/guide/playcore/in-app-updates +- https://developer.android.com/reference/com/google/android/play/core/appupdate/AppUpdateManager +- https://medium.com/swlh/updating-users-to-the-latest-app-release-on-ios-ed96e4c76705 +- https://gist.github.com/DineshKachhot/f63fcebceca6351fc982cafd38f6f05c +draft: + description: Check if the app enforces updates e.g. via AppUpdateManager on Android or itunes check on app version on iOS. However, the backend would be enforcing this and not only the app locally. + topics: + - The in‑app update mechanism isn't used at all (CWE-693). + - The update enforcement occurs purely locally (client‑side) without server‑side checks (CWE-602). +beta-coverage: [MASWE-0075] +status: placeholder + +--- + diff --git a/weaknesses/MASVS-CODE/MASWE-0076.md b/weaknesses/MASVS-CODE/MASWE-0041.md similarity index 99% rename from weaknesses/MASVS-CODE/MASWE-0076.md rename to weaknesses/MASVS-CODE/MASWE-0041.md index aa678db..6f62f8b 100644 --- a/weaknesses/MASVS-CODE/MASWE-0076.md +++ b/weaknesses/MASVS-CODE/MASWE-0041.md @@ -1,6 +1,6 @@ --- title: Dependencies with Known Vulnerabilities -id: MASWE-0076 +id: MASWE-0041 alias: dependencies-with-known-vulnerabilities platform: [android, ios] profiles: [L1, L2] @@ -25,6 +25,7 @@ refs: - https://developer.apple.com/support/third-party-SDK-requirements/ - https://www.youtube.com/watch?v=3klmiHX0uVQ - https://developer.apple.com/videos/play/wwdc2023/10060/ +beta-coverage: [MASWE-0076] --- ## Overview @@ -53,7 +54,7 @@ In terms of privacy, dependencies can introduce risks if they collect or transmi "When you use a third-party SDK with your app, you are responsible for all the code the SDK includes in your app, and need to be aware of its data collection and use practices. -For more information on privacy and data collection declarations, see @MASWE-0112. +For more information on privacy and data collection declarations, see @MASWE-0068. ## Impact diff --git a/weaknesses/MASVS-CODE/MASWE-0042.md b/weaknesses/MASVS-CODE/MASWE-0042.md new file mode 100644 index 0000000..5a66153 --- /dev/null +++ b/weaknesses/MASVS-CODE/MASWE-0042.md @@ -0,0 +1,28 @@ +--- +title: Running on a recent Platform Version Not Ensured +id: MASWE-0042 +alias: run-on-recent-platform-version +platform: [android, ios] +profiles: [L2] +mappings: + masvs-v2: [MASVS-CODE-1] + cwe: [451, 693, 1104, 1357] + +refs: +- https://developer.android.com/topic/security/risks/strandhogg +beta-coverage: [MASWE-0077, MASWE-0057] +draft: + description: | + e.g. via minSdkVersion on Android and MinimumOSVersion on iOS. Ensuring a recent minimum + platform version guarantees the availability of security features and components + (MASVS-STORAGE-1), the NSC/ATS availability (Android > 7.0 / iOS > 9.0, MASVS-NETWORK-1), + and secure WebView configuration (MASVS-PLATFORM-2). Running on older versions also exposes + the app to platform-level vulnerabilities that were fixed in later releases, such as the + StrandHogg task-affinity/`allowTaskReparenting` attacks on older Android versions. + topics: + - The app sets a low minimum OS version to support older devices, but still relies, implicitly or explicitly, on security features (e.g., runtime permissions, hardware-backed keystore, network security policies) that may not exist on those versions (CWE-693 and CWE-1357). + - exposure to platform vulnerabilities fixed in later releases (e.g. StrandHogg v1/v2, task affinity / allowTaskReparenting on older Android) +status: placeholder + +--- + diff --git a/weaknesses/MASVS-CODE/MASWE-0078.md b/weaknesses/MASVS-CODE/MASWE-0043.md similarity index 93% rename from weaknesses/MASVS-CODE/MASWE-0078.md rename to weaknesses/MASVS-CODE/MASWE-0043.md index 8c333c4..85ec151 100644 --- a/weaknesses/MASVS-CODE/MASWE-0078.md +++ b/weaknesses/MASVS-CODE/MASWE-0043.md @@ -1,6 +1,6 @@ --- title: Latest Platform Version Not Targeted -id: MASWE-0078 +id: MASWE-0043 alias: target-latest-platform-version platform: [android, ios] profiles: [L2] @@ -13,6 +13,7 @@ draft: topics: - targetSDK on Android - XCode version on iOS +beta-coverage: [MASWE-0078] status: placeholder --- diff --git a/weaknesses/MASVS-CODE/MASWE-0044.md b/weaknesses/MASVS-CODE/MASWE-0044.md new file mode 100644 index 0000000..1dd6959 --- /dev/null +++ b/weaknesses/MASVS-CODE/MASWE-0044.md @@ -0,0 +1,28 @@ +--- +title: Unsafe Dynamic Code Loading +id: MASWE-0044 +alias: unsafe-code-loading +platform: [android, ios] +profiles: [L2] +mappings: + masvs-v2: [MASVS-CODE-4] + cwe: [494] + +refs: +- https://developer.android.com/privacy-and-security/risks/runtime-code-loading +beta-coverage: [MASWE-0085] +draft: + description: | + Loading and executing code that is fetched or resolved at runtime (e.g. via `dlopen`, + `DexClassLoader`/`PathClassLoader`, loading native libraries or DEX/JAR files from writable + or external locations, or downloading executable code) is dangerous when the source or + integrity of that code is not verified. An attacker who can modify or substitute the loaded + code can achieve arbitrary code execution within the app's context (CWE-494). + topics: + - dlopen / native library loading from untrusted paths + - DexClassLoader / PathClassLoader loading from writable or external storage + - downloading and executing code without integrity/authenticity verification +status: placeholder + +--- + diff --git a/weaknesses/MASVS-CODE/MASWE-0116.md b/weaknesses/MASVS-CODE/MASWE-0045.md similarity index 97% rename from weaknesses/MASVS-CODE/MASWE-0116.md rename to weaknesses/MASVS-CODE/MASWE-0045.md index fdc3afd..f8debf8 100644 --- a/weaknesses/MASVS-CODE/MASWE-0116.md +++ b/weaknesses/MASVS-CODE/MASWE-0045.md @@ -1,6 +1,6 @@ --- title: Compiler-Provided Security Features Not Used -id: MASWE-0116 +id: MASWE-0045 alias: compiler-provided-security-features-not-implemented platform: [android, ios] profiles: [L2] @@ -20,6 +20,7 @@ draft: - PIC - stack canaries note: PIC cannot be switched off in newer versions of Android, the NDK does not link against such libraries anymore [source](https://cs.android.com/android/platform/superproject/main/+/main:bionic/linker/linker_main.cpp;l=397?q=linker_main&ss=android%2Fplatform%2Fsuperproject%2Fmain). Alternative title could be Memory Anti-Exploitation Mechanisms Not Implemented. +beta-coverage: [MASWE-0116] status: placeholder observed_examples: - https://nvd.nist.gov/vuln/detail/CVE-2019-3568 diff --git a/weaknesses/MASVS-CODE/MASWE-0046.md b/weaknesses/MASVS-CODE/MASWE-0046.md new file mode 100644 index 0000000..766892d --- /dev/null +++ b/weaknesses/MASVS-CODE/MASWE-0046.md @@ -0,0 +1,33 @@ +--- +title: Use of Deprecated APIs or Functionality +id: MASWE-0046 +alias: deprecated-apis +platform: [android, ios] +profiles: [L2] +mappings: + masvs-v1: [MSTG-CRYPTO-4] + masvs-v2: [MASVS-CODE-3, MASVS-CRYPTO-2] + cwe: [327, 477, 522] + +refs: +- https://developer.android.com/about/versions/12/behavior-changes-all#bouncy-castle +- https://developer.android.com/reference/java/security/KeyStore +- https://labs.withsecure.com/publications/how-secure-is-your-android-keystore-authentication +beta-coverage: [MASWE-0015] +draft: + description: | + The app relies on deprecated APIs or functionality that are no longer maintained, may lack + security fixes, or have been superseded by safer alternatives. Continuing to use deprecated + security-relevant APIs can leave the app exposed to known weaknesses that the platform has + already addressed in newer APIs. A representative example is the use of deprecated Android + KeyStore implementations such as Bouncy Castle (BKS), but this weakness covers deprecated + APIs and functionality in general (cryptography, storage, networking, platform, etc.). + topics: + - deprecated KeyStore implementations (e.g. Bouncy Castle / BKS) + - deprecated cryptographic providers and algorithms + - deprecated platform APIs superseded by safer alternatives + - identifying deprecation warnings during build +status: placeholder + +--- + diff --git a/weaknesses/MASVS-CODE/MASWE-0047.md b/weaknesses/MASVS-CODE/MASWE-0047.md new file mode 100644 index 0000000..0f170d1 --- /dev/null +++ b/weaknesses/MASVS-CODE/MASWE-0047.md @@ -0,0 +1,45 @@ +--- +title: Using Non-Standard Libraries for Security-Critical Functionality +id: MASWE-0047 +alias: non-standard-security-libs +platform: [android, ios] +profiles: [L2] +mappings: + masvs-v1: [MSTG-CRYPTO-2, MSTG-NETWORK-6] + masvs-v2: [MASVS-CODE-3, MASVS-AUTH-1, MASVS-CRYPTO-1, MASVS-NETWORK-1] + cwe: [287, 326, 327, 1240] + +refs: +- https://developer.android.com/privacy-and-security/security-tips#Credentials +- https://developer.apple.com/documentation/security/password_autofill +- https://developer.android.com/privacy-and-security/cryptography#crypto_provider +- https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf?__blob=publicationFile +beta-coverage: [MASWE-0019, MASWE-0032, MASWE-0049] +draft: + description: | + Security-critical functionality (cryptography, networking/TLS, and authentication) should + rely on well-vetted, platform-provided APIs or established, peer-reviewed libraries rather + than custom ("roll-your-own") implementations or unproven third-party libraries. Platform + APIs are designed and maintained by experts, incorporate security best practices, and are + regularly updated to address new threats. Custom or non-standard implementations are far + more likely to contain subtle, exploitable flaws and to miss timely security updates. + + This weakness consolidates: + + - **Risky cryptography implementations**: custom or non-compliant crypto (e.g. not meeting + standards such as FIPS 140-2/3), unproven algorithms, or home-grown constructions that + haven't undergone rigorous peer review and formal validation. + - **Non-standard networking**: rolling a custom networking/TLS stack or using outdated + third-party networking libraries instead of proven APIs such as `URLSession`/`NSURLSession` + on iOS or `HttpsURLConnection`/`OkHttp` on Android. + - **Non-standard authentication**: implementing custom authentication instead of using + platform-provided authentication APIs (e.g. Android Credential Manager/`AccountManager`, + iOS Authentication Services / Password AutoFill). + topics: + - roll-your-own cryptography vs. vetted, standards-compliant libraries + - custom networking/TLS stacks vs. proven networking APIs (URLSession, HttpsURLConnection, OkHttp, Alamofire) + - custom authentication vs. platform-provided authentication APIs (Credential Manager, AccountManager, Authentication Services) + - unmaintained/unproven third-party security libraries +status: placeholder + +--- diff --git a/weaknesses/MASVS-CODE/MASWE-0048.md b/weaknesses/MASVS-CODE/MASWE-0048.md new file mode 100644 index 0000000..179e593 --- /dev/null +++ b/weaknesses/MASVS-CODE/MASWE-0048.md @@ -0,0 +1,48 @@ +--- +title: Unsafe Handling of Untrusted Data +id: MASWE-0048 +alias: unsafe-untrusted-data +platform: [android, ios] +profiles: [L1, L2] +mappings: + masvs-v1: [MSTG-PLATFORM-2] + masvs-v2: [MASVS-CODE-4] + cwe: [20, 22, 73, 89, 116, 345, 348, 349, 502, 611, 924] + +refs: +- https://developer.android.com/topic/security/risks/path-traversal +- https://developer.android.com/topic/security/risks/sql-injection +- https://developer.android.com/privacy-and-security/risks/unsafe-deserialization +- https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html +beta-coverage: [MASWE-0079, MASWE-0080, MASWE-0081, MASWE-0082, MASWE-0083, MASWE-0084, MASWE-0086, MASWE-0087, MASWE-0088] +draft: + description: | + Any data that originates outside the app's trust boundary must be treated as untrusted and + validated, sanitized, or safely parsed before use, even when it arrives over a secure + channel. Failing to do so can lead to injection, path traversal, and memory-corruption + vulnerabilities when the data reaches a sensitive sink. + + This weakness consolidates unsafe handling of data regardless of its source, including: + + - **Network** data (even over TLS). + - **Backup** data restored to the app (unvalidated restored data, CWE-349). + - **External interfaces** such as Bluetooth, NFC, and USB. + - **Local storage** (internal/external files, document pickers), including path traversal + and zip path traversal. + - **User interface** input (text fields, QR codes, URLs, pasteboard). + - **IPC** (received intents, broadcast receivers, content URIs, URL schemes). + + It also covers the dangerous sinks where untrusted data causes harm, such as SQL injection + (use parameterized queries), insecure parsing and escaping (e.g. XXE, improper output + encoding), and insecure object deserialization (e.g. `java.io.Serializable`, `Parcelable`, + `NSCoding`, XML/JSON). + topics: + - untrusted data from network, backups, external interfaces, local storage, UI, and IPC + - input validation and sanitization at trust boundaries + - path traversal and zip path traversal + - SQL injection / parameterized queries + - insecure parsing and escaping (XXE, output encoding) + - insecure object deserialization (Serializable, Parcelable, NSCoding, XML/JSON) +status: placeholder + +--- diff --git a/weaknesses/MASVS-CODE/MASWE-0075.md b/weaknesses/MASVS-CODE/MASWE-0075.md index c4f7ebe..d61e5ba 100644 --- a/weaknesses/MASVS-CODE/MASWE-0075.md +++ b/weaknesses/MASVS-CODE/MASWE-0075.md @@ -1,25 +1,33 @@ --- -title: Enforced Updating Not Implemented +title: Malicious Code Included in the App id: MASWE-0075 -alias: enforced-updating +alias: malicious-code-included platform: [android, ios] profiles: [L2] mappings: - masvs-v1: [MSTG-ARCH-9] - masvs-v2: [MASVS-CODE-2] - cwe: [602, 693] + masvs-v2: [MASVS-CODE-3] + cwe: [506, 507, 511] refs: -- https://developer.android.com/guide/playcore/in-app-updates -- https://developer.android.com/reference/com/google/android/play/core/appupdate/AppUpdateManager -- https://medium.com/swlh/updating-users-to-the-latest-app-release-on-ios-ed96e4c76705 -- https://gist.github.com/DineshKachhot/f63fcebceca6351fc982cafd38f6f05c +- https://developer.android.com/privacy-and-security/risks/insecure-library +- https://support.google.com/googleplay/android-developer/answer/13326895 +- https://developer.apple.com/support/third-party-SDK-requirements/ draft: - description: Check if the app enforces updates e.g. via AppUpdateManager on Android or itunes check on app version on iOS. However, the backend would be enforcing this and not only the app locally. + description: | + An app may ship with malicious code, either introduced intentionally by an insider, or + unintentionally through a compromised dependency, SDK, build tool, or supply-chain attack. + Malicious code can exfiltrate data, execute hidden or backdoored functionality, display + unwanted content, or perform actions against the user's interest. Because the developer is + responsible for all code shipped in the app (including third-party SDKs), the app must be + reviewed and its supply chain controlled to detect and prevent inclusion of malicious code. + This complements [MASWE-0041](MASWE-0041.md) (dependencies with known vulnerabilities) and + [MASWE-0077](MASWE-0077.md) (non-reproducible builds). topics: - - The in‑app update mechanism isn't used at all (CWE-693). - - The update enforcement occurs purely locally (client‑side) without server‑side checks (CWE-602). + - intentionally introduced malicious code / insider threat + - malicious or compromised third-party SDKs and dependencies (supply-chain) + - backdoors and hidden functionality + - build-tool / build-pipeline compromise + - detecting malicious code (code review, SCA, behavioral analysis) status: placeholder --- - diff --git a/weaknesses/MASVS-CODE/MASWE-0077.md b/weaknesses/MASVS-CODE/MASWE-0077.md index d0ece2d..e786626 100644 --- a/weaknesses/MASVS-CODE/MASWE-0077.md +++ b/weaknesses/MASVS-CODE/MASWE-0077.md @@ -1,21 +1,30 @@ --- -title: Running on a recent Platform Version Not Ensured +title: Non-Reproducible Builds id: MASWE-0077 -alias: run-on-recent-platform-version +alias: non-reproducible-builds platform: [android, ios] profiles: [L2] mappings: - masvs-v2: [MASVS-CODE-1] - cwe: [693, 1357] + masvs-v2: [MASVS-CODE-3] + cwe: [1357, 494] +refs: +- https://reproducible-builds.org/ +- https://slsa.dev/ draft: - description: e.g. via minSdkVersion on Android and MinimumOSVersion on iOS. with - this we Ensure services/components availability (MASVS-STORAGE-1), also the NSC/ATS - availability - Android > 7.0 / iOS > 9.0 (MASVS-NETWORK-1) and WebView secure - config (MASVS-PLATFORM-2). + description: | + A build is reproducible when compiling the same source with the same build environment + always yields a bit-for-bit identical artifact. When builds are not reproducible, it is + impossible for a third party (or the developer) to independently verify that a distributed + binary was built from the claimed, unmodified source, which weakens supply-chain integrity + and makes it harder to detect tampering or injected malicious code. Reproducible builds, + together with build provenance/attestation (e.g. SLSA), let stakeholders verify the + integrity of released artifacts. topics: - - The app sets a low minimum OS version to support older devices, but still relies, implicitly or explicitly, on security features (e.g., runtime permissions, hardware-backed keystore, network security policies) that may not exist on those versions (CWE-693 and CWE-1357). + - non-deterministic build outputs (timestamps, paths, ordering, embedded environment data) + - inability to independently verify a released binary against its source + - build provenance and attestation (e.g. SLSA) + - pinned, controlled, and documented build environments/toolchains status: placeholder --- - diff --git a/weaknesses/MASVS-CODE/MASWE-0079.md b/weaknesses/MASVS-CODE/MASWE-0079.md deleted file mode 100644 index afaad75..0000000 --- a/weaknesses/MASVS-CODE/MASWE-0079.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -title: Unsafe Handling of Data from the Network -id: MASWE-0079 -alias: unsafe-network-data -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v2: [MASVS-CODE-4] - cwe: [924] - -draft: - description: Data received from the network should be treated as untrusted even if it is received over a secure channel. - topics: - - network -status: placeholder - ---- - diff --git a/weaknesses/MASVS-CODE/MASWE-0080.md b/weaknesses/MASVS-CODE/MASWE-0080.md deleted file mode 100644 index c064ad5..0000000 --- a/weaknesses/MASVS-CODE/MASWE-0080.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: Unsafe Handling of Data from Backups -id: MASWE-0080 -alias: unsafe-backup-data -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v2: [MASVS-CODE-4] - cwe: [349] - -refs: -- https://developer.android.com/guide/topics/data/keyvaluebackup#RestoreVersion -draft: - description: The app does not validate restored backup data, potentially accepting untrusted modifications alongside trusted data (CWE-349). - topics: - - backup data validation - - backup data integrity -status: placeholder - ---- - diff --git a/weaknesses/MASVS-CODE/MASWE-0081.md b/weaknesses/MASVS-CODE/MASWE-0081.md deleted file mode 100644 index 0d4f32d..0000000 --- a/weaknesses/MASVS-CODE/MASWE-0081.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: Unsafe Handling Of Data From External Interfaces -id: MASWE-0081 -alias: unsafe-external-data -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v2: [MASVS-CODE-4] - cwe: [924] - -draft: - description: When data is received from external interfaces (e.g. Bluetooth, NFC, - etc.), it should be treated as untrusted. - topics: - - Bluetooth - - NFC -status: placeholder - ---- - diff --git a/weaknesses/MASVS-CODE/MASWE-0082.md b/weaknesses/MASVS-CODE/MASWE-0082.md deleted file mode 100644 index 335765f..0000000 --- a/weaknesses/MASVS-CODE/MASWE-0082.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: Unsafe Handling of Data From Local Storage -id: MASWE-0082 -alias: unsafe-local-storage -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v2: [MASVS-CODE-4] - cwe: [20, 22, 73, 349] - -refs: -- https://developer.android.com/topic/security/risks/path-traversal -- https://developer.android.com/topic/security/risks/zip-path-traversal -draft: - description: When data is read from local storage, it should be treated as untrusted. - topics: - - Internal Storage - - External Storage - - UIDocumentPickerViewController used by the receiver app - - The app does not validate or sanitize input from local storage, which may lead to injection vulnerabilities when the data is interpreted or used in sensitive operations (CWE-20). - - The app does not validate or sanitize file paths read from local storage, enabling potential path traversal attacks (CWE-22). - - Paths to local files are influenced by attacker-controlled input, and their content can be modified (common in external storage or document pickers), leading to unintended file access or tampering (CWE-73). - - The app processes data from local storage as if it were inherently trustworthy, without isolating or verifying it, allowing attackers to alter app state or behavior (CWE-349). -status: placeholder - ---- - diff --git a/weaknesses/MASVS-CODE/MASWE-0083.md b/weaknesses/MASVS-CODE/MASWE-0083.md deleted file mode 100644 index 6dea879..0000000 --- a/weaknesses/MASVS-CODE/MASWE-0083.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: Unsafe Handling of Data From The User Interface -id: MASWE-0083 -alias: unsafe-ui-data -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v1: [MSTG-PLATFORM-2] - masvs-v2: [MASVS-CODE-4, MASVS-PLATFORM-3] - cwe: [345, 348] - -draft: - description: e.g. text fields, QR codes, URLs, pasteboard, etc. - topics: - - text Fields - - QR Codes - - URLs - - Pasteboard -status: placeholder - ---- - diff --git a/weaknesses/MASVS-CODE/MASWE-0084.md b/weaknesses/MASVS-CODE/MASWE-0084.md deleted file mode 100644 index 7436569..0000000 --- a/weaknesses/MASVS-CODE/MASWE-0084.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: Unsafe Handling of Data from IPC -id: MASWE-0084 -alias: unsafe-ipc-data -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v1: [MSTG-PLATFORM-2] - masvs-v2: [MASVS-CODE-4, MASVS-PLATFORM-1] - cwe: [20, 345, 349] - -draft: - description: e.g. received intents, broadcast receivers, URL validation, URL schemes, - etc. - topics: - - The app does not validate or sanitize input received through inter-process communication channels (e.g., intents, content URIs, broadcast receivers), which may lead to injection or logic vulnerabilities when the data is used in sensitive operations (CWE-20). - - The app assumes that data received from other apps via IPC is trustworthy, without verifying its authenticity or origin (CWE-345). - - The app combines untrusted IPC data with trusted inputs or internal state, which may allow attackers to influence app behavior or corrupt logic flows (CWE-349). -status: placeholder - ---- - diff --git a/weaknesses/MASVS-CODE/MASWE-0085.md b/weaknesses/MASVS-CODE/MASWE-0085.md deleted file mode 100644 index 009c022..0000000 --- a/weaknesses/MASVS-CODE/MASWE-0085.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: Unsafe Dynamic Code Loading -id: MASWE-0085 -alias: unsafe-code-loading -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v2: [MASVS-CODE-4] - cwe: [494] - -draft: - description: e.g. when using dlopen, DexClassLoader, etc. - topics: - - dlopen - - DexClassLoader -status: placeholder - ---- - diff --git a/weaknesses/MASVS-CODE/MASWE-0086.md b/weaknesses/MASVS-CODE/MASWE-0086.md deleted file mode 100644 index 1431757..0000000 --- a/weaknesses/MASVS-CODE/MASWE-0086.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: SQL Injection -id: MASWE-0086 -alias: sql-injection -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v2: [MASVS-CODE-4] - cwe: [89] - -refs: -- https://developer.android.com/topic/security/risks/sql-injection -draft: - description: e.g. prepared statements with variable binding (i.e. parameterized - queries) - topics: - - not using prepared statements -status: placeholder - ---- - diff --git a/weaknesses/MASVS-CODE/MASWE-0087.md b/weaknesses/MASVS-CODE/MASWE-0087.md deleted file mode 100644 index bc2c70d..0000000 --- a/weaknesses/MASVS-CODE/MASWE-0087.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: Insecure Parsing and Escaping -id: MASWE-0087 -alias: insecure-parsing-escaping -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v2: [MASVS-CODE-4] - cwe: [116, 611] - -draft: - description: e.g. XML External Entity (XXE) attacks, X509 certificate parsing, character escaping. - topics: - - The app does not properly escape or encode special characters when handling structured output formats (e.g., HTML, XML, JSON), which may lead to injection or rendering issues in downstream components (CWE-116). - - The app parses XML input without restricting external entity resolution, allowing XML External Entity (XXE) attacks that can expose files, initiate SSRF, or disrupt app logic (CWE-611). -status: placeholder - ---- - diff --git a/weaknesses/MASVS-CODE/MASWE-0088.md b/weaknesses/MASVS-CODE/MASWE-0088.md deleted file mode 100644 index 08870c6..0000000 --- a/weaknesses/MASVS-CODE/MASWE-0088.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: Insecure Object Deserialization -id: MASWE-0088 -alias: insecure-deserialization -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v2: [MASVS-CODE-4] - cwe: [502] - android-risks: - - https://developer.android.com/privacy-and-security/risks/unsafe-deserialization -draft: - description: e.g. XML, JSON, java.io.Serializable, Parcelable on Android or NSCoding - on iOS. - topics: - - XML - - JSON - - java.io.Serializable - - Parcelable - - NSCoding -status: placeholder -refs: -- https://i.blackhat.com/EU-22/Wednesday-Briefings/EU-22-Ke-Android-Parcels-Introducing-Android-Safer-Parcel.pdf -- https://github.com/michalbednarski/ReparcelBug2 -- https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html -- https://blog.oversecured.com/Exploiting-memory-corruption-vulnerabilities-on-Android ---- - diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0007.md b/weaknesses/MASVS-CRYPTO/MASWE-0007.md new file mode 100644 index 0000000..763f983 --- /dev/null +++ b/weaknesses/MASVS-CRYPTO/MASWE-0007.md @@ -0,0 +1,48 @@ +--- +title: Improper Cryptographic Key Generation +id: MASWE-0007 +alias: weak-crypto-key-generation +platform: [android, ios] +profiles: [L1, L2] +mappings: + masvs-v1: [MSTG-CRYPTO-2] + masvs-v2: [MASVS-CRYPTO-2] + cwe: [331, 337, 338, 522] + android-risks: + - https://developer.android.com/privacy-and-security/risks/weak-prng +refs: +- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf +- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf +- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-175Br1.pdf +- https://developer.android.com/privacy-and-security/cryptography +- https://developer.android.com/reference/javax/crypto/KeyGenerator +- https://developer.android.com/reference/kotlin/android/security/keystore/KeyProtection +- https://developer.apple.com/documentation/cryptokit/aes/keywrap +beta-coverage: [MASWE-0009, MASWE-0017] +status: new +--- + +## Overview + +In cryptography, the security strength is heavily influenced by the methods used to generate cryptographic keys. One critical aspect is the key size, also known as the key length, which is measured in bits and must comply with the latest security best practices. Encryption algorithms that use insufficient key sizes are vulnerable to attack, while longer keys typically result in more complex encryption. + +However, even with a sufficiently large key size, the security of the encryption can be compromised if the key generation process is flawed. Failing to use strong, cryptographically secure pseudorandom number generators (CSPRNGs) with sufficient entropy can generate predictable keys that are easier for attackers to guess or reproduce and that are susceptible to repetitive patterns. + +## Impact + +- **Risk of Brute-Force Attacks**: Improper key generation, whether due to shorter key length or predictable random number generator (PRNG) inputs, increases the risk of brute-force attacks. Attackers can more easily guess or systematically try possible keys until they find the correct one. +- **Loss of Confidentiality**: Encryption relies on strong keys to maintain the confidentiality of sensitive data. Seed values with insufficient entropy can allow attackers to decrypt and access confidential information, leading to unauthorized disclosure and potential data breaches. +- **Loss of Integrity**: Improper key generation can compromise data integrity, allowing attackers to exploit vulnerabilities and potentially alter or tamper with the information without detection. + +## Modes of Introduction + +- **Insufficient Entropy**: Using a source of randomness with insufficient entropy can lead to predictable cryptographic keys. +- **Insufficient Key Length**: Cryptographic keys that are too short provide inadequate security. For example, keys shorter than recommended lengths for modern algorithms may be vulnerable to brute force attacks, making them easier for attackers to break. +- **Using Risky or Broken Algorithms**: Relying on deprecated, risky or inherently broken cryptographic algorithms can result in the generation of weaker keys. As these algorithms often have vulnerabilities or support shorter key lengths, they are more susceptible to modern attacks, compromising the overall security of the app. +- **Insecure Key Export**: When a generated key must leave the secure environment in which it was created (for example, to be backed up or shared with another device), exporting it in plaintext exposes it to compromise. Keys should be "wrapped" (encrypted with another key) before export, as specified in [NIST.SP.800-175Br1 5.3.5](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-175Br1.pdf), even when the key is sent over a secure channel. + +## Mitigations + +- Always use modern, well-established cryptographic libraries and APIs that follow best practices for entropy generation and key management. +- When keys must be exported, protect them with key wrapping (e.g. AES Key Wrap or an equivalent authenticated scheme) so they are never exposed in plaintext outside a secure environment. +- Ensure that key lengths meet or exceed current standards for cryptographic security, such as 256-bit for AES encryption and 2048-bit for RSA (considering quantum computing attacks). See ["NIST Special Publication 800-57: Recommendation for Key Management: Part 1 – General"](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf) and ["NIST Special Publication 800-131A: Transitioning the Use of Cryptographic Algorithms and Key Lengths"](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf) and ["BlueKrypt's Cryptographic Key Length Recommendation"](https://www.keylength.com/) for more information on cryptographic key sizes. diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0008.md b/weaknesses/MASVS-CRYPTO/MASWE-0008.md new file mode 100644 index 0000000..6b2b723 --- /dev/null +++ b/weaknesses/MASVS-CRYPTO/MASWE-0008.md @@ -0,0 +1,35 @@ +--- +title: Improper Cryptographic Key Derivation +id: MASWE-0008 +alias: weak-crypto-key-derivation +platform: [android, ios] +profiles: [L1, L2] +mappings: + masvs-v1: [MSTG-CRYPTO-2] + masvs-v2: [MASVS-CRYPTO-2] + cwe: [326, 327, 916] + +refs: +- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf +- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-132.pdf +- https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html +beta-coverage: [MASWE-0010] +draft: + description: | + Cryptographic keys are frequently derived from passwords, passphrases, or other + low-entropy inputs using a Key Derivation Function (KDF). When the KDF is chosen + or configured incorrectly, the derived key is far weaker than intended and can be + recovered through brute-force or dictionary attacks. Common problems include using + a fast, general-purpose hash instead of a dedicated password-based KDF, an + insufficient iteration/work factor, a missing or predictable salt, or deriving keys + from inputs with insufficient entropy. + topics: + - use of a password-based KDF (e.g. PBKDF2, scrypt, Argon2, bcrypt) instead of a plain hash + - insufficient iteration count / work factor (e.g. PBKDF2 with too few iterations) + - missing, hardcoded, or reused salt + - derivation from inputs with insufficient entropy + - selecting KDF parameters per NIST.SP.800-132 and current OWASP guidance +status: placeholder + +--- + diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0009.md b/weaknesses/MASVS-CRYPTO/MASWE-0009.md index 4ae3a54..e3231bd 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0009.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0009.md @@ -1,43 +1,31 @@ --- -title: Improper Cryptographic Key Generation +title: Cryptographic Key Rotation Not Implemented id: MASWE-0009 -alias: weak-crypto-key-generation +alias: no-key-rotation platform: [android, ios] -profiles: [L1, L2] +profiles: [L2] mappings: - masvs-v1: [MSTG-CRYPTO-2] masvs-v2: [MASVS-CRYPTO-2] - cwe: [331, 337, 338] - android-risks: - - https://developer.android.com/privacy-and-security/risks/weak-prng + cwe: [262, 324] + refs: - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf -- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf -- https://developer.android.com/privacy-and-security/cryptography -- https://developer.android.com/reference/javax/crypto/KeyGenerator +- https://developers.google.com/tink/managing-key-rotation +beta-coverage: [MASWE-0011] +draft: + description: | + Cryptographic keys have a limited cryptoperiod after which they should be retired and + replaced. Key rotation limits the amount of data protected by any single key and bounds + the impact of a key compromise. When an app never rotates its keys, a single compromised + key exposes all data ever protected with it. This is especially important for long-lived + keys and asymmetric keys. Rotation must be implemented so that data protected under old + keys can still be decrypted/verified (e.g. via keysets with versioned keys) while new + operations use the current key. + topics: + - long-lived keys and cryptoperiods (as per NIST.SP.800-57pt1r5) + - versioned keysets and graceful re-encryption (e.g. Tink key rotation) + - retiring and destroying superseded keys +status: placeholder -status: new --- -## Overview - -In cryptography, the security strength is heavily influenced by the methods used to generate cryptographic keys. One critical aspect is the key size, also known as the key length, which is measured in bits and must comply with the latest security best practices. Encryption algorithms that use insufficient key sizes are vulnerable to attack, while longer keys typically result in more complex encryption. - -However, even with a sufficiently large key size, the security of the encryption can be compromised if the key generation process is flawed. Failing to use strong, cryptographically secure pseudorandom number generators (CSPRNGs) with sufficient entropy can generate predictable keys that are easier for attackers to guess or reproduce and that are susceptible to repetitive patterns. - -## Impact - -- **Risk of Brute-Force Attacks**: Improper key generation, whether due to shorter key length or predictable random number generator (PRNG) inputs, increases the risk of brute-force attacks. Attackers can more easily guess or systematically try possible keys until they find the correct one. -- **Loss of Confidentiality**: Encryption relies on strong keys to maintain the confidentiality of sensitive data. Seed values with insufficient entropy can allow attackers to decrypt and access confidential information, leading to unauthorized disclosure and potential data breaches. -- **Loss of Integrity**: Improper key generation can compromise data integrity, allowing attackers to exploit vulnerabilities and potentially alter or tamper with the information without detection. - -## Modes of Introduction - -- **Insufficient Entropy**: Using a source of randomness with insufficient entropy can lead to predictable cryptographic keys. -- **Insufficient Key Length**: Cryptographic keys that are too short provide inadequate security. For example, keys shorter than recommended lengths for modern algorithms may be vulnerable to brute force attacks, making them easier for attackers to break. -- **Using Risky or Broken Algorithms**: Relying on deprecated, risky or inherently broken cryptographic algorithms can result in the generation of weaker keys. As these algorithms often have vulnerabilities or support shorter key lengths, they are more susceptible to modern attacks, compromising the overall security of the app. - -## Mitigations - -- Always use modern, well-established cryptographic libraries and APIs that follow best practices for entropy generation and key management. -- Ensure that key lengths meet or exceed current standards for cryptographic security, such as 256-bit for AES encryption and 2048-bit for RSA (considering quantum computing attacks). See ["NIST Special Publication 800-57: Recommendation for Key Management: Part 1 – General"](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf) and ["NIST Special Publication 800-131A: Transitioning the Use of Cryptographic Algorithms and Key Lengths"](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf) and ["BlueKrypt's Cryptographic Key Length Recommendation"](https://www.keylength.com/) for more information on cryptographic key sizes. diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0010.md b/weaknesses/MASVS-CRYPTO/MASWE-0010.md index 847c7a3..c042caa 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0010.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0010.md @@ -1,21 +1,42 @@ --- -title: Improper Cryptographic Key Derivation +title: Cryptographic Key Access Not Restricted id: MASWE-0010 -alias: weak-crypto-key-derivation +alias: crypto-key-access-not-restricted platform: [android, ios] -profiles: [L1, L2] +profiles: [L2] mappings: - masvs-v1: [MSTG-CRYPTO-2] - masvs-v2: [MASVS-CRYPTO-2] - cwe: [326, 327] + masvs-v2: [MASVS-CRYPTO-2, MASVS-AUTH-2, MASVS-AUTH-3] + cwe: [284] refs: -- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf +- https://developer.android.com/reference/android/security/keystore/KeyGenParameterSpec.Builder#setUnlockedDeviceRequired(boolean) +- https://developer.apple.com/documentation/security/ksecattraccessiblewhenunlockedthisdeviceonly +- https://developer.android.com/training/sign-in/biometric-auth#prompt-the-user-to-authenticate-with-biometrics +- https://developer.apple.com/documentation/security/restricting-keychain-item-accessibility +- https://source.android.com/docs/security/features/keystore/strongbox +- https://developer.apple.com/documentation/security/ksecattrtokenidsecureenclave +beta-coverage: [MASWE-0018] draft: - description: e.g. PBKDF2 with insufficient iterations, lack of salt, etc. + description: Ensuring that cryptographic keys are accessible only under strict conditions, + such as when the device is unlocked by an authenticated user, within secure application + contexts, bound to the current device, or for limited periods of time, is critical to maintaining the confidentiality + and integrity of encrypted data. This applies even to keys generated inside a hardware + security module such as Android StrongBox or the iOS Secure Enclave, where access + restrictions (user authentication, unlocked-device requirement, usage authorization) + must still be configured explicitly. topics: - - sources with insufficient entropy - - lack of salt encryption when doing PBKDF2 + - keys generated inside StrongBox / Secure Enclave still requiring access restrictions + - from a Background Process + - locked device (iOS kSecAttrAccessibleWhenUnlockedThisDeviceOnly, Android setUnlockedDeviceRequired) + - device-bound or non-transferable (iOS ThisDeviceOnly) + - time-based access (duration) + - Require User Presence + - application-specific password + - biometric authentication + - key use restricted e.g. requiring user auth with biometrics, User Presence. + - especially for sensitive operations + - keys restricted/authorized for a duration of time or specific crypto operation, + etc. status: placeholder --- diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0011.md b/weaknesses/MASVS-CRYPTO/MASWE-0011.md index fe48560..913c2a2 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0011.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0011.md @@ -1,22 +1,51 @@ --- -title: Cryptographic Key Rotation Not Implemented +title: Improper Encryption id: MASWE-0011 -alias: no-key-rotation +alias: weak-encryption platform: [android, ios] -profiles: [L2] +profiles: [L1, L2] mappings: - masvs-v2: [MASVS-CRYPTO-2] - cwe: [262, 324] + masvs-v1: [MSTG-CRYPTO-4, MSTG-CRYPTO-5] + masvs-v2: [MASVS-CRYPTO-1, MASVS-CRYPTO-2] + cwe: [208, 323, 325, 326, 327, 329, 780] refs: -- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf -- https://developers.google.com/tink/managing-key-rotation -draft: - description: Key rotation is a best practice to limit the impact of a key compromise. - It is especially important for long-lived keys such as asymmetric keys. - topics: - - long-lived keys (cryptoperiods as per NIST.SP.800-57pt1r5) -status: placeholder +- https://support.google.com/faqs/answer/10046138?hl=en +- https://support.google.com/faqs/answer/9450925?hl=en +- https://developer.android.com/privacy-and-security/cryptography#deprecated-functionality +- https://developer.android.com/privacy-and-security/cryptography#pbe-without-iv +- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf +- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Br2.pdf +- https://www.usenix.org/legacy/event/woot10/tech/full_papers/Rizzo.pdf +beta-coverage: [MASWE-0020, MASWE-0012, MASWE-0022, MASWE-0023] +status: new --- +## Overview + +Improper encryption refers to cryptographic systems or implementations that are vulnerable to attack, allowing unauthorized individuals to decrypt secured data. + +## Impact + +- **Loss of Confidentiality**: Improper encryption may enable attackers to decipher and obtain sensitive information, resulting in unauthorized exposure and possible data breaches. +- **Loss of Integrity**: Improper encryption can compromise the integrity of data, allowing adversaries to alter or manipulate the information without detection. + +## Mode of Introduction + +- **Broken Algorithms**: Relying on broken encryption algorithms (i.e., that are deprecated or disallowed by NIST or other standards) such as RC4. +- **Predictable or Reused Initialization Vectors (IVs)**: Using IVs that are hardcoded, null, predictable, or reused in modes like AES-CBC or AES-CTR breaks semantic security, allowing attackers to detect patterns or recover plaintext differences. In AEAD modes like AES-GCM, reusing nonces or using authentication tags of insufficient length compromises both confidentiality and integrity. On Android, use `GCMParameterSpec` (not the legacy `IvParameterSpec`) for GCM. +- **Risky Padding**: Using a padding scheme susceptible to padding oracle attacks (e.g. PKCS#7 with unauthenticated AES-CBC, or PKCS#1 v1.5 for RSA) in combination with observable padding-error signals allows attackers to decrypt or forge ciphertext without the key. See [MASWE-0015](MASWE-0015.md) for signature verification and prefer authenticated encryption. +- **Broken Modes of Operation**: Using modes that are considered broken. For example, AES-ECB is broken due to practical known-plaintext attacks and it's disallowed by NIST. +- **Insufficient Key Length**: The use of insufficient key sizes (e.g., 128-bit keys in AES) can compromise encryption strength making the encryption susceptible to brute-force attacks. +- **Insecure or Wrong Key Usage**: Reusing a single key for multiple purposes (e.g. encryption and signing) or with an unauthorized algorithm violates key-separation principles. Per [NIST.SP.800-57pt1r5](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf), a single key should be used for only one purpose. +- **Non-Cryptographic Operations**: Relying on techniques such as XOR, Base64 encoding, or simple obfuscation methods for security purposes. These methods provide no actual encryption and can be easily reversed or decoded, exposing sensitive data. + +## Mitigations + +- **Use Secure Encryption Modes**: Choose secure, authenticated modes (e.g. approved by NIST) such as `AES/GCM/NoPadding`. If AES-CBC must be used, apply Encrypt-then-MAC (e.g. append HMAC) and, for RSA, prefer OAEP over PKCS#1 v1.5. +- **Ensure Proper Initialization Vector Management**: Generate IVs using cryptographically secure random number generators (with sufficient entropy) and ensure they are unique for every operation; never hardcode, null, or reuse them. +- **Use Sufficiently Long Keys**: Enforce sufficiently long keys such as those approved by NIST, e.g., a minimum of 256 bits for AES. +- **Use Each Key for a Single Purpose**: Derive or generate separate keys for encryption, authentication, and signing, and only use each key with its authorized algorithm. +- **Do Not Expose Cryptographic Errors**: Avoid leaking detailed padding or decryption error messages or timing differences that could serve as an oracle. +- **Rely on Proper Cryptographic Primitives**: Rely on well-vetted cryptographic primitives that have undergone rigorous peer review and formal validation. diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0012.md b/weaknesses/MASVS-CRYPTO/MASWE-0012.md index a1d2c7f..a29784b 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0012.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0012.md @@ -1,23 +1,32 @@ --- -title: Insecure or Wrong Usage of Cryptographic Key +title: Improper Hashing id: MASWE-0012 -alias: insecure-key-usage +alias: improper-hashing platform: [android, ios] -profiles: [L2] +profiles: [L1, L2] mappings: - masvs-v1: [MSTG-CRYPTO-5] - masvs-v2: [MASVS-CRYPTO-2] - cwe: [323] + masvs-v1: [MSTG-CRYPTO-4] + masvs-v2: [MASVS-CRYPTO-1] + cwe: [328] refs: -- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf +- https://developer.android.com/privacy-and-security/cryptography#deprecated-functionality +- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf +- https://en.wikipedia.org/wiki/Collision_attack +- https://csrc.nist.gov/pubs/ir/8547/ipd +beta-coverage: [MASWE-0021] draft: - description: According to NIST.SP.800-57pt1r5, in general, a single key shall be - used for only one purpose (e.g., encryption, integrity, authentication, key wrapping, - random bit generation, or digital signatures) + description: | + Using broken or unsuitable hash functions in a security-sensitive context can + compromise data integrity and authenticity. Broken algorithms such as MD5 and SHA-1 + are vulnerable to collision attacks and must not be used where collision or + second-preimage resistance is required (e.g. digital signatures, integrity checks, + certificate fingerprints). Note that password/passphrase handling requires a + dedicated password-based KDF rather than a plain hash (see [MASWE-0008](MASWE-0008.md)). topics: - - key used together with an authorized algorithm - - key reuse for different purposes or operations (encrypt, decrypt, sign,...) + - broken hashing algorithms (e.g. MD5, SHA-1) + - collision and second-preimage resistance requirements + - selecting an approved hash function (e.g. SHA-256/SHA-3) per NIST guidance status: placeholder --- diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0013.md b/weaknesses/MASVS-CRYPTO/MASWE-0013.md index 907ab4a..660b341 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0013.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0013.md @@ -1,13 +1,35 @@ --- -title: Hardcoded Cryptographic Keys in Use +title: Improper Use of Message Authentication Code (MAC) id: MASWE-0013 -alias: hardcoded-crypto-keys-usage +alias: improper-mac platform: [android, ios] -profiles: [] +profiles: [L1, L2] mappings: - masvs-v1: [MSTG-CRYPTO-1] - masvs-v2: [MASVS-CRYPTO-2] -status: deprecated -covered_by: [MASWE-0014] -deprecation_note: Content overlap. + masvs-v1: [MSTG-CRYPTO-4, MSTG-CRYPTO-5] + masvs-v2: [MASVS-CRYPTO-1, MASVS-CRYPTO-2] + cwe: [323, 327, 807, 915] + +refs: +- https://developer.android.com/privacy-and-security/cryptography#deprecated-functionality +- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf +- https://csrc.nist.gov/pubs/sp/800/224/ipd +- https://datatracker.ietf.org/doc/html/rfc6151 +- https://web.archive.org/web/20170810051504/http://www.tcs.hut.fi/old/papers/aura/aura-csfws97.pdf +- https://en.wikipedia.org/wiki/Replay_attack +beta-coverage: [MASWE-0024, MASWE-0012] +draft: + description: Improper use of MACs in security sensitive contexts affecting data integrity. + topics: + - Using a MAC key for more than one purpose or with an unauthorized algorithm (key separation) + - Using HMAC with keys with insufficient entropy + - Using HMAC with missing timestamp (or nonce) + - Using MAC‑then‑encrypt or encrypt‑then‑MAC incorrectly, leaking information via timing or error messages + - Allowing predictors (users or attackers) to control data inputs, creating scenarios where forged or replayed tags bypass integrity checks. + - Hash functions lacking collision resistance (e.g., MD5 or SHA‑1 used in HMAC) + - Use of non‑cryptographic checksums (e.g., CRC‑32 instead of HMAC) + - MAC constructions that fail outside narrow assumptions (e.g., raw CBC‑MAC on variable‑length messages) + - Tags that are too short significantly lower the effort required for forgery +status: placeholder + --- + diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0014.md b/weaknesses/MASVS-CRYPTO/MASWE-0014.md index 5ff7f5a..cdd9c53 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0014.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0014.md @@ -1,43 +1,34 @@ --- -title: Cryptographic Keys Not Properly Protected at Rest +title: Improper Generation of Cryptographic Signatures id: MASWE-0014 -alias: crypto-keys-not-protected-at-rest +alias: improper-signature-generation platform: [android, ios] profiles: [L1, L2] mappings: - masvs-v1: [MSTG-STORAGE-1] - masvs-v2: [MASVS-CRYPTO-2, MASVS-STORAGE-1] - cwe: [312, 318, 321] - android-risks: - - https://developer.android.com/privacy-and-security/risks/hardcoded-cryptographic-secrets -refs: -- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf -- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-175Br1.pdf -status: new ---- - -## Overview - -Cryptographic keys are essential for securing sensitive data in mobile applications. However, if these keys are not properly protected at rest, they can be easily compromised. This weakness involves storing cryptographic keys in insecure locations, such as unencrypted SharedPreferences, unprotected files, hardcoding them within the application code, or including them in source control and versioning systems which may end in the final application package in production. - -Attackers can decompile or reverse-engineer the app to extract hardcoded keys. + masvs-v1: [MSTG-CRYPTO-4, MSTG-CRYPTO-5] + masvs-v2: [MASVS-CRYPTO-1, MASVS-CRYPTO-2] + cwe: [323, 327] -## Impact - -- **Unauthorized Access**: If cryptographic keys are not properly protected, attackers may gain unauthorized access to sensitive data and potential identity theft. -- **Loss of Integrity**: Compromised keys can allow attackers to tamper with encrypted data. -- **Loss of Confidentiality**: Sensitive information can be exposed, resulting in a loss of confidentiality. Once keys are exposed, all data encrypted with those keys is at risk. - -## Modes of Introduction - -- **Insecure Storage Locations**: Storing cryptographic keys in locations that are not designed for secure storage, such as regular configuration or user preferences files, application data directories, or other areas lacking encryption and access control mechanisms. -- **Hardcoded Cryptographic Keys**: Including cryptographic keys directly in the application code, making them susceptible to extraction through decompilation and reverse-engineering. -- **Insecure Imported Keys**: Importing cryptographic keys from untrusted sources or without validating their integrity, which can lead to the introduction of malicious or compromised keys into the application environment. +refs: +- https://developer.android.com/privacy-and-security/cryptography#deprecated-functionality +- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf +- https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf +- https://csrc.nist.gov/pubs/ir/8547/ipd +beta-coverage: [MASWE-0025, MASWE-0012] +draft: + description: | + Cryptographic signatures must be generated with algorithms and parameters of + sufficient strength to guarantee integrity and authenticity. Using weak or deprecated + schemes (e.g. SHA1withRSA), short keys, or reusing a signing key for other purposes + undermines the signature's security and can allow forgery. Randomness used during + signing (e.g. the per-signature nonce in (EC)DSA) must be unpredictable and unique. + topics: + - weak or deprecated signature algorithms (e.g. SHA1withRSA) + - insufficient key length for the signing algorithm + - predictable or reused per-signature nonce in (EC)DSA + - using a signing key for more than one purpose (key separation) + - selecting approved signature schemes per NIST FIPS 186-5 +status: placeholder -## Mitigations +--- -- **Use Platform Keystores**: Where possible, generate cryptographic keys dynamically on the device, rather than using predefined keys, and ensure that they are securely stored after creation. For this you can use the platform-specific keystores, such as the [Android KeyStore](https://developer.android.com/training/articles/keystore) or [iOS KeyChain](https://developer.apple.com/documentation/security/keychain_services). -- **Implement Strongest Hardware Security Solutions**: For the most critical cases and whenever [available and compatible](https://developer.android.com/privacy-and-security/keystore#HardwareSecurityModule) for the use case at hand, leverage the strongest hardware-backed security options such as [Android StrongBox](https://source.android.com/docs/security/features/keystore/strongbox) or iOS's Secure Enclave [`kSecAttrTokenIDSecureEnclave`](https://developer.apple.com/documentation/security/ksecattrtokenidsecureenclave) option to ensure the highest protection including physical and side-channel attacks. -- **Use Cryptographic Key Management Systems**: Securely retrieve keys from server-side services that provide secure storage, access control, and auditing for sensitive data. For example, AWS Secrets Manager, Azure Key Vault, or Google Cloud Secret Manager are some popular managed secrets storage solutions. The app can securely retrieve the necessary secrets at runtime through secure, authenticated API calls. -- **Encrypt and Wrap Keys**: Whenever storing keys in platform keystores is not suitable for the use case or keys need to be exported, use envelope encryption (DEK+KEK) and key wrapping techniques as specified in [NIST.SP.800-175Br1 5.3.5](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-175Br1.pdf) to protect cryptographic keys before storing them. -- **Follow Standard Key Management Best Practices**: Implement proper key management practices, including key rotation and robust protection mechanisms for keys in storage as outlined in [NIST.SP.800-57pt1r5 6.2.2](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf), ensuring availability, integrity, confidentiality, and proper association with usage, entities, and related information. diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0015.md b/weaknesses/MASVS-CRYPTO/MASWE-0015.md index 0ac41a7..4c5fe52 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0015.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0015.md @@ -1,22 +1,31 @@ --- -title: Deprecated Android KeyStore Implementations +title: Improper Verification of Cryptographic Signature id: MASWE-0015 -alias: deprecated-keystore -platform: [android] -profiles: [L2] +alias: improper-signature-verification +platform: [android, ios] +profiles: [L1, L2] mappings: masvs-v1: [MSTG-CRYPTO-4] - masvs-v2: [MASVS-CRYPTO-2, MASVS-CODE-3] - cwe: [327, 477, 522] + masvs-v2: [MASVS-CRYPTO-1] + cwe: [347] refs: -- https://labs.withsecure.com/publications/how-secure-is-your-android-keystore-authentication -- https://developer.android.com/reference/java/security/KeyStore -- https://developer.android.com/about/versions/12/behavior-changes-all#bouncy-castle +- https://cwe.mitre.org/data/definitions/347.html +- https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf +beta-coverage: [MASWE-0026] draft: - description: Avoid deprecated implementations such as BKS + description: | + Cryptographic signature verification must be implemented correctly to guarantee the + integrity and authenticity of data. Common failures include skipping verification + entirely, ignoring or not checking the verification result, accepting signatures from + untrusted or unpinned keys, failing to validate the full certificate/trust chain, or + using algorithms and parameters that do not match the signer's. Any of these lets an + attacker present forged or tampered data as authentic. topics: - - Bouncy Castle (BKS) + - verification result not checked or ignored + - accepting signatures without validating the signer's key/trust chain + - algorithm confusion or accepting weak/deprecated signature algorithms + - verifying against attacker-controllable public keys status: placeholder --- diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0016.md b/weaknesses/MASVS-CRYPTO/MASWE-0016.md index a81a5ca..c5f9a1a 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0016.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0016.md @@ -1,26 +1,42 @@ --- -title: Unsafe Handling of Imported Cryptographic Keys +title: Improper Random Number Generation id: MASWE-0016 -alias: unsafe-imported-key-handling -platform: [android, ios] -profiles: [L2] +alias: improper-random-number-generation +platform: ["android", "ios"] +profiles: ["L1", "L2"] mappings: - masvs-v2: [MASVS-CRYPTO-2, MASVS-CODE-4] - cwe: [322] - -refs: -- https://mas.owasp.org/MASTG/0x05d-Testing-Data-Storage/#secure-key-import-into-keystore -- https://developer.android.com/privacy-and-security/keystore#ImportingEncryptedKeys -- https://developer.android.com/reference/kotlin/android/security/keystore/KeyProtection -- https://developer.apple.com/documentation/security/certificate_key_and_trust_services/keys/storing_keys_as_data#2933724 -draft: - description: Importing keys without validating their origin or integrity, or using - insecure custom key exchange protocols, can inadvertently introduce malicious - or compromised keys into the app environment. - topics: - - key import from untrusted sources - - key import from untrusted storage -status: placeholder - + masvs-v1: [MSTG-CRYPTO-6] + masvs-v2: [MASVS-CRYPTO-1] + cwe: [332, 337, 338] + android-risks: + - https://developer.android.com/privacy-and-security/risks/weak-prng +observed_examples: +- https://nvd.nist.gov/vuln/detail/CVE-2013-6386 +- https://nvd.nist.gov/vuln/detail/CVE-2013-6386 +- https://nvd.nist.gov/vuln/detail/CVE-2006-3419 +- https://nvd.nist.gov/vuln/detail/CVE-2008-4102 +- https://www.zellic.io/blog/proton-dart-flutter-csprng-prng/ +beta-coverage: [MASWE-0027] +status: new --- +## Overview + +A [pseudorandom number generator (PRNG)](https://en.wikipedia.org/wiki/Pseudorandom_number_generator) algorithm generates sequences based on a seed with insufficient entropy that may be predictable. Common implementations are not cryptographically secure. For example, they typically use a linear congruential formula, allowing an attacker to predict future outputs, given enough observed outputs. Therefore, it is not suitable for security-critical applications or protecting sensitive data. + +## Impact + +- **Bypass Protection Mechanism**: Using a non-cryptographically secure PRNG in a security context, such as authentication, poses significant risks. An attacker could potentially guess the generated numbers and gain access to privileged data or functionality. Predicting or regenerating random numbers can lead to encryption breaches, compromise sensitive user information, or enable user impersonation. + +## Modes of Introduction + +- **Risky Random APIs**: The app may use many existing APIs to generate random numbers with insufficient entropy. +- **Non-random Sources**: The app may use custom methods to create "supposedly random" values, using non-random sources such as the current time. + +## Mitigations + +For security-relevant contexts, use cryptographically secure random numbers. + +In general, it is strongly recommended not to use any random function in a deterministic way, even if it's a secure one, especially those involving hardcoded seed values (which are vulnerable to exposure by decompilation). + +Refer to the [RFC 1750 - Randomness Recommendations for Security](https://www.ietf.org/rfc/rfc1750.txt) and the [OWASP Cryptographic Storage Cheat Sheet - Secure Random Number Generation](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html#secure-random-number-generation) for more information and recommendations on random number generation. diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0017.md b/weaknesses/MASVS-CRYPTO/MASWE-0017.md deleted file mode 100644 index 1cef7d0..0000000 --- a/weaknesses/MASVS-CRYPTO/MASWE-0017.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: Cryptographic Keys Not Properly Protected on Export -id: MASWE-0017 -alias: crypto-keys-not-protected-export -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v2: [MASVS-CRYPTO-2, MASVS-STORAGE-1, MASVS-NETWORK-1] - cwe: [522] - -refs: -- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf -- https://developer.android.com/reference/kotlin/android/security/keystore/KeyProtection -- https://developer.apple.com/documentation/cryptokit/aes/keywrap -- https://developer.apple.com/documentation/security/certificate_key_and_trust_services/keys/storing_keys_as_data#2933723 -draft: - description: Before exporting, keys should be "wrapped" or encrypted with another - key. This process ensures that the cryptographic key is protected during and after - export. This is true even if the key is sent over a secure channel. - topics: - - key wrapping (NIST.SP.800-175Br1 5.3.5) -status: placeholder - ---- - diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0018.md b/weaknesses/MASVS-CRYPTO/MASWE-0018.md deleted file mode 100644 index 6375f12..0000000 --- a/weaknesses/MASVS-CRYPTO/MASWE-0018.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: Cryptographic Keys Access Not Restricted -id: MASWE-0018 -alias: crypto-key-access-not-restricted -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v2: [MASVS-CRYPTO-2, MASVS-AUTH-2, MASVS-AUTH-3] - cwe: [284] - -refs: -- https://developer.android.com/reference/android/security/keystore/KeyGenParameterSpec.Builder#setUnlockedDeviceRequired(boolean) -- https://developer.apple.com/documentation/security/ksecattraccessiblewhenunlockedthisdeviceonly -- https://developer.android.com/training/sign-in/biometric-auth#prompt-the-user-to-authenticate-with-biometrics -- https://developer.apple.com/documentation/security/restricting-keychain-item-accessibility -draft: - description: Ensuring that cryptographic keys are accessible only under strict conditions, - such as when the device is unlocked by an authenticated user, within secure application - contexts, bound to the current device, or for limited periods of time, is critical to maintaining the confidentiality - and integrity of encrypted data. - topics: - - from a Background Process - - locked device (iOS kSecAttrAccessibleWhenUnlockedThisDeviceOnly, Android setUnlockedDeviceRequired) - - device-bound or non-transferable (iOS ThisDeviceOnly) - - time-based access (duration) - - Require User Presence - - application-specific password - - biometric authentication - - key use restricted e.g. requiring user auth with biometrics, User Presence. - - especially for sensitive operations - - keys restricted/authorized for a duration of time or specific crypto operation, - etc. -status: placeholder - ---- - diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0019.md b/weaknesses/MASVS-CRYPTO/MASWE-0019.md deleted file mode 100644 index 31628cb..0000000 --- a/weaknesses/MASVS-CRYPTO/MASWE-0019.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -title: Risky Cryptography Implementations -id: MASWE-0019 -alias: potentially-weak-crypto-impl -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v1: [MSTG-CRYPTO-2] - masvs-v2: [MASVS-CRYPTO-1, MASVS-CODE-3] - mastg-v1: [MASTG-TEST-0061, MASTG-TEST-0014] - cwe: [326, 327, 1240] - -refs: - - https://book.hacktricks.xyz/crypto-and-stego/cryptographic-algorithms - - https://eudl.eu/pdf/10.4108/eai.3-12-2015.2262471 - - https://www.scitepress.org/papers/2014/50563/50563.pdf - - https://pure.tugraz.at/ws/portalfiles/portal/23858147/main.pdf - - https://github.com/Wind-River/crypto-detector - - https://github.com/Rami114/cryptoscan/ - - https://github.com/IAIK/CryptoSlice - - https://developer.android.com/reference/javax/crypto/Cipher#getInstance(java.lang.String) - - https://developer.android.com/privacy-and-security/security-gms-provider - - https://developer.android.com/privacy-and-security/cryptography#bc-algorithms - - https://developer.android.com/privacy-and-security/cryptography#jetpack_security_crypto_library - - https://developer.android.com/privacy-and-security/cryptography#crypto_provider - - https://developer.android.com/privacy-and-security/cryptography#deprecated-functionality - - https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf?__blob=publicationFile ---- - -## Overview - -Risky or noncompliant cryptographic implementations, such as those that do not meet established security standards such as FIPS 140-2/3 (Federal Information Processing Standards), may use algorithms that have not been sufficiently tested or that lack certification, may not follow best practices for secure key management, or may include custom cryptographic solutions that haven't undergone rigorous peer review or formal validation. - -## Impact - -Custom cryptographic implementations created without following established standards make them more susceptible to attacks such as brute force or differential cryptanalysis. In addition, cryptography is notoriously difficult to implement correctly, and even small errors in a custom solution, such as incorrect padding or faulty random number generation, can completely undermine the security of the system, exposing sensitive data to attackers. - -The impact associated with such defects can be very broad and difficult to predict or measure: - -- **Data breaches**: Risky cryptography implementations can lead to unauthorized access to sensitive data, resulting in data breaches. -- **Compromised confidentiality, integrity, and authenticity**: The core principles of cryptography (confidentiality, integrity, and authenticity) are compromised. Attackers can decrypt, manipulate, or impersonate legitimate users or systems. - -## Modes of Introduction - -- **Deviation from standard libraries**: Not using well-known libraries for cryptography, such as those provided by the platforms like Conscrypt or CryptoKit, or other well-established libraries like OpenSSL, BouncyCastle, etc. -- **Use of cryptographic constants**: Hardcoded cryptographic constants are typically used to implement cryptographic algorithms. These constants include S-boxes (substitution boxes) for block ciphers, permutation tables, etc. -- **Use of low-level mathematical operations**: Low-level mathematical operations (such as bitwise operations, shifts, custom padding schemes) typically used in cryptographic algorithms. -- **High entropy code**: An indicator of cryptographic implementations or heavily obfuscated code that may hide cryptographic algorithms from reverse engineering. -- **Use of non-cryptographic functions**: Non-cryptographic functions such as Base64 encoding or XOR instead of encryption. - -## Mitigations - -- **Use standard cryptographic libraries and avoid custom cryptography**: Avoid developing custom cryptographic algorithms or protocols. Always prefer well-established and widely accepted cryptographic libraries such as OpenSSL, BoringSSL, or platform-specific libraries such as Android's Conscrypt and Apple's CryptoKit. These libraries have undergone extensive testing and are regularly updated to address new security threats. - -- **Ensure compliance with security standards**: If you can't avoid using custom cryptography, make sure it's implemented to meet industry standards such as FIPS 140-2/3 (Federal Information Processing Standards) or the latest National Institute of Standards and Technology (NIST) recommendations. -- **Perform periodic security audits**: If using custom cryptography is unavoidable, perform regular security audits (including thorough code reviews) to identify and remediate any flaws in your custom cryptographic implementations. Engage external security experts to provide an unbiased assessment. diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0020.md b/weaknesses/MASVS-CRYPTO/MASWE-0020.md deleted file mode 100644 index 81cbb8f..0000000 --- a/weaknesses/MASVS-CRYPTO/MASWE-0020.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: Improper Encryption -id: MASWE-0020 -alias: weak-encryption -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v1: [MSTG-CRYPTO-4] - masvs-v2: [MASVS-CRYPTO-1] - cwe: [326] - -refs: -- https://support.google.com/faqs/answer/10046138?hl=en -- https://support.google.com/faqs/answer/9450925?hl=en -- https://developer.android.com/privacy-and-security/cryptography#deprecated-functionality -- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf - -status: new - ---- - -## Overview - -Improper encryption refers to cryptographic systems or implementations that are vulnerable to attack, allowing unauthorized individuals to decrypt secured data. - -## Impact - -- **Loss of Confidentiality**: Improper encryption may enable attackers to decipher and obtain sensitive information, resulting in unauthorized exposure and possible data breaches. -- **Loss of Integrity**: Improper encryption can compromise the integrity of data, allowing adversaries to alter or manipulate the information without detection. - -## Mode of Introduction - -- **Broken Algorithms**: Relying on broken encryption algorithms (i.e., that are deprecated or disallowed by NIST or other standards) such as RC4. -- **Risky Algorithm Configurations**: Using IVs with insufficient entropy or reusing them in modes like AES-CBC or AES-CTR breaks semantic security, allowing attackers to detect patterns or recover plaintext differences. In AEAD modes like AES-GCM, reusing nonces or using authentication tags of insufficient length compromises both confidentiality and integrity. -- **Broken Modes of Operation**: Using modes that are considered broken. For example, AES-ECB is broken due to practical known-plaintext attacks and it's disallowed by NIST. -- **Insufficient Key Length**: The use of insufficient key sizes (e.g., 128-bit keys in AES) can compromise encryption strength making the encryption susceptible to brute-force attacks. -- **Non-Cryptographic Operations**: Relying on techniques such as XOR, Base64 encoding, or simple obfuscation methods for security purposes. These methods provide no actual encryption and can be easily reversed or decoded, exposing sensitive data. - -## Mitigations - -- **Use Secure Encryption Modes**: Choose secure modes (e.g. approved by NIST) such as `AES/GCM/NoPadding`. -- **Ensure Proper Initialization Vector Management**: Generate IVs using cryptographically secure random number generators (with sufficient entropy) and ensure they are unique for every operation. -- **Use Sufficiently Long Keys**: Enforce sufficiently long keys such as those approved by NIST, e.g., a minimum of 256 bits for AES. -- **Rely on Proper Cryptographic Primitives**: Rely on well-vetted cryptographic primitives that have undergone rigorous peer review and formal validation. diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0021.md b/weaknesses/MASVS-CRYPTO/MASWE-0021.md deleted file mode 100644 index 4d19d10..0000000 --- a/weaknesses/MASVS-CRYPTO/MASWE-0021.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: Improper Hashing -id: MASWE-0021 -alias: improper-hashing -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v1: [MSTG-CRYPTO-4] - masvs-v2: [MASVS-CRYPTO-1] - cwe: [328] - -refs: -- https://developer.android.com/privacy-and-security/cryptography#deprecated-functionality -- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf -- https://en.wikipedia.org/wiki/Collision_attack -- https://csrc.nist.gov/pubs/ir/8547/ipd -draft: - description: Utilizing broken hashing algorithms such as MD5 and SHA1 in a security - sensitive context may compromise data integrity and authenticity. - topics: - - Broken hashing algorithms (e.g. MD5, SHA1, etc.) -status: placeholder - ---- - diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0022.md b/weaknesses/MASVS-CRYPTO/MASWE-0022.md deleted file mode 100644 index 7ad15f6..0000000 --- a/weaknesses/MASVS-CRYPTO/MASWE-0022.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: Predictable Initialization Vectors (IVs) -id: MASWE-0022 -alias: predictable-ivs -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v1: [MSTG-CRYPTO-4] - masvs-v2: [MASVS-CRYPTO-1] - cwe: [329] - -refs: -- https://developer.android.com/privacy-and-security/cryptography#pbe-without-iv -draft: - description: The use of predictable IVs (hardcoded, null, reused) in a security - sensitive context can weaken data encryption strength and potentially compromise - confidentiality. - topics: - - not use the IvParameterSpec.class anymore for GCM, use the GCMParameterSpec.class - instead (Android) - - Hardcoded IVs - - Null IVs - - Reused IVs -status: placeholder - ---- - diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0023.md b/weaknesses/MASVS-CRYPTO/MASWE-0023.md deleted file mode 100644 index 24d09b7..0000000 --- a/weaknesses/MASVS-CRYPTO/MASWE-0023.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: Risky Padding -id: MASWE-0023 -alias: risky-padding -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v1: [MSTG-CRYPTO-4] - masvs-v2: [MASVS-CRYPTO-1] - mastg-v1: [MASTG-TEST-0014] - cwe: [208, 325, 327, 780] - -refs: -- https://developer.android.com/privacy-and-security/cryptography#deprecated-functionality -- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf -- https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf?__blob=publicationFile -- https://www.usenix.org/legacy/event/woot10/tech/full_papers/Rizzo.pdf -- https://capec.mitre.org/data/definitions/463.html -- https://robertheaton.com/2013/07/29/padding-oracle-attack/ -- https://cryptopals.com/sets/3/challenges/17 -- https://medium.com/@masjadaan/oracle-padding-attack-a61369993c86 -status: new ---- - -## Overview - -[Padding oracle attacks](https://www.usenix.org/legacy/event/woot10/tech/full_papers/Rizzo.pdf) are a type of side-channel exploit that lets attackers decrypt or manipulate data **without** knowing the key. These attacks aren't due to the padding scheme bring broken itself, they arise when the app reveals whether a padding error occurred (through error messages or timing differences), creating an **oracle**. By submitting modified ciphertexts and observing the app's response, an attacker can gradually recover plaintext or forge ciphertext, compromising both confidentiality and integrity. - -Below are two common examples of cryptographic contexts where risky padding can become a problem: - -- **Symmetric Cryptography**: In block cipher modes (e.g., AES-CBC), **PKCS#7 padding** is widely used and it's not broken (not disallowed by NIST). However, it becomes vulnerable to padding oracle attacks if the system leaks detailed error messages or timing differences. To mitigate this, cryptographers often use **authenticated encryption modes** like AES-GCM or pair AES-CBC with a separate integrity check (e.g., HMAC in an Encrypt-then-MAC scheme). -- **Asymmetric Cryptography**: With RSA, **PKCS#1 v1.5** is known to be susceptible to attacks such as [Bleichenbacher](https://link.springer.com/content/pdf/10.1007/BFb0055716.pdf) (based on padding oracles). This older scheme is now discouraged or disallowed by various standards (for example, see [RFC 8017, Section 7.2](https://datatracker.ietf.org/doc/html/rfc8017#section-7.2) from November 2016 or [NIST SP 800-131A Rev.2, Section 6](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf) from March 2019). - -However, simply using a padding scheme susceptible to padding oracle attacks does not guarantee a vulnerability. As mentioned above, the app must **also** leak information (the "oracle") that indicates whether a padding error has occurred. If both conditions are met, attackers can use these signals to recover sensitive data or to craft malicious ciphertext. - -## Impact - -- **Loss of Integrity**: Attackers can modify ciphertext, exploiting the padding oracle to trick the system into accepting maliciously altered data, leading to unauthorized data modifications. -- **Loss of Confidentiality**: Attackers can use the padding oracle to iteratively decrypt sensitive information, such as passwords or session tokens, leading to exposure of confidential data. - -## Modes of Introduction - -- **Unauthenticated Padding for Symmetric Encryption**: Using padding schemes like PKCS#7 without authenticating the ciphertext (e.g., with HMAC) allows padding oracle attacks in modes like AES-CBC. -- **Risky Padding in Asymmetric Encryption**: Using schemes like PKCS#1 v1.5 for RSA encryption without strict, uniform handling of invalid ciphertext enables oracle attacks. -- **Exposure of Cryptographic Errors**: Revealing detailed error messages or timing variations during decryption can leak information exploitable by attackers. - -## Mitigations - -- **Use Authenticated Symmetric Encryption Modes**: Prefer authenticated encryption modes like AES-GCM, which eliminate the need for separate padding validation and incorporate integrity checks. If AES-CBC must be used, adopt the Encrypt-then-MAC paradigm (e.g., append HMAC). See [NIST SP 800-175B Rev.1, Section 4.3](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-175Br1.pdf). -- **Use Secure Padding Schemes for Asymmetric Encryption**: Replace risky schemes like PKCS#1 v1.5 with secure ones such as OAEP (Optimal Asymmetric Encryption Padding). See [NIST SP 800-56B Rev.2, Section 7.2.2](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Br2.pdf). -- **Don't Expose Cryptographic Errors**: Do not expose cryptographic error messages, such as padding errors, to users. This prevents attackers from gaining clues about the padding's correctness. diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0024.md b/weaknesses/MASVS-CRYPTO/MASWE-0024.md deleted file mode 100644 index c0d5c0a..0000000 --- a/weaknesses/MASVS-CRYPTO/MASWE-0024.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: Improper Use of Message Authentication Code (MAC) -id: MASWE-0024 -alias: improper-mac -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v1: [MSTG-CRYPTO-4] - masvs-v2: [MASVS-CRYPTO-1] - cwe: [327, 807, 915] - -refs: -- https://developer.android.com/privacy-and-security/cryptography#deprecated-functionality -- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf -- https://csrc.nist.gov/pubs/sp/800/224/ipd -- https://datatracker.ietf.org/doc/html/rfc6151 -- https://web.archive.org/web/20170810051504/http://www.tcs.hut.fi/old/papers/aura/aura-csfws97.pdf -- https://en.wikipedia.org/wiki/Replay_attack -draft: - description: Improper use of MACs in security sensitive contexts affecting data integrity. - topics: - - Using HMAC with keys with insufficient entropy - - Using HMAC with missing timestamp (or nonce) - - Using MAC‑then‑encrypt or encrypt‑then‑MAC incorrectly, leaking information via timing or error messages - - Allowing predictors (users or attackers) to control data inputs, creating scenarios where forged or replayed tags bypass integrity checks. - - Hash functions lacking collision resistance (e.g., MD5 or SHA‑1 used in HMAC) - - Use of non‑cryptographic checksums (e.g., CRC‑32 instead of HMAC) - - MAC constructions that fail outside narrow assumptions (e.g., raw CBC‑MAC on variable‑length messages) - - Tags that are too short significantly lower the effort required for forgery -status: placeholder - ---- - diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0025.md b/weaknesses/MASVS-CRYPTO/MASWE-0025.md deleted file mode 100644 index f1df81e..0000000 --- a/weaknesses/MASVS-CRYPTO/MASWE-0025.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: Improper Generation of Cryptographic Signatures -id: MASWE-0025 -alias: improper-signature-generation -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v1: [MSTG-CRYPTO-4] - masvs-v2: [MASVS-CRYPTO-1] - cwe: [327] - -refs: -- https://developer.android.com/privacy-and-security/cryptography#deprecated-functionality -- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf -- https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf -- https://csrc.nist.gov/pubs/ir/8547/ipd -draft: - description: The use of algorithms with insufficient strength for signatures such as SHA1withRSA, etc. in a security-sensitive context should be avoided to ensure the integrity and authenticity of the data. - topics: null -status: placeholder - ---- - diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0026.md b/weaknesses/MASVS-CRYPTO/MASWE-0026.md deleted file mode 100644 index 87ec399..0000000 --- a/weaknesses/MASVS-CRYPTO/MASWE-0026.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: Improper Verification of Cryptographic Signature -id: MASWE-0026 -alias: improper-signature-verification -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v1: [MSTG-CRYPTO-4] - masvs-v2: [MASVS-CRYPTO-1] - cwe: [347] - -refs: -- https://cwe.mitre.org/data/definitions/347.html -- https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf -draft: - description: Cryptographic signature verification should be performed properly to - ensure the integrity and authenticity of the data. - topics: null -status: placeholder - ---- - diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0027.md b/weaknesses/MASVS-CRYPTO/MASWE-0027.md deleted file mode 100644 index 47203c2..0000000 --- a/weaknesses/MASVS-CRYPTO/MASWE-0027.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: Improper Random Number Generation -id: MASWE-0027 -alias: improper-random-number-generation -platform: ["android", "ios"] -profiles: ["L1", "L2"] -mappings: - masvs-v1: [MSTG-CRYPTO-6] - masvs-v2: [MASVS-CRYPTO-1] - cwe: [332, 337, 338] - android-risks: - - https://developer.android.com/privacy-and-security/risks/weak-prng -observed_examples: -- https://nvd.nist.gov/vuln/detail/CVE-2013-6386 -- https://nvd.nist.gov/vuln/detail/CVE-2013-6386 -- https://nvd.nist.gov/vuln/detail/CVE-2006-3419 -- https://nvd.nist.gov/vuln/detail/CVE-2008-4102 -- https://www.zellic.io/blog/proton-dart-flutter-csprng-prng/ -status: new ---- - -## Overview - -A [pseudorandom number generator (PRNG)](https://en.wikipedia.org/wiki/Pseudorandom_number_generator) algorithm generates sequences based on a seed with insufficient entropy that may be predictable. Common implementations are not cryptographically secure. For example, they typically use a linear congruential formula, allowing an attacker to predict future outputs, given enough observed outputs. Therefore, it is not suitable for security-critical applications or protecting sensitive data. - -## Impact - -- **Bypass Protection Mechanism**: Using a non-cryptographically secure PRNG in a security context, such as authentication, poses significant risks. An attacker could potentially guess the generated numbers and gain access to privileged data or functionality. Predicting or regenerating random numbers can lead to encryption breaches, compromise sensitive user information, or enable user impersonation. - -## Modes of Introduction - -- **Risky Random APIs**: The app may use many existing APIs to generate random numbers with insufficient entropy. -- **Non-random Sources**: The app may use custom methods to create "supposedly random" values, using non-random sources such as the current time. - -## Mitigations - -For security-relevant contexts, use cryptographically secure random numbers. - -In general, it is strongly recommended not to use any random function in a deterministic way, even if it's a secure one, especially those involving hardcoded seed values (which are vulnerable to exposure by decompilation). - -Refer to the [RFC 1750 - Randomness Recommendations for Security](https://www.ietf.org/rfc/rfc1750.txt) and the [OWASP Cryptographic Storage Cheat Sheet - Secure Random Number Generation](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html#secure-random-number-generation) for more information and recommendations on random number generation. diff --git a/weaknesses/MASVS-NETWORK/MASWE-0050.md b/weaknesses/MASVS-NETWORK/MASWE-0025.md similarity index 90% rename from weaknesses/MASVS-NETWORK/MASWE-0050.md rename to weaknesses/MASVS-NETWORK/MASWE-0025.md index 88ef2ef..e47a914 100644 --- a/weaknesses/MASVS-NETWORK/MASWE-0050.md +++ b/weaknesses/MASVS-NETWORK/MASWE-0025.md @@ -1,16 +1,18 @@ --- -title: Cleartext Traffic -id: MASWE-0050 +title: Network Traffic Not Encrypted +id: MASWE-0025 alias: cleartext-traffic platform: [android, ios] profiles: [L1, L2] mappings: - masvs-v1: [MSTG-NETWORK-2] + masvs-v1: [MSTG-NETWORK-2, MSTG-NETWORK-1] masvs-v2: [MASVS-NETWORK-1] - cwe: [319] + cwe: [311, 319] android-risks: - https://developer.android.com/privacy-and-security/risks/cleartext-communications + - https://developer.android.com/privacy-and-security/risks/insecure-machine-to-machine android-core-app-quality: [SC-9, SC-N1, SC-N2] +beta-coverage: [MASWE-0050, MASWE-0037, MASWE-0048] refs: - https://developer.apple.com/documentation/security/preventing-insecure-network-connections - https://developer.apple.com/documentation/bundleresources/information_property_list/nsapptransportsecurity/nsexceptiondomains @@ -53,6 +55,8 @@ If the connections were secured using encryption and proper authentication mecha - **Cleartext Traffic Allowed in Platform-provided Settings:** Configuring platform-provided settings (e.g. Network Security Configuration on Android or App Transport Security on iOS) to explicitly allow cleartext traffic (globally or per-domain), making it the default behavior for all network connections managed by those settings. - **Usage of HTTP:** Using HTTP instead of HTTPS for communication, which does not encrypt data in transit. - **Usage of Non-HTTP Insecure Protocols:** Using insecure protocols such as FTP, SMTP without TLS, TCP sockets or custom protocols which do not encrypt data in transit. +- **Unencrypted Non-IP Interfaces:** Transferring data over local/proximity interfaces such as Bluetooth/BLE, NFC, USB, or Wi-Fi Direct without encryption. These machine-to-machine channels are often overlooked but can expose sensitive data or enable remote device takeover if the payloads are not encrypted and authenticated. +- **Authentication Material over Insecure Channels:** Sending session IDs, tokens, passwords, or API keys over any of the above unencrypted channels. - **Usage of Low-Level Network APIs:** Use of low-level network APIs that do not enforce encryption and do not honor the platform's network security settings, such as `Socket` on Android or `NSURLConnection` on iOS. - **Cross-Platform Framework Misconfiguration:** Improper settings in cross-platform frameworks may allow cleartext traffic for both Android and iOS versions of an app. - **Third-Party Libraries**: Using third-party libraries or SDKs that default to insecure communication methods or are improperly configured. diff --git a/weaknesses/MASVS-NETWORK/MASWE-0052.md b/weaknesses/MASVS-NETWORK/MASWE-0026.md similarity index 99% rename from weaknesses/MASVS-NETWORK/MASWE-0052.md rename to weaknesses/MASVS-NETWORK/MASWE-0026.md index c72745e..1dc48e8 100644 --- a/weaknesses/MASVS-NETWORK/MASWE-0052.md +++ b/weaknesses/MASVS-NETWORK/MASWE-0026.md @@ -1,6 +1,6 @@ --- title: Insecure Certificate Validation -id: MASWE-0052 +id: MASWE-0026 alias: insecure-cert-val platform: [android, ios] profiles: [L1, L2] @@ -22,6 +22,7 @@ refs: - https://developer.apple.com/forums/thread/707320 - https://support.apple.com/en-us/102390 - https://developer.apple.com/documentation/foundation/performing-manual-server-trust-authentication +beta-coverage: [MASWE-0052] status: new --- diff --git a/weaknesses/MASVS-NETWORK/MASWE-0047.md b/weaknesses/MASVS-NETWORK/MASWE-0027.md similarity index 99% rename from weaknesses/MASVS-NETWORK/MASWE-0047.md rename to weaknesses/MASVS-NETWORK/MASWE-0027.md index 453a593..80898a2 100644 --- a/weaknesses/MASVS-NETWORK/MASWE-0047.md +++ b/weaknesses/MASVS-NETWORK/MASWE-0027.md @@ -1,6 +1,6 @@ --- title: Insecure Identity Pinning -id: MASWE-0047 +id: MASWE-0027 alias: insecure-pinning platform: [android, ios] profiles: [L2] @@ -8,6 +8,7 @@ mappings: masvs-v1: [MSTG-NETWORK-4] masvs-v2: [MASVS-NETWORK-2] cwe: [295] +beta-coverage: [MASWE-0047] status: new --- diff --git a/weaknesses/MASVS-NETWORK/MASWE-0048.md b/weaknesses/MASVS-NETWORK/MASWE-0048.md deleted file mode 100644 index 9c83e02..0000000 --- a/weaknesses/MASVS-NETWORK/MASWE-0048.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: Insecure Machine-to-Machine Communication -id: MASWE-0048 -alias: insecure-m2m -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v1: [MSTG-NETWORK-1] - masvs-v2: [MASVS-NETWORK-1] - cwe: [311, 319] - android-risks: - - https://developer.android.com/privacy-and-security/risks/insecure-machine-to-machine -draft: - description: Android applications often use technologies like Bluetooth, NFC, and USB for data transfer and device interaction. Developers must use these APIs carefully to prevent data exposure and remote device takeover by attackers. - topics: - - Bluetooth - - BLE - - NFC - - USB - - Wi-Fi P2P -status: placeholder ---- diff --git a/weaknesses/MASVS-NETWORK/MASWE-0049.md b/weaknesses/MASVS-NETWORK/MASWE-0049.md deleted file mode 100644 index f14e4ad..0000000 --- a/weaknesses/MASVS-NETWORK/MASWE-0049.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: Proven Networking APIs Not used -id: MASWE-0049 -alias: no-proven-net-apis -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v1: [MSTG-NETWORK-6] - masvs-v2: [MASVS-NETWORK-1, MASVS-CODE-3] -status: new ---- - -## Overview - -Applications that do not utilize platform-provided networking APIs or well-established security libraries are susceptible to security vulnerabilities. When developers implement custom networking code or "roll-your-own" security mechanisms, they risk introducing flaws due to a lack of deep expertise in cryptography and network security. Platform-provided APIs and libraries, such as `NSURLSession` on iOS or `HttpsURLConnection` on Android, are designed and maintained by experts, incorporating security best practices and regular updates to address new threats and vulnerabilities. - -## Impact - -- **Security Vulnerabilities**: Custom networking implementations may contain flaws that attackers can exploit, leading to data breaches and unauthorized access. -- **Lack of Updates**: Custom code may not receive timely updates to address new vulnerabilities or comply with evolving security standards. -- **Inconsistent Security Measures**: Bypassing standard APIs can result in inconsistent application of security features like encryption, certificate validation, and error handling. -- **Increased Development Complexity**: Writing and maintaining custom networking code increases complexity, making it harder to audit and secure the application. -- **Non-Compliance with Standards**: Failing to use approved APIs may lead to non-compliance with industry regulations and security guidelines. - -## Modes of Introduction - -- **Custom Networking Stack Development**: Developers create their own networking code instead of using platform-provided APIs, possibly to add custom features or due to unfamiliarity with existing APIs. -- **Use of Insecure Third-Party Libraries**: Incorporating third-party networking libraries that are outdated or do not follow current security best practices. -- **Bypassing Security Mechanisms**: Deliberately avoiding standard APIs to circumvent security checks, such as certificate pinning or TLS enforcement. -- **Insufficient Security Knowledge**: Developers may lack adequate understanding of network security principles, leading to insecure implementations. -- **Performance Optimization Attempts**: Writing custom networking code to optimize performance without fully considering the security implications. - -## Mitigations - -- **Utilize Platform-Provided Networking APIs**: Always use the networking APIs provided by the platform, such as `NSURLSession` for iOS and `HttpsURLConnection` for Android, which handle many security concerns internally. -- **Adopt Established Security Libraries**: If additional functionality is required, use reputable, well-maintained libraries like `OkHttp` for Android or `Alamofire` on iOS that adhere to security best practices. -- **Avoid Custom Security Implementations**: Refrain from implementing custom cryptographic algorithms or security protocols; rely on standard, vetted solutions instead. -- **Keep Dependencies Updated**: Regularly update all libraries and dependencies to incorporate the latest security patches and improvements. diff --git a/weaknesses/MASVS-NETWORK/MASWE-0051.md b/weaknesses/MASVS-NETWORK/MASWE-0051.md deleted file mode 100644 index f251697..0000000 --- a/weaknesses/MASVS-NETWORK/MASWE-0051.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: Unprotected Open Ports -id: MASWE-0051 -alias: open-ports -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v1: [MSTG-NETWORK-2] - masvs-v2: [MASVS-NETWORK-1] - cwe: [923] -status: new ---- - -## Overview - -Applications that open network ports without proper protection are vulnerable to unauthorized access and potential exploitation. This weakness occurs when an application listens on a network port and accepts incoming connections without adequate security measures, allowing other applications or attackers to connect and interact with it. - -## Impact - -- **Unauthorized Access**: Attackers can connect to open ports and gain access to application functionalities or sensitive data. -- **Data Leakage**: Sensitive information may be exposed through unprotected ports if proper authentication and encryption are not enforced. -- **Remote Code Execution**: Exploitation of open ports can lead to the execution of arbitrary code on the device. -- **Denial of Service**: Attackers may overload the open port, causing the application or device to become unresponsive. -- **Privacy Breach**: User data and application state can be compromised, leading to privacy violations and non-compliance with regulations. - -## Modes of Introduction - -- **Binding to All Network Interfaces**: Configuring the application to bind to all available network interfaces (e.g., using wildcard addresses), making it accessible over untrusted networks. -- **Insecure Loopback Address Usage**: Misconfiguring the application to listen on loopback addresses without proper access restrictions. -- **Lack of Access Controls**: Failing to implement authentication and authorization mechanisms for services exposed via open ports. -- **Debug Services Left Enabled**: Leaving development or debugging network services active in production releases. -- **Misconfigured Firewall Settings**: Not setting up proper firewall rules, allowing unauthorized inbound connections to open ports. - -## Mitigations - -- **Restrict Network Bindings**: Configure the application to bind only to specific, necessary network interfaces, avoiding the use of wildcard addresses like `INADDR_ANY`. -- **Implement Strong Access Controls**: Enforce authentication and authorization for any services exposed through open ports to ensure only authorized entities can connect. -- **Disable Debugging Services in Production**: Ensure that all development and debugging network services are disabled or removed in production builds. -- **Configure Firewalls Appropriately**: Set up firewall rules to restrict access to open ports, allowing connections only from trusted sources. diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0028.md b/weaknesses/MASVS-PLATFORM/MASWE-0028.md new file mode 100644 index 0000000..0a30889 --- /dev/null +++ b/weaknesses/MASVS-PLATFORM/MASWE-0028.md @@ -0,0 +1,28 @@ +--- +title: Sensitive Data Exposed via the User Interface +id: MASWE-0028 +alias: data-leak-ui +platform: [android, ios] +profiles: [L2] +mappings: + masvs-v1: [MSTG-STORAGE-7] + masvs-v2: [MASVS-PLATFORM-3, MASVS-STORAGE-2] + cwe: [200, 359] + +beta-coverage: [MASWE-0053] +draft: + description: | + Sensitive data such as passwords, PINs, card numbers, or other PII may be exposed + directly through the user interface, for example by displaying it in cleartext, allowing + it to be copied to the clipboard, keeping it in the keyboard cache via auto-correct, or + not using secure text entry fields. An attacker with brief access to the device or its + screen can then read this information. + topics: + - secure text entry (e.g. secureTextEntry / inputType textPassword) + - disabling copy/paste for sensitive fields + - disabling auto-correct / keyboard caching for sensitive fields + - masking or redacting sensitive values shown on screen +status: placeholder + +--- + diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0029.md b/weaknesses/MASVS-PLATFORM/MASWE-0029.md new file mode 100644 index 0000000..5f2b784 --- /dev/null +++ b/weaknesses/MASVS-PLATFORM/MASWE-0029.md @@ -0,0 +1,25 @@ +--- +title: Sensitive Data Leaked via Notifications +id: MASWE-0029 +alias: data-leak-notifications +platform: [android, ios] +profiles: [L2] +mappings: + masvs-v2: [MASVS-PLATFORM-3, MASVS-STORAGE-2] + cwe: [200, 359] + +beta-coverage: [MASWE-0054] +draft: + description: | + Apps may place sensitive data (e.g. OTPs, message contents, account details) into + notifications. Notifications are rendered on the lock screen and can be read by other apps + holding notification access (e.g. an Android `NotificationListenerService`), leaking the + data to unauthorized parties or the shoulder-surfing observer. + topics: + - sensitive content shown in notifications on the lock screen + - notifications readable by other apps (e.g. NotificationListenerService) + - notification visibility levels and redaction for sensitive notifications +status: placeholder + +--- + diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0055.md b/weaknesses/MASVS-PLATFORM/MASWE-0030.md similarity index 98% rename from weaknesses/MASVS-PLATFORM/MASWE-0055.md rename to weaknesses/MASVS-PLATFORM/MASWE-0030.md index b11baac..a658550 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0055.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0030.md @@ -1,6 +1,6 @@ --- title: Sensitive Data Leaked via Screenshots or Screen Recordings -id: MASWE-0055 +id: MASWE-0030 alias: data-leak-screenshots platform: [android, ios] profiles: [L2] @@ -11,6 +11,7 @@ mappings: refs: - https://developer.android.com/about/versions/14/features/screenshot-detection +beta-coverage: [MASWE-0055] status: new --- diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0031.md b/weaknesses/MASVS-PLATFORM/MASWE-0031.md new file mode 100644 index 0000000..37d69ed --- /dev/null +++ b/weaknesses/MASVS-PLATFORM/MASWE-0031.md @@ -0,0 +1,31 @@ +--- +title: App Vulnerable to Overlay Attacks +id: MASWE-0031 +alias: tapjacking-attacks +platform: [android, ios] +profiles: [L2] +mappings: + masvs-v1: [MSTG-PLATFORM-9] + masvs-v2: [MASVS-PLATFORM-3, MASVS-CODE-1] + cwe: [1021] + +refs: +- https://developer.android.com/topic/security/risks/tapjacking +beta-coverage: [MASWE-0056] +draft: + description: | + Overlay attacks occur when a malicious app (or an attacker-controlled window) draws content + on top of the target app to trick the user into interacting with it (tapjacking) or to + capture their input. The app is vulnerable when it does not defend against being fully or + partially obscured, e.g. by not using `View.setFilterTouchesWhenObscured(true)` / + `android:filterTouchesWhenObscured="true"` and not ignoring touch events carrying the + `FLAG_WINDOW_IS_PARTIALLY_OBSCURED` flag. This can lead the user to unknowingly approve + sensitive actions or disclose sensitive input. + topics: + - tapjacking (full and partial occlusion) + - filtering touches when the window is obscured + - protecting sensitive confirmation screens from overlays +status: placeholder + +--- + diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0058.md b/weaknesses/MASVS-PLATFORM/MASWE-0032.md similarity index 95% rename from weaknesses/MASVS-PLATFORM/MASWE-0058.md rename to weaknesses/MASVS-PLATFORM/MASWE-0032.md index a917e8b..66851f5 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0058.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0032.md @@ -1,6 +1,6 @@ --- title: Insecure Deep Links -id: MASWE-0058 +id: MASWE-0032 alias: insecure-deep-links platform: [android, ios] profiles: [L1, L2] @@ -18,6 +18,7 @@ draft: - Universal Links - URL validation - Check for OS version. e.g. deep link are more secure after Android XX +beta-coverage: [MASWE-0058] refs: - https://developer.apple.com/documentation/technotes/tn3155-debugging-universal-links status: placeholder diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0033.md b/weaknesses/MASVS-PLATFORM/MASWE-0033.md new file mode 100644 index 0000000..64f9e25 --- /dev/null +++ b/weaknesses/MASVS-PLATFORM/MASWE-0033.md @@ -0,0 +1,35 @@ +--- +title: Improper Use of the Clipboard +id: MASWE-0033 +alias: improper-clipboard +platform: [android, ios] +profiles: [L1, L2] +mappings: + masvs-v2: [MASVS-PLATFORM-1, MASVS-STORAGE-2] + cwe: [200, 668] + +refs: +- https://developer.android.com/develop/ui/views/touch-and-input/copy-paste#PreventingSensitiveData +- https://developer.apple.com/documentation/uikit/uipasteboard +beta-coverage: [MASWE-0059] +draft: + description: | + The system clipboard is a shared resource: any app (and, on some platforms, nearby devices + via universal clipboard) can read its contents. Copying sensitive data (passwords, OTPs, + card numbers, tokens) to the clipboard, or failing to mark it as sensitive/clear it, can + leak that data to other apps. Apps should avoid placing sensitive data on the clipboard, + mark clipboard content as sensitive where supported (e.g. `EXTRA_IS_SENSITIVE` on Android, + excluding items from universal clipboard on iOS), and clear it when appropriate. + + Note: the general IPC / localhost-server aspects previously covered here have moved to + [MASWE-0020](../MASVS-AUTH/MASWE-0020.md); this weakness exclusively covers improper use of + the clipboard. + topics: + - copying sensitive data to the clipboard + - not marking clipboard content as sensitive (e.g. Android EXTRA_IS_SENSITIVE) + - not restricting universal/shared clipboard for sensitive content on iOS + - reading untrusted data from the clipboard without validation +status: placeholder + +--- + diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0061.md b/weaknesses/MASVS-PLATFORM/MASWE-0034.md similarity index 84% rename from weaknesses/MASVS-PLATFORM/MASWE-0061.md rename to weaknesses/MASVS-PLATFORM/MASWE-0034.md index 8a5e7de..602ae9c 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0061.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0034.md @@ -1,6 +1,6 @@ --- -title: Insecure Use of App Extensions -id: MASWE-0061 +title: Allowing Untrusted App Extensions +id: MASWE-0034 alias: insecure-app-extensions platform: [ios] profiles: [L1, L2] @@ -9,6 +9,7 @@ mappings: masvs-v2: [MASVS-PLATFORM-1, MASVS-STORAGE-2] cwe: [200] +beta-coverage: [MASWE-0061] draft: description: restricting use of certain extensions topics: diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0035.md b/weaknesses/MASVS-PLATFORM/MASWE-0035.md new file mode 100644 index 0000000..ab6926f --- /dev/null +++ b/weaknesses/MASVS-PLATFORM/MASWE-0035.md @@ -0,0 +1,36 @@ +--- +title: Insecure Intents +id: MASWE-0035 +alias: insecure-intents +platform: [android] +profiles: [L1, L2] +mappings: + masvs-v2: [MASVS-PLATFORM-1, MASVS-STORAGE-2] + cwe: [927, 940] + +refs: +- https://support.google.com/faqs/answer/9267555?hl=en +- https://developer.android.com/privacy-and-security/security-tips#intents +- https://developer.android.com/topic/security/risks/intent-redirection +- https://developer.android.com/topic/security/risks/implicit-intent-hijacking +- https://developer.android.com/topic/security/risks/pending-intent +- https://developer.android.com/topic/security/risks/sticky-broadcast +beta-coverage: [MASWE-0066] +draft: + description: | + This weakness covers everything related to the insecure handling of Android Intents, e.g. + calling `startActivity`, `startService`, `sendBroadcast`, or `setResult` on untrusted + Intents without validating or sanitizing them. Using an implicit intent to start a service + is a security hazard because you can't be certain what service will respond and the user + can't see which service starts. It also covers mutable pending intents (not using + `FLAG_IMMUTABLE`), replayable pending intents (not using `FLAG_ONE_SHOT`), implicit intent + hijacking, intent redirection, and sticky broadcasts. + topics: + - Insecure Intent Redirection + - Insecure Implicit Intents + - Insecure Pending Intents (mutable, replaying) + - Sticky broadcasts +status: placeholder + +--- + diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0036.md b/weaknesses/MASVS-PLATFORM/MASWE-0036.md new file mode 100644 index 0000000..8fe0def --- /dev/null +++ b/weaknesses/MASVS-PLATFORM/MASWE-0036.md @@ -0,0 +1,30 @@ +--- +title: Sensitive Functionality Exposed in WebViews +id: MASWE-0036 +alias: js-bridges-webviews +platform: [android, ios] +profiles: [L1, L2] +mappings: + masvs-v1: [MSTG-PLATFORM-7] + masvs-v2: [MASVS-PLATFORM-2, MASVS-STORAGE-2] + cwe: [749, 94] + +refs: +- https://support.google.com/faqs/answer/9095419 +beta-coverage: [MASWE-0068] +draft: + description: | + WebViews can expose native/sensitive functionality to the web content they render, most + commonly through JavaScript bridges (e.g. Android `addJavascriptInterface`, + `WKScriptMessageHandler` / `evaluateJavaScript` on iOS). When such bridges expose more + capability than needed, or are reachable by untrusted content, malicious JavaScript can + invoke native methods, access sensitive data, or perform privileged actions. + topics: + - addJavascriptInterface and other JavaScript bridges + - exposing more native functionality than necessary + - bridges reachable by untrusted web content + - restricting bridge exposure to trusted origins only +status: placeholder + +--- + diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0037.md b/weaknesses/MASVS-PLATFORM/MASWE-0037.md new file mode 100644 index 0000000..13f8692 --- /dev/null +++ b/weaknesses/MASVS-PLATFORM/MASWE-0037.md @@ -0,0 +1,34 @@ +--- +title: WebViews Allow Access to Local Resources with Untrusted Content +id: MASWE-0037 +alias: webviews-local-resources +platform: [android, ios] +profiles: [L1, L2] +mappings: + masvs-v1: [MSTG-PLATFORM-6] + masvs-v2: [MASVS-PLATFORM-2, MASVS-STORAGE-2, MASVS-CODE-4] + cwe: [22, 79, 200, 669] + android-risks: + - https://developer.android.com/privacy-and-security/risks/webview-unsafe-file-inclusion + +refs: +- https://blog.oversecured.com/Android-Exploring-vulnerabilities-in-WebResourceResponse/ +beta-coverage: [MASWE-0069, MASWE-0073] +draft: + description: | + When a WebView is configured to access local resources (e.g. `setAllowFileAccessFromFileURLs`, + `setAllowUniversalAccessFromFileURLs`, `setAllowFileAccess`, `setAllowContentAccess`) while + also rendering untrusted content, malicious JavaScript can read app-private files, traverse the + filesystem, or exfiltrate data via XHR. This also covers insecure custom resource loading via + `WebResourceResponse` (instead of `WebViewAssetLoader`), which can serve attacker-controllable + HTML/JS (enabling XSS) and expose files from a protected internal sphere to the less-trusted + WebView JavaScript context or external websites. + topics: + - universal file access from file URLs + - restricting file:// and content:// access + - insecure WebResourceResponse vs. WebViewAssetLoader + - exposing app-private files/data to the WebView JavaScript context +status: placeholder + +--- + diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0038.md b/weaknesses/MASVS-PLATFORM/MASWE-0038.md new file mode 100644 index 0000000..163e5a3 --- /dev/null +++ b/weaknesses/MASVS-PLATFORM/MASWE-0038.md @@ -0,0 +1,32 @@ +--- +title: WebViews Loading Untrusted Content +id: MASWE-0038 +alias: webviews-untrusted-content +platform: [android, ios] +profiles: [L1, L2] +mappings: + masvs-v2: [MASVS-PLATFORM-2, MASVS-CODE-4] + cwe: [79, 601, 829] + +refs: +- https://blog.oversecured.com/Evernote-Universal-XSS-theft-of-all-cookies-from-all-sites-and-more/ +beta-coverage: [MASWE-0071, MASWE-0070, MASWE-0072] +draft: + description: | + WebView objects shouldn't load URLs, HTML, or JavaScript from untrusted sources, and the app + shouldn't let users navigate to sites outside of the developer's control. Loading untrusted + content (e.g. a URL received via an intent or deep link, or JavaScript fetched from an + unverified source) can lead to cross-site scripting, including Universal XSS, allowing an + attacker to steal cookies/tokens from any site, perform phishing, or drive-by downloads. + Whenever possible, use an allowlist to restrict what the WebView loads (e.g. via + `WebViewClient.shouldOverrideUrlLoading`) and enable Safe Browsing. + topics: + - not restricting navigation to trusted origins + - loading URLs from untrusted sources (e.g. intents or deep links) + - loading JavaScript from untrusted/unverified sources + - Universal XSS (theft of cookies/tokens across sites) + - not enabling Safe Browsing +status: placeholder + +--- + diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0039.md b/weaknesses/MASVS-PLATFORM/MASWE-0039.md new file mode 100644 index 0000000..4012bff --- /dev/null +++ b/weaknesses/MASVS-PLATFORM/MASWE-0039.md @@ -0,0 +1,34 @@ +--- +title: Sensitive Data Leaked via Accessibility Services +id: MASWE-0039 +alias: data-leak-accessibility +platform: [android, ios] +profiles: [L2] +mappings: + masvs-v2: [MASVS-PLATFORM-3, MASVS-STORAGE-2] + cwe: [200, 359] + +refs: +- https://developer.android.com/guide/topics/ui/accessibility/service +- https://support.google.com/googleplay/android-developer/answer/10964491 +- https://developer.apple.com/documentation/uikit/uiaccessibility +draft: + description: | + Accessibility services (e.g. Android `AccessibilityService`) can observe screen content, + read text of on-screen nodes, and receive UI events across apps. A malicious or overly + privileged accessibility service can therefore harvest sensitive data (passwords, OTPs, + messages, PII) that an app displays or that the user enters. Apps handling sensitive data + should minimize what is exposed to accessibility APIs, mark sensitive views appropriately + (e.g. excluding them from accessibility where suitable, avoiding placing secrets in + accessibility node text), and be aware that accessibility-based malware is a common + exfiltration and overlay-abuse vector. Similarly on iOS, sensitive values should not be + exposed through accessibility labels/values beyond what is necessary. + topics: + - Android AccessibilityService reading on-screen content and events + - sensitive data exposed via accessibility node text / labels + - accessibility-based malware and overlay abuse + - minimizing sensitive data exposed to accessibility APIs + - iOS accessibility labels/values leaking sensitive data +status: placeholder + +--- diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0053.md b/weaknesses/MASVS-PLATFORM/MASWE-0053.md deleted file mode 100644 index b0a068e..0000000 --- a/weaknesses/MASVS-PLATFORM/MASWE-0053.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: Sensitive Data Leaked via the User Interface -id: MASWE-0053 -alias: data-leak-ui -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v1: [MSTG-STORAGE-7] - masvs-v2: [MASVS-PLATFORM-3, MASVS-STORAGE-2] - cwe: [200, 359] - -draft: - description: e.g. leaking passwords, PINs via the UI - topics: - - secureText - - copy/paste disabled - - auto-correct - - etc. -status: placeholder - ---- - diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0054.md b/weaknesses/MASVS-PLATFORM/MASWE-0054.md deleted file mode 100644 index a22019a..0000000 --- a/weaknesses/MASVS-PLATFORM/MASWE-0054.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: Sensitive Data Leaked via Notifications -id: MASWE-0054 -alias: data-leak-notifications -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v2: [MASVS-PLATFORM-3, MASVS-STORAGE-2] - cwe: [200, 359] - -draft: - description: e.g. stealing pending intents from notifications via notificationlistenerservice - or tapjacking wire transfer UI. - topics: - - NotificationListenerService -status: placeholder - ---- - diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0056.md b/weaknesses/MASVS-PLATFORM/MASWE-0056.md deleted file mode 100644 index d2f9702..0000000 --- a/weaknesses/MASVS-PLATFORM/MASWE-0056.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: Tapjacking Attacks -id: MASWE-0056 -alias: tapjacking-attacks -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v1: [MSTG-PLATFORM-9] - masvs-v2: [MASVS-PLATFORM-3, MASVS-CODE-1] - cwe: [1021] - -refs: -- https://developer.android.com/topic/security/risks/tapjacking -draft: - description: not using View.setFilterTouchesWhenObscured(true) or android:filterTouchesWhenObscured="true" - in the AndroidManifest.xml or not ignoring touch events that have FLAG_WINDOW_IS_PARTIALLY_OBSCURED - flag - topics: - - Full occlusion - - Partial occlusion -status: placeholder - ---- - diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0057.md b/weaknesses/MASVS-PLATFORM/MASWE-0057.md deleted file mode 100644 index bc36fc3..0000000 --- a/weaknesses/MASVS-PLATFORM/MASWE-0057.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: StrandHogg Attack / Task Affinity Vulnerability -id: MASWE-0057 -alias: strandhogg-attack -platform: [android] -profiles: [L1, L2] -mappings: - masvs-v2: [MASVS-PLATFORM-3] - cwe: [451, 1104] - -refs: -- https://developer.android.com/topic/security/risks/strandhogg -draft: - description: This vulnerability is exploited by manipulating the allowTaskReparenting - and taskAffinity settings. - topics: - - StrandHogg Attack v1 - - StrandHogg Attack v2 -status: placeholder - ---- - diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0059.md b/weaknesses/MASVS-PLATFORM/MASWE-0059.md deleted file mode 100644 index 860924a..0000000 --- a/weaknesses/MASVS-PLATFORM/MASWE-0059.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: Use Of Unauthenticated Platform IPC -id: MASWE-0059 -alias: unauthenticated-ipc -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v2: [MASVS-PLATFORM-1, MASVS-STORAGE-2] - cwe: [287, 668, 200] - -draft: - description: e.g. (ab)using the clipboard or using localhost server for IPC - topics: - - (ab)using the clipboard - - using localhost server -status: placeholder - ---- - diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0060.md b/weaknesses/MASVS-PLATFORM/MASWE-0060.md deleted file mode 100644 index 4d03249..0000000 --- a/weaknesses/MASVS-PLATFORM/MASWE-0060.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: Insecure Use of UIActivity -id: MASWE-0060 -alias: insecure-uiactivity -platform: [ios] -profiles: [L1, L2] -mappings: - masvs-v2: [MASVS-PLATFORM-1, MASVS-STORAGE-2] - cwe: [200, 285, 358] - -draft: - description: e.g. data (items) being shared, custom activities, excluded activity - types. More examples include CWE-285 and CWE-200 for exposing UIActivity information to untrusted apps or actors. CWE-358 for possible bad activityViewController implemented in the UIActivity. - topics: - - data (items) being shared - - custom activities - - excluded activity types -status: placeholder - ---- - diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0062.md b/weaknesses/MASVS-PLATFORM/MASWE-0062.md deleted file mode 100644 index 445e972..0000000 --- a/weaknesses/MASVS-PLATFORM/MASWE-0062.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: Insecure Services -id: MASWE-0062 -alias: insecure-services -platform: [android] -profiles: [L1, L2] -mappings: - masvs-v1: [MSTG-PLATFORM-4] - masvs-v2: [MASVS-PLATFORM-1, MASVS-STORAGE-2] - cwe: [926] - -refs: -- https://developer.android.com/privacy-and-security/security-tips#Services -- https://developer.android.com/guide/topics/manifest/service-element -- https://developer.android.com/reference/android/app/Service -- https://developer.android.com/privacy-and-security/security-tips#binder-and-messenger-interfaces -draft: - description: Unintentionally exported services, unrestricted permissions. Exposed - binders e.g not using checkCallingPermission() to verify whether the caller has - a required permission. - topics: - - Services - - Exposed Binders via Exported Services -status: placeholder - ---- - diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0063.md b/weaknesses/MASVS-PLATFORM/MASWE-0063.md deleted file mode 100644 index aa350d4..0000000 --- a/weaknesses/MASVS-PLATFORM/MASWE-0063.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: Insecure Broadcast Receivers -id: MASWE-0063 -alias: insecure-broadcast-receivers -platform: [android] -profiles: [L1, L2] -mappings: - masvs-v1: [MSTG-PLATFORM-4] - masvs-v2: [MASVS-PLATFORM-1, MASVS-STORAGE-2] - cwe: [925, 926] - -refs: -- https://developer.android.com/guide/components/broadcasts#security-and-best-practices -- https://developer.android.com/topic/security/risks/sticky-broadcast -- https://developer.android.com/privacy-and-security/security-tips#BroadcastReceivers -draft: - description: Unintentionally exported broadcast receivers, unrestricted permissions, - sticky broadcasts. - topics: - - Unintentionally exported broadcast receivers - - Unrestricted permissions - - Sticky broadcasts -status: placeholder - ---- - diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0064.md b/weaknesses/MASVS-PLATFORM/MASWE-0064.md deleted file mode 100644 index 9731a5b..0000000 --- a/weaknesses/MASVS-PLATFORM/MASWE-0064.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: Insecure Content Providers -id: MASWE-0064 -alias: insecure-content-providers -platform: [android] -profiles: [L1, L2] -mappings: - masvs-v1: [MSTG-STORAGE-6] - masvs-v2: [MASVS-PLATFORM-1, MASVS-STORAGE-1] - cwe: [926] - -refs: -- https://developer.android.com/topic/security/risks/content-resolver -- https://developer.android.com/reference/androidx/core/content/FileProvider -- https://developer.android.com/topic/security/risks/file-providers -- https://developer.android.com/privacy-and-security/security-tips#ContentProviders -draft: - description: Unintentionally exported content providers, unprotected content providers, - permission tags, protection level - topics: - - file-system based - - FileProvider (Android) - - database based - - exposed - - permission tags - - protection level -status: placeholder - ---- - diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0065.md b/weaknesses/MASVS-PLATFORM/MASWE-0065.md deleted file mode 100644 index 481adb0..0000000 --- a/weaknesses/MASVS-PLATFORM/MASWE-0065.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: Sensitive Data Permanently Shared with Other Apps -id: MASWE-0065 -alias: sensitive-data-shared-other-apps -platform: [android] -profiles: [L1, L2] -mappings: - masvs-v1: [MSTG-STORAGE-6] - masvs-v2: [MASVS-PLATFORM-1, MASVS-STORAGE-1] - cwe: [200, 276, 732] - -refs: -- https://developer.android.com/topic/security/risks/content-resolver -- https://developer.android.com/reference/androidx/core/content/FileProvider -- https://developer.android.com/topic/security/risks/file-providers -- https://developer.android.com/privacy-and-security/security-tips#ContentProviders -draft: - description: Provide clients one-time access to data. For example using URI permission - grant flags and content provider permissions to display an app's PDF file in a - separate PDF Viewer app. - topics: - - content providers - - FLAG_GRANT_READ_URI_PERMISSION - - FLAG_GRANT_WRITE_URI_PERMISSION - - FLAG_GRANT_PERSISTABLE_URI_PERMISSION - - content URIs - - file URIs -status: placeholder - ---- - diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0066.md b/weaknesses/MASVS-PLATFORM/MASWE-0066.md deleted file mode 100644 index 026a7ce..0000000 --- a/weaknesses/MASVS-PLATFORM/MASWE-0066.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: Insecure Intents -id: MASWE-0066 -alias: insecure-intents -platform: [android] -profiles: [L1, L2] -mappings: - masvs-v2: [MASVS-PLATFORM-1, MASVS-STORAGE-2] - cwe: [927, 940] - -refs: -- https://support.google.com/faqs/answer/9267555?hl=en -- https://developer.android.com/privacy-and-security/security-tips#intents -- https://developer.android.com/topic/security/risks/intent-redirection -- https://developer.android.com/topic/security/risks/implicit-intent-hijacking -- https://developer.android.com/topic/security/risks/pending-intent -draft: - description: e.g. calling startActivity, startService, sendBroadcast, or setResult - on untrusted Intents without validating or sanitizing these Intents. Using an - implicit intent to start a service is a security hazard, because you can't be - certain what service will respond to the intent and the user can't see which service - starts. e.g. mutable pending intents (not using FLAG_IMMUTABLE), replaying pending - intents (not using FLAG_ONE_SHOT) - topics: - - Insecure Intent Redirection - - Insecure Implicit Intents - - Insecure Pending Intents (Mutable, Replaying) -status: placeholder - ---- - diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0068.md b/weaknesses/MASVS-PLATFORM/MASWE-0068.md deleted file mode 100644 index a5339ff..0000000 --- a/weaknesses/MASVS-PLATFORM/MASWE-0068.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: JavaScript Bridges in WebViews -id: MASWE-0068 -alias: js-bridges-webviews -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v1: [MSTG-PLATFORM-7] - masvs-v2: [MASVS-PLATFORM-2, MASVS-STORAGE-2] - cwe: [749, 94] - -refs: -- https://support.google.com/faqs/answer/9095419 -draft: - description: via addJavascriptInterface - topics: - - addJavascriptInterface -status: placeholder - ---- - diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0069.md b/weaknesses/MASVS-PLATFORM/MASWE-0069.md deleted file mode 100644 index 444c79c..0000000 --- a/weaknesses/MASVS-PLATFORM/MASWE-0069.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: WebViews Allows Access to Local Resources -id: MASWE-0069 -alias: webviews-local-resources -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v1: [MSTG-PLATFORM-6] - masvs-v2: [MASVS-PLATFORM-2, MASVS-STORAGE-2] - cwe: [200, 22] - android-risks: - - https://developer.android.com/privacy-and-security/risks/webview-unsafe-file-inclusion - -draft: - description: use of setAllowFileAccessFromFileURLs. Mitigations include setAllowFileAccess(false), - setAllowContentAccess(false) - topics: - - universal file access - - restrict content access - - handlers e.g. file:// vs content:// -status: placeholder - ---- - diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0070.md b/weaknesses/MASVS-PLATFORM/MASWE-0070.md deleted file mode 100644 index f27415d..0000000 --- a/weaknesses/MASVS-PLATFORM/MASWE-0070.md +++ /dev/null @@ -1,17 +0,0 @@ ---- -title: JavaScript Loaded from Untrusted Sources -id: MASWE-0070 -alias: js-untrusted-sources -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v2: [MASVS-PLATFORM-2, MASVS-CODE-4] - cwe: [79, 829] - -draft: - description: e.g. not validating the source of the JavaScript code - topics: null -status: placeholder - ---- - diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0071.md b/weaknesses/MASVS-PLATFORM/MASWE-0071.md deleted file mode 100644 index c660260..0000000 --- a/weaknesses/MASVS-PLATFORM/MASWE-0071.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: WebViews Loading Content from Untrusted Sources -id: MASWE-0071 -alias: webviews-untrusted-content -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v2: [MASVS-PLATFORM-2, MASVS-CODE-4] - cwe: [601] - -draft: - description: WebView objects shouldn't load URLs from untrusted sources. Also, your - app shouldn't let users navigate to sites that are outside of your control. Whenever - possible, use an allowlist to restrict the content loaded by your app's WebView - objects e.g. via WebViewClient.shouldOverrideUrlLoading - topics: - - not restricting navigation - - not using SafeBrowsing - - loading URL from untrusted sources e.g. intents or deep links -status: placeholder - ---- - diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0072.md b/weaknesses/MASVS-PLATFORM/MASWE-0072.md deleted file mode 100644 index 9ca0179..0000000 --- a/weaknesses/MASVS-PLATFORM/MASWE-0072.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: Universal XSS -id: MASWE-0072 -alias: universal-xss -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v2: [MASVS-PLATFORM-2, MASVS-CODE-4] - cwe: [79] - -refs: -- https://hackerone.com/reports/532836 -- https://www.cybersecurity-help.cz/vdb/SB2021110227 -- https://cwe.mitre.org/data/definitions/79.html -- https://blog.oversecured.com/Evernote-Universal-XSS-theft-of-all-cookies-from-all-sites-and-more/ -draft: - description: Successful exploitation of this vulnerability may allow a remote attacker - to steal potentially sensitive information, change appearance of a web page, perform - phishing and drive-by-download attacks. - topics: null -status: placeholder - ---- - diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0073.md b/weaknesses/MASVS-PLATFORM/MASWE-0073.md deleted file mode 100644 index 33a9468..0000000 --- a/weaknesses/MASVS-PLATFORM/MASWE-0073.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: Insecure WebResourceResponse Implementations -id: MASWE-0073 -alias: insecure-webresourceresponse -platform: [android] -profiles: [L2] -mappings: - masvs-v2: [MASVS-PLATFORM-2, MASVS-CODE-4] - cwe: [79, 200, 669] - -refs: -- https://blog.oversecured.com/Android-Exploring-vulnerabilities-in-WebResourceResponse/ -draft: - description: Using WebResourceResponse instead of WebViewAssetLoader - topics: - - Since WebResourceResponse may serve attacker‑controlled HTML/JS, it enables XSS when content isn’t properly sanitized (CWE-79). - - If an app exposes arbitrary files via XHR in the WebView context, it may be leaking private data (CWE-200). - - Data or files from a protected internal sphere (such as app-private storage) are exposed to a less trusted sphere, like WebView's JavaScript context or external websites (CWE-669). -status: placeholder - ---- - diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0074.md b/weaknesses/MASVS-PLATFORM/MASWE-0074.md deleted file mode 100644 index c3a78f2..0000000 --- a/weaknesses/MASVS-PLATFORM/MASWE-0074.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: Web Content Debugging Enabled -id: MASWE-0074 -alias: web-content-debugging -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v2: [MASVS-PLATFORM-2, MASVS-RESILIENCE-4] - cwe: [489] - -refs: -- https://developer.android.com/reference/android/webkit/WebView#setWebContentsDebuggingEnabled(boolean) -- https://developer.apple.com/documentation/webkit/wkwebview/4111163-isinspectable -draft: - description: using setWebContentsDebuggingEnabled in Android or WKWebView.isInspectable - on iOS - topics: null -status: placeholder - ---- - diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0118.md b/weaknesses/MASVS-PLATFORM/MASWE-0118.md deleted file mode 100644 index f665841..0000000 --- a/weaknesses/MASVS-PLATFORM/MASWE-0118.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -title: Sensitive Data Not Removed After Use -id: MASWE-0118 -alias: data-minimisation -platform: [android, ios] -profiles: [P] -mappings: - masvs-v2: [MASVS-PRIVACY-1] - -refs: - - https://mas.owasp.org/MASTG/knowledge/android/MASVS-PLATFORM/MASTG-KNOW-0018/#webviews-cleanup - - https://developer.android.com/privacy-and-security/security-tips?hl=en#WebView - - https://developer.apple.com/documentation/webkit/wkwebsitedatastore -draft: - description: | - Applying data minimisation, including appropriate cleanup in the end of the lifecycle is important. - - 1. Clear web state or prefer non-persistent web stores - - - Android: - - `CookieManager.getInstance().removeAllCookies(ValueCallback)` - - `WebStorage.getInstance().deleteAllData()` - - `WebViewDatabase.getInstance(context).clearHttpAuthUsernamePassword()` - - - iOS: - - `WKWebsiteDataStore.default().removeData(ofTypes: WKWebsiteDataStore.allWebsiteDataTypes(), modifiedSince: Date.distantPast)` - - Use `WKWebsiteDataStore.nonPersistent()` for private sessions - - `HTTPCookieStorage.shared.removeCookies(since: .distantPast)` - - Use `WKHTTPCookieStore` for targeted cookie deletion - - 2. Clear app cache and files - - - Android: - - `context.cacheDir.deleteRecursively()` - - `context.filesDir.deleteRecursively()` - - `context.deleteDatabase(name)` for temporary databases - - `SharedPreferences.edit().clear().apply()` to remove tokens or user data - - - iOS: - - Remove items in `NSTemporaryDirectory()` and the Caches folder using `FileManager.default.removeItem(at:)` - - For Core Data, call `NSPersistentStoreCoordinator.destroyPersistentStore(at:ofType:options:)` for a full wipe - - Reset `UserDefaults` with `removePersistentDomain(forName:)` - - 3. Avoid network caches - - - Android: - - `HttpResponseCache.getInstalled()?.delete()` for legacy stack - - For OkHttp: `okHttpClient.cache?.evictAll()` or disable caching with `CacheControl.FORCE_NETWORK` - - - iOS: - - `URLCache.shared.removeAllCachedResponses()` - - Disable caching via `URLSessionConfiguration.urlCache = nil` or set `requestCachePolicy = .reloadIgnoringLocalCacheData` - - `URLSession.invalidateAndCancel()` to clear in-memory session state - - topics: - - webview - - webview-cleanup - - caches - - data-minimisation - - cleanup -status: placeholder - ---- diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0119.md b/weaknesses/MASVS-PLATFORM/MASWE-0119.md deleted file mode 100644 index 7a8b17c..0000000 --- a/weaknesses/MASVS-PLATFORM/MASWE-0119.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: Insecure Activities -id: MASWE-0119 -alias: insecure-activities -platform: [android] -profiles: [L1, L2] -mappings: - masvs-v1: [MSTG-PLATFORM-4] - masvs-v2: [MASVS-PLATFORM-1, MASVS-STORAGE-2] - cwe: [926] - -refs: -- https://developer.android.com/privacy-and-security/security-tips#intents -- https://developer.android.com/guide/topics/manifest/activity-element -- https://developer.android.com/reference/android/app/Activity -draft: - description: Unintentionally exported ativities, unrestricted permissions. - topics: - - Activities -status: placeholder - ---- - diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0109.md b/weaknesses/MASVS-PRIVACY/MASWE-0065.md similarity index 79% rename from weaknesses/MASVS-PRIVACY/MASWE-0109.md rename to weaknesses/MASVS-PRIVACY/MASWE-0065.md index 5a53aa1..cfdc1d1 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0109.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0065.md @@ -1,6 +1,6 @@ --- title: Lack of Anonymization or Pseudonymisation Measures -id: MASWE-0109 +id: MASWE-0065 alias: anonymization-pseudonymization-measures platform: ["android", "ios"] profiles: ["P"] @@ -15,6 +15,7 @@ refs: - https://gdpr-info.eu/art-4-gdpr/ - https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2014/wp216_en.pdf - https://www.statista.com/topics/9460/app-tracking-and-mobile-privacy/ +beta-coverage: [MASWE-0109] status: new --- @@ -27,6 +28,7 @@ This lack of privacy safeguards can result in unauthorized profiling, targeted a ## Modes of Introduction - **Lack of Anonymization or Pseudonymization Measures**: Failure to remove direct identifiers, such as user ID or name, from data before server-side collection, or to manipulate the data to prevent linkage to real-world identities. This also includes not implementing protocols like Private Information Retrieval or Oblivious HTTP (OHTTP) to enhance privacy. +- **Sensitive Data Not Redacted Before Passing to AI**: Sending unredacted sensitive or personal data to AI/ML services (on-device or cloud) without first removing or masking identifiers. Beyond the immediate disclosure, the data may be retained and used to train models, making the exposure difficult to reverse. ## Impact @@ -36,3 +38,4 @@ This lack of privacy safeguards can result in unauthorized profiling, targeted a ## Mitigations - **Use Anonymisation and Pseudonymisation**: Ensure techniques like anonymisation and pseudonymisation are implemented to prevent user identification. +- **Redact Sensitive Data Before Passing to AI**: Before sending data to AI/ML services, redact or mask sensitive fields and identifiers so that personal data is not exposed to (or used to train) third-party models. diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0110.md b/weaknesses/MASVS-PRIVACY/MASWE-0066.md similarity index 98% rename from weaknesses/MASVS-PRIVACY/MASWE-0110.md rename to weaknesses/MASVS-PRIVACY/MASWE-0066.md index 0dffb1c..fd0d0ed 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0110.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0066.md @@ -1,6 +1,6 @@ --- -title: Use of Unique Identifiers for User Tracking -id: MASWE-0110 +title: Incorrect Use of Identifiers for User Tracking +id: MASWE-0066 alias: unique-identifiers-user-tracking platform: ["android", "ios"] profiles: ["P"] @@ -23,7 +23,7 @@ refs: - https://developer.apple.com/app-store/ad-attribution/ - https://developer.apple.com/documentation/adattributionkit - https://gdpr-info.eu/recitals/no-30/ - +beta-coverage: [MASWE-0110] status: new --- diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0111.md b/weaknesses/MASVS-PRIVACY/MASWE-0067.md similarity index 98% rename from weaknesses/MASVS-PRIVACY/MASWE-0111.md rename to weaknesses/MASVS-PRIVACY/MASWE-0067.md index e3fc5bf..9b9236f 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0111.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0067.md @@ -1,6 +1,6 @@ --- title: Inadequate Privacy Policy -id: MASWE-0111 +id: MASWE-0067 alias: privacy-policy platform: ["android", "ios"] profiles: ["P"] @@ -12,6 +12,7 @@ refs: - https://support.google.com/googleplay/android-developer/answer/9859455#privacy_policy - https://developer.apple.com/app-store/app-privacy-details/#privacy-links - https://developer.apple.com/app-store/review/guidelines/#5.1.1 +beta-coverage: [MASWE-0111] status: new --- diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0112.md b/weaknesses/MASVS-PRIVACY/MASWE-0068.md similarity index 87% rename from weaknesses/MASVS-PRIVACY/MASWE-0112.md rename to weaknesses/MASVS-PRIVACY/MASWE-0068.md index 4b77bfb..9c96b8a 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0112.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0068.md @@ -1,12 +1,12 @@ --- title: Inadequate Data Collection Declarations -id: MASWE-0112 +id: MASWE-0068 alias: data-collection-declarations platform: ["android", "ios"] profiles: ["P"] mappings: - masvs-v1: [MSTG-STORAGE-12] - masvs-v2: [MASVS-PRIVACY-3] + masvs-v1: [MSTG-STORAGE-12, MSTG-NETWORK-1] + masvs-v2: [MASVS-PRIVACY-3, MASVS-PRIVACY-1] cwe: [359] refs: - https://support.apple.com/en-us/102188 @@ -18,6 +18,7 @@ refs: - https://support.google.com/googleplay/answer/11416267 - https://www.youtube.com/watch?v=J7TM0Yy0aTQ - https://www.youtube.com/watch?v=4rfF3y4xchU +beta-coverage: [MASWE-0112, MASWE-0108] status: new --- @@ -33,6 +34,7 @@ These declarations must clearly outline what data is collected, how it is used, - **Undeclared Data Collection and Purpose**: Failing to declare what data is being collected (e.g., location, contacts, identifiers) and for what purposes (e.g., analytics, personalization), leaving users unaware of how their information is used. - **Discrepancies in Declarations vs Behavior**: Differences between privacy label declarations (such as Apple's Privacy Nutrition Labels or Google's Data Safety Section) and the app's actual behavior, including undeclared data collection, sharing with third parties not mentioned in privacy labels, or using data for purposes not disclosed, which are against both Apple and Google guidelines. +- **Undeclared Data Sent in Network Traffic**: Data actually transmitted over the network, even over HTTPS, that goes beyond what is declared, such as over-collection beyond functional needs, sending detailed location/behavior analytics, unnecessary identifiers (e.g. IMEI, email, phone number), or sharing with third-party analytics/advertising services not reflected in the declarations. ## Impact diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0113.md b/weaknesses/MASVS-PRIVACY/MASWE-0069.md similarity index 98% rename from weaknesses/MASVS-PRIVACY/MASWE-0113.md rename to weaknesses/MASVS-PRIVACY/MASWE-0069.md index b9ccf76..6b50c62 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0113.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0069.md @@ -1,6 +1,6 @@ --- title: Lack of Proper Data Management Controls -id: MASWE-0113 +id: MASWE-0069 alias: data-management-controls platform: ["android", "ios"] profiles: ["P"] @@ -10,6 +10,7 @@ mappings: cwe: [359] refs: - https://developer.apple.com/app-store/app-privacy-details/#privacy-links +beta-coverage: [MASWE-0113] status: new --- diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0114.md b/weaknesses/MASVS-PRIVACY/MASWE-0070.md similarity index 89% rename from weaknesses/MASVS-PRIVACY/MASWE-0114.md rename to weaknesses/MASVS-PRIVACY/MASWE-0070.md index 172b911..f97d6e3 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0114.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0070.md @@ -1,6 +1,6 @@ --- title: Inadequate Data Visibility Controls -id: MASWE-0114 +id: MASWE-0070 alias: data-visibility-control platform: ["android", "ios"] profiles: ["P"] @@ -11,6 +11,7 @@ mappings: refs: - https://firebase.google.com/support/privacy/storing-privacy-settings - https://www.researchgate.net/publication/335863205_Demystifying_Hidden_Privacy_Settings_in_Mobile_Apps +beta-coverage: [MASWE-0114] status: new --- @@ -23,6 +24,7 @@ Ensuring that users have clear and granular options, typically in the form of ap ## Modes of Introduction - **Lack of Granular Privacy Settings**: Failing to provide privacy settings with sufficient granularity to allow users to control specific aspects of data collection and sharing, such as differentiating between location services, contacts, or media access. This lack of control results in users being unable to decide which types of information are shared and with whom. +- **Oversharing by Default**: Sharing flows that expose more than the user intends because privacy-reducing options are off by default or hard to find. For example, forwarding a message or picture that reveals the original sender's name unless the user explicitly enables an option such as "Hide Sender Name". ## Impact diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0115.md b/weaknesses/MASVS-PRIVACY/MASWE-0071.md similarity index 83% rename from weaknesses/MASVS-PRIVACY/MASWE-0115.md rename to weaknesses/MASVS-PRIVACY/MASWE-0071.md index 1eb007c..65513ce 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0115.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0071.md @@ -1,17 +1,18 @@ --- title: Inadequate or Ambiguous User Consent Mechanisms -id: MASWE-0115 +id: MASWE-0071 alias: ambiguous-consent-mechanisms platform: ["android", "ios"] profiles: ["P"] mappings: masvs-v1: [] masvs-v2: [MASVS-PRIVACY-4] - cwe: [359] + cwe: [200, 285, 358, 359] refs: - https://developer.apple.com/design/human-interface-guidelines/privacy#Requesting-permission - https://developer.apple.com/documentation/uikit/protecting_the_user_s_privacy/requesting_access_to_protected_resources - https://developer.android.com/training/permissions/requesting#explain +beta-coverage: [MASWE-0115, MASWE-0060] status: new --- @@ -27,6 +28,7 @@ In addition, users must be able to easily withdraw their consent at any time and - **Failure to Prompt for Consent Changes**: Failing to prompt the user for consent when data collection practices change or when additional data is collected beyond what was originally specified. - **Ambiguous Consent Mechanisms**: Consent is bundled with terms of service, often covering future use cases without notifying the user again. In some cases, consent is implied if the user doesn't explicitly deny access, leading to data collection without clear approval. +- **Lack of User Awareness When Exporting Data**: Sharing or exporting flows that do not make the user aware of the privacy consequences of their action. Users are generally free to share whatever they want, but they should be made aware of the risks. For example, when a user "Saves" a picture, warning them that the data will be exported to public/shared storage, or when using the iOS share sheet (`UIActivity`), being explicit about which items are shared and excluding activity types that would leak data to untrusted apps. ## Impact @@ -39,3 +41,4 @@ In addition, users must be able to easily withdraw their consent at any time and - **Prompt for Consent on Changes**: Establish mechanisms for prompting users for consent if data collection practices change or if additional data is being collected, ensuring transparency when app functionality evolves. - **Obtain Clear and Explicit User Consent for Immediate Actions**: Before accessing sensitive resources like sensors or local data (e.g., camera, location), always request explicit permission from the user. Clearly explain why the permission is needed, using mechanisms like [purpose strings](https://developer.apple.com/documentation/uikit/protecting_the_user_s_privacy/requesting_access_to_protected_resources) on iOS or [similar prompts](https://developer.android.com/training/permissions/requesting#explain) on Android, to ensure users understand the immediate use of their data. - **Ensure Informed and Transparent Consent**: Provide users with clear, specific information about what data will be collected, how it will be used, and the potential impact. Consent should not be hidden in terms of service or bundled for future uses. Users must confirm consent separately for each purpose, especially when permissions extend beyond the initial request. +- **Make Users Aware When Exporting or Sharing Data**: When the user shares or exports data (e.g. saving media to shared storage or using the system share sheet), surface the privacy consequences so they can make an informed choice, and default share flows to the least-exposing option. diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0117.md b/weaknesses/MASVS-PRIVACY/MASWE-0072.md similarity index 99% rename from weaknesses/MASVS-PRIVACY/MASWE-0117.md rename to weaknesses/MASVS-PRIVACY/MASWE-0072.md index 546f50a..11c7c16 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0117.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0072.md @@ -1,6 +1,6 @@ --- title: Inadequate Permission Management -id: MASWE-0117 +id: MASWE-0072 alias: inadequate-permission-management platform: ["android", "ios"] profiles: ["P"] @@ -19,7 +19,7 @@ refs: - https://arxiv.org/pdf/2203.10583 - https://ieeexplore.ieee.org/document/9001128 - https://www.enisa.europa.eu/sites/default/files/publications/WP2017%20O-2-2-4%20GDPR%20Mobile.pdf - +beta-coverage: [MASWE-0117] status: new --- diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0073.md b/weaknesses/MASVS-PRIVACY/MASWE-0073.md new file mode 100644 index 0000000..fa8243b --- /dev/null +++ b/weaknesses/MASVS-PRIVACY/MASWE-0073.md @@ -0,0 +1,34 @@ +--- +title: Inadequate Tracking Domains Declarations +id: MASWE-0073 +alias: tracking-domains-declarations +platform: ["android", "ios"] +profiles: ["P"] +mappings: + masvs-v1: [] + masvs-v2: [MASVS-PRIVACY-3] + cwe: [359] +refs: +- https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api +- https://developer.apple.com/documentation/bundleresources/privacy_manifest_files +- https://developer.apple.com/app-store/app-privacy-details/#user-tracking +- https://developer.apple.com/documentation/apptrackingtransparency/ +beta-coverage: [MASWE-0108] +draft: + description: | + Platforms increasingly require apps to declare the domains they use for tracking so the + system can enforce user tracking choices (e.g. Apple's privacy manifest lists tracking + domains, and connections to those domains are blocked when the user has not granted App + Tracking Transparency permission). This weakness occurs when an app fails to declare its + tracking domains, declares them incompletely, or declares domains inconsistently with the + app's actual network behavior. Inadequate or inaccurate tracking-domain declarations + prevent the platform from enforcing the user's tracking preferences and mislead users + about how their data is used, and can also lead to app-review rejections. + topics: + - declaring tracking domains in Apple's privacy manifest (NSPrivacyTrackingDomains) + - consistency between declared tracking domains and actual network connections + - interaction with App Tracking Transparency (ATT) enforcement + - incomplete or missing tracking-domain declarations for third-party SDKs +status: placeholder + +--- diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0074.md b/weaknesses/MASVS-PRIVACY/MASWE-0074.md new file mode 100644 index 0000000..500b636 --- /dev/null +++ b/weaknesses/MASVS-PRIVACY/MASWE-0074.md @@ -0,0 +1,43 @@ +--- +title: Usage of Non-Privacy-Preserving Functionality +id: MASWE-0074 +alias: non-privacy-preserving-functionality +platform: [android, ios] +profiles: [P] +mappings: + masvs-v2: [MASVS-PRIVACY-2] + cwe: [359] + +refs: +- https://datatracker.ietf.org/doc/html/rfc8252#appendix-B +- https://developer.apple.com/documentation/authenticationservices/aswebauthenticationsession +- https://developer.android.com/training/data-storage/shared/photopicker +- https://developer.apple.com/documentation/photokit/phpickerviewcontroller +draft: + description: | + Apps often have a choice between functionality that unnecessarily exposes user data and a + privacy-preserving alternative provided by the platform. Using the non-privacy-preserving + option when a privacy-friendly one exists leads to avoidable data exposure and over-collection. + + Examples include: + + - Using deprecated or non-isolated web-authentication flows such as `SFAuthenticationSession` + (deprecated) or embedding a general-purpose WebView for authentication, instead of + `ASWebAuthenticationSession` on iOS or Chrome Custom Tabs / Android Custom Tabs on Android + (see [RFC 8252, Appendix B](https://datatracker.ietf.org/doc/html/rfc8252#appendix-B)), + which keep credentials and browsing state isolated from the app. + - Requesting broad permissions unnecessarily instead of using a privacy-friendly API, e.g. + requesting full photo-library or camera access instead of using the system photo picker + (`PHPickerViewController` on iOS, the Android Photo Picker), which returns only the items + the user selects without any permission grant. + + Note: this weakness is intended to also incorporate the original content on non-privacy-preserving + functionality; confirm the intended source material before finalizing. + topics: + - use of ASWebAuthenticationSession / Custom Tabs instead of embedded WebViews or SFAuthenticationSession + - RFC 8252 best practices for OAuth in native apps + - using the system photo picker instead of requesting full photo/camera permissions + - preferring privacy-friendly, least-exposing platform APIs +status: placeholder + +--- diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0108.md b/weaknesses/MASVS-PRIVACY/MASWE-0108.md deleted file mode 100644 index 3084874..0000000 --- a/weaknesses/MASVS-PRIVACY/MASWE-0108.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: Sensitive Data in Network Traffic -id: MASWE-0108 -alias: sensitive-data-in-network-traffic -platform: ["android", "ios"] -profiles: ["P"] -mappings: - masvs-v1: [MSTG-NETWORK-1] - masvs-v2: [MASVS-PRIVACY-1] - cwe: [359] -status: new ---- - -## Overview - -Sensitive data in network traffic refers to the transmission of personal or confidential information over the network in a manner that could be intercepted and accessed by unauthorized parties. While the data may be sent using secure protocols such as HTTPS, the primary concern is the appropriateness and necessity of the data being shared or collected. - -The risk is not in the security of the transmission method, but in the privacy implications of the data being transmitted. This could include personal user information, location data, usage patterns, or any other information that could compromise user privacy. - -## Modes of Introduction - -This risk can be introduced in various scenarios, including: - -- Over-collection of user data beyond the app's functional requirements. -- Transmission of detailed user location or behavior analytics without proper anonymization. -- Sharing sensitive information with third-party services (e.g., analytics, advertising networks) without user consent. -- Unnecessary collection of identifiers like IMEI, email, or phone numbers. - -## Impact - -The impact of exposing sensitive data in network traffic includes: - -- **Violation of User Privacy**: Users may not be aware that their personal information is being transmitted, leading to privacy infringement. -- **Compliance and Legal Risks**: Breach of data protection laws and regulations (like GDPR), resulting in legal consequences and fines. -- **Loss of User Trust**: Users losing trust in the application, leading to reputational damage and potential loss of business. - -## Mitigations - -To mitigate this risk, consider the following strategies: - -- Minimize the collection of user data to what is strictly necessary for app functionality. -- Implement and strictly enforce data privacy policies, including user consent for data collection and sharing. -- Use anonymization techniques for user data that is transmitted for analytics or other secondary purposes. -- Regularly review and audit data transmitted over the network to ensure it aligns with privacy policies and user expectations. -- Provide clear user-facing privacy settings, allowing users to control what data is shared. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0008.md b/weaknesses/MASVS-RESILIENCE/MASWE-0049.md similarity index 97% rename from weaknesses/MASVS-RESILIENCE/MASWE-0008.md rename to weaknesses/MASVS-RESILIENCE/MASWE-0049.md index 1b68e78..5530405 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0008.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0049.md @@ -1,6 +1,6 @@ --- title: Missing Device Secure Lock Verification Implementation -id: MASWE-0008 +id: MASWE-0049 alias: secured-device-detection-not-implemented platform: [android, ios] profiles: [L2] @@ -18,6 +18,7 @@ draft: - user set a device passcode via `isDeviceSecure()` on Android better than only ensuring that the secure screen lock is set via `KeyguardManager.isKeyguardSecure()` - before attempting to authenticate, test to make sure that you actually have the ability to do so by calling the `LAContext.canEvaluatePolicy(_:error:)` method on iOS - to make sure that biometrics can be used, verify that the `kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly` or the `kSecAttrAccessibleWhenPasscodeSet` protection class is set when the `SecAccessControlCreateWithFlags` method is called +beta-coverage: [MASWE-0008] status: placeholder --- diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0067.md b/weaknesses/MASVS-RESILIENCE/MASWE-0050.md similarity index 55% rename from weaknesses/MASVS-RESILIENCE/MASWE-0067.md rename to weaknesses/MASVS-RESILIENCE/MASWE-0050.md index 93f40c8..d16952e 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0067.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0050.md @@ -1,24 +1,29 @@ --- -title: Debuggable Flag Not Disabled -id: MASWE-0067 +title: Debug Mechanisms Not Disabled +id: MASWE-0050 alias: debuggable-flag platform: [android, ios] profiles: [R] mappings: masvs-v1: [MSTG-RESILIENCE-2] - masvs-v2: [MASVS-RESILIENCE-4] + masvs-v2: [MASVS-RESILIENCE-4, MASVS-PLATFORM-2] android-risks: - https://developer.android.com/privacy-and-security/risks/android-debuggable cwe: [489] refs: - https://developer.android.com/guide/topics/manifest/application-element +- https://developer.android.com/reference/android/webkit/WebView#setWebContentsDebuggingEnabled(boolean) +- https://developer.apple.com/documentation/webkit/wkwebview/4111163-isinspectable +beta-coverage: [MASWE-0067, MASWE-0074] status: new --- ## Overview -Mobile apps typically include a configuration flag that determines whether the app is debuggable. While this flag is essential during development, leaving it enabled in production can introduce serious security risks. A debuggable app allows attackers to attach debuggers, inspect memory, manipulate execution flow, and bypass client-side controls, even on non-rooted or non-jailbroken devices. It may also expose sensitive information through verbose logging or developer tools that would otherwise be inaccessible. +Mobile apps typically include configuration flags and mechanisms that enable debugging. While these are essential during development, leaving them enabled in production can introduce serious security risks. A debuggable app allows attackers to attach debuggers, inspect memory, manipulate execution flow, and bypass client-side controls, even on non-rooted or non-jailbroken devices. It may also expose sensitive information through verbose logging or developer tools that would otherwise be inaccessible. + +Beyond the application-level debuggable flag, this weakness also covers WebView content debugging, which lets a remote inspector attach to the app's web content (e.g. Android's `WebView.setWebContentsDebuggingEnabled(true)` or iOS's `WKWebView.isInspectable`). Like the debuggable flag, this must be disabled in production builds. ## Impact @@ -30,7 +35,9 @@ Mobile apps typically include a configuration flag that determines whether the a ## Mode of Introduction - **Misconfigured Build Settings**: Misconfigured build settings can accidentally leave an app in a state that is debuggable, exposing it to security vulnerabilities. This can result from improper selection of build variants, errors in CI/CD configurations, or mistakenly applying debug settings to production environments. +- **WebView Content Debugging Left Enabled**: Leaving WebView content debugging enabled in production (e.g. `setWebContentsDebuggingEnabled(true)` on Android or `isInspectable = true` on iOS), allowing an attacker to inspect and manipulate the app's web content. ## Mitigations - Ensure that the debuggable flag in the app's configuration file is not enabled for production builds. For example, by using build variants or flavours to separate debug and release configurations, ensure that the debuggable flag is enabled only for debug builds. +- Disable WebView content debugging in production builds (do not call `setWebContentsDebuggingEnabled(true)` on Android; keep `WKWebView.isInspectable` set to `false` on iOS). diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0051.md b/weaknesses/MASVS-RESILIENCE/MASWE-0051.md new file mode 100644 index 0000000..1699527 --- /dev/null +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0051.md @@ -0,0 +1,25 @@ +--- +title: Code Obfuscation Not Implemented +id: MASWE-0051 +alias: code-obfuscation +platform: [android, ios] +profiles: [R] +mappings: + masvs-v1: [MSTG-RESILIENCE-9] + masvs-v2: [MASVS-RESILIENCE-3] + cwe: [693] + +beta-coverage: [MASWE-0089, MASWE-0092] +draft: + description: The app's code doesn’t implement effective obfuscation techniques to protect against reverse engineering and static analysis (CWE-693), e.g. polymorphic obfuscation, method-inlining, insertion of opaque predicates, instruction substitution, and instruction block chopping. This also covers failing to hinder static analysis tools from decompiling the app ("static damage control"). + topics: + - polymorphic obfuscation + - method-inlining + - insertion of opaque predicates + - instruction substitution + - instruction block chopping + - preventing/hindering decompilation by static analysis tools +status: placeholder + +--- + diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0090.md b/weaknesses/MASVS-RESILIENCE/MASWE-0052.md similarity index 91% rename from weaknesses/MASVS-RESILIENCE/MASWE-0090.md rename to weaknesses/MASVS-RESILIENCE/MASWE-0052.md index 07ab1db..ec39859 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0090.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0052.md @@ -1,6 +1,6 @@ --- title: Resource Obfuscation Not Implemented -id: MASWE-0090 +id: MASWE-0052 alias: resource-obfuscation platform: [android, ios] profiles: [R] @@ -9,6 +9,7 @@ mappings: masvs-v2: [MASVS-RESILIENCE-3] cwe: [693] +beta-coverage: [MASWE-0090] draft: description: e.g. resource obfuscation, binary encryption/packing topics: diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0091.md b/weaknesses/MASVS-RESILIENCE/MASWE-0053.md similarity index 90% rename from weaknesses/MASVS-RESILIENCE/MASWE-0091.md rename to weaknesses/MASVS-RESILIENCE/MASWE-0053.md index 2159ec9..c99e9d5 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0091.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0053.md @@ -1,6 +1,6 @@ --- title: Anti-Deobfuscation Techniques Not Implemented -id: MASWE-0091 +id: MASWE-0053 alias: anti-deobfuscation platform: [android, ios] profiles: [R] @@ -9,6 +9,7 @@ mappings: masvs-v2: [MASVS-RESILIENCE-3] cwe: [693] +beta-coverage: [MASWE-0091] draft: description: The app's code doesn’t implement effective anti-deobfuscation techniques to protect against reverse engineering (CWE-693) topics: diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0054.md b/weaknesses/MASVS-RESILIENCE/MASWE-0054.md new file mode 100644 index 0000000..73a0aeb --- /dev/null +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0054.md @@ -0,0 +1,39 @@ +--- +title: Debug Artifacts Not Removed +id: MASWE-0054 +alias: non-production-resources +platform: [android, ios] +profiles: [R] +mappings: + masvs-v1: [MSTG-CODE-3, MSTG-CODE-4] + masvs-v2: [MASVS-RESILIENCE-3] + cwe: [489, 497, 540, 912, 1295] + +beta-coverage: [MASWE-0094, MASWE-0093, MASWE-0095] +draft: + description: | + The app contains developer debug artifacts that should not be present in production builds. + These include verbose logging and code flows, enabled testing utilities (e.g. StrictMode), + debugging symbols, and, most critically, leftover debug/test code or backdoors, such as + hidden switches or an insecure trust manager, that can disable security controls (e.g. TLS + certificate validation). Such artifacts help adversaries understand the app's behavior and + potentially exploit it (CWE-497), may include sensitive information (CWE-540) or + implementation details (CWE-1295), and may allow bypassing security controls (CWE-489, + CWE-912). + + Note the distinction from [MASWE-0006](../MASVS-STORAGE/MASWE-0006.md): that weakness (in + STORAGE) covers developer _leftover artifacts_ that leak confidentiality, such as staging / + integration URLs, developer emails/usernames, and source code files hardcoded in the package. + This weakness (in RESILIENCE) covers developer _debug artifacts_ that weaken the app's + resilience, such as verbose logging, backdoors (e.g. an insecure trust manager behind a + hidden switch/config), debugging symbols, code flows, and testing utilities. + topics: + - verbose logging and code flows left in production + - enabled testing utilities (e.g. StrictMode) + - debugging symbols not stripped + - backdoors / hidden settings that disable security controls (e.g. TLS verification) + - leftover debug/test code +status: placeholder + +--- + diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0055.md b/weaknesses/MASVS-RESILIENCE/MASWE-0055.md new file mode 100644 index 0000000..3ac96f7 --- /dev/null +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0055.md @@ -0,0 +1,28 @@ +--- +title: No Application-Level Payload Encryption +id: MASWE-0055 +alias: data-unencrypted +platform: [android, ios] +profiles: [R] +mappings: + masvs-v1: [MSTG-RESILIENCE-13] + masvs-v2: [MASVS-RESILIENCE-3, MASVS-NETWORK-1] + cwe: [319] + +beta-coverage: [MASWE-0096] +draft: + description: | + The app does not apply an additional layer of application-level (payload / end-to-end) + encryption on top of the transport encryption. Even when the connection is encrypted (e.g. + HTTPS), an attacker who can perform a MITM attack (for example by bypassing certificate + pinning on a device they control) would be able to observe or tamper with the plaintext + payloads, revealing the inner workings of the app and its operations. Application-level + payload encryption raises the effort required to analyze and manipulate the app's traffic. + This is a resilience measure and is not necessarily related to privacy. + topics: + - application-level / end-to-end payload encryption on top of TLS + - protecting the confidentiality of app traffic against MITM on attacker-controlled devices +status: placeholder + +--- + diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0097.md b/weaknesses/MASVS-RESILIENCE/MASWE-0056.md similarity index 55% rename from weaknesses/MASVS-RESILIENCE/MASWE-0097.md rename to weaknesses/MASVS-RESILIENCE/MASWE-0056.md index 58b9e03..cd7dedc 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0097.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0056.md @@ -1,19 +1,21 @@ --- title: Root/Jailbreak Detection Not Implemented -id: MASWE-0097 +id: MASWE-0056 alias: root-jailbreak-detection platform: [android, ios] profiles: [R] mappings: - masvs-v1: [MSTG-RESILIENCE-1] - masvs-v2: [MASVS-RESILIENCE-1] + masvs-v1: [MSTG-RESILIENCE-1, MSTG-RESILIENCE-8] + masvs-v2: [MASVS-RESILIENCE-1, MASVS-RESILIENCE-4] cwe: [693] +beta-coverage: [MASWE-0097, MASWE-0103] draft: description: no root/jailbreak detection implemented e.g. check for Cydia, SuperSU, - Magisk, Xposed, etc. The app does not implement effective techniques to detect if the device is rooted or jailbroken (CWE-693). + Magisk, Xposed, etc. The app does not implement effective techniques to detect if the device is rooted or jailbroken (CWE-693). More broadly, the app should apply Runtime Application Self-Protection (RASP) techniques that detect a compromised environment and trigger appropriate responses. topics: - detection in place + - RASP techniques with detection triggering different responses - Effectiveness Assessment (e.g. bypassing the detection) status: placeholder diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0098.md b/weaknesses/MASVS-RESILIENCE/MASWE-0057.md similarity index 93% rename from weaknesses/MASVS-RESILIENCE/MASWE-0098.md rename to weaknesses/MASVS-RESILIENCE/MASWE-0057.md index fb29e6d..05162da 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0098.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0057.md @@ -1,6 +1,6 @@ --- title: App Virtualization Environment Detection Not Implemented -id: MASWE-0098 +id: MASWE-0057 alias: app-virtualization-detection platform: [android, ios] profiles: [R] @@ -8,6 +8,7 @@ mappings: masvs-v2: [MASVS-RESILIENCE-1] cwe: [693] +beta-coverage: [MASWE-0098] draft: description: The app's code doesn’t implement effective techniques to detect if it is running in a virtualized environment (CWE-693), e.g. checking for known virtualization software or anomalies in the environment. topics: diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0099.md b/weaknesses/MASVS-RESILIENCE/MASWE-0058.md similarity index 52% rename from weaknesses/MASVS-RESILIENCE/MASWE-0099.md rename to weaknesses/MASVS-RESILIENCE/MASWE-0058.md index 4d3d8ac..ab32393 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0099.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0058.md @@ -1,18 +1,20 @@ --- title: Emulator Detection Not Implemented -id: MASWE-0099 +id: MASWE-0058 alias: emulator-detection platform: [android, ios] profiles: [R] mappings: - masvs-v1: [MSTG-RESILIENCE-5] - masvs-v2: [MASVS-RESILIENCE-1] + masvs-v1: [MSTG-RESILIENCE-5, MSTG-RESILIENCE-8] + masvs-v2: [MASVS-RESILIENCE-1, MASVS-RESILIENCE-4] cwe: [693] +beta-coverage: [MASWE-0099, MASWE-0103] draft: - description: The app's code doesn’t implement effective techniques to detect if it is running in an emulator (CWE-693), e.g. identifying features and limitations available for commonly used emulation solutions + description: The app's code doesn’t implement effective techniques to detect if it is running in an emulator (CWE-693), e.g. identifying features and limitations available for commonly used emulation solutions. More broadly, the app should apply Runtime Application Self-Protection (RASP) techniques that detect a compromised environment and trigger appropriate responses. topics: - detection in place + - RASP techniques with detection triggering different responses - Effectiveness Assessment (e.g. bypassing the detection) status: placeholder diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0100.md b/weaknesses/MASVS-RESILIENCE/MASWE-0059.md similarity index 96% rename from weaknesses/MASVS-RESILIENCE/MASWE-0100.md rename to weaknesses/MASVS-RESILIENCE/MASWE-0059.md index 14055f5..a4a943d 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0100.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0059.md @@ -1,6 +1,6 @@ --- title: Device Attestation Not Implemented -id: MASWE-0100 +id: MASWE-0059 alias: device-attestation platform: [android, ios] profiles: [R] @@ -19,6 +19,7 @@ refs: - https://github.com/iansampson/AppAttest - https://github.com/firebase/firebase-ios-sdk/blob/v8.15.0/FirebaseAppCheck/Sources/AppAttestProvider/DCAppAttestService%2BFIRAppAttestService.h - https://blog.restlesslabs.com/john/ios-app-attest +beta-coverage: [MASWE-0100] draft: description: The app doesn't use App Attestation APIs, such as Google Play Integrity API, iOS DeviceCheck API,so the backend cannot ensure requests originate from a genuine app binary (CWE-693). This exposes the app to tampering, fraud, replay attacks, and unauthorized use of premium features. topics: diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0101.md b/weaknesses/MASVS-RESILIENCE/MASWE-0060.md similarity index 90% rename from weaknesses/MASVS-RESILIENCE/MASWE-0101.md rename to weaknesses/MASVS-RESILIENCE/MASWE-0060.md index f3cc129..81b283e 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0101.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0060.md @@ -1,6 +1,6 @@ --- title: Debugger Detection Not Implemented -id: MASWE-0101 +id: MASWE-0060 alias: debugger-detection platform: [android, ios] profiles: [R] @@ -9,6 +9,7 @@ mappings: masvs-v2: [MASVS-RESILIENCE-4] cwe: [693] +beta-coverage: [MASWE-0101] draft: description: The app's code doesn’t implement effective techniques to detect if it is being debugged (CWE-693), e.g. checking for debugger presence. topics: diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0102.md b/weaknesses/MASVS-RESILIENCE/MASWE-0061.md similarity index 92% rename from weaknesses/MASVS-RESILIENCE/MASWE-0102.md rename to weaknesses/MASVS-RESILIENCE/MASWE-0061.md index d54f234..ac611a9 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0102.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0061.md @@ -1,6 +1,6 @@ --- title: Dynamic Analysis Tools Detection Not Implemented -id: MASWE-0102 +id: MASWE-0061 alias: dynamic-analysis-tools platform: [android, ios] profiles: [R] @@ -9,6 +9,7 @@ mappings: masvs-v2: [MASVS-RESILIENCE-4] cwe: [693] +beta-coverage: [MASWE-0102] draft: description: The app's code doesn’t implement effective techniques to detect if it is being analyzed by dynamic analysis tools (CWE-693), e.g. Frida, Xposed, Ellekit, etc. topics: diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0062.md b/weaknesses/MASVS-RESILIENCE/MASWE-0062.md new file mode 100644 index 0000000..87dc8c8 --- /dev/null +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0062.md @@ -0,0 +1,40 @@ +--- +title: App Attestation Not Implemented +id: MASWE-0062 +alias: app-integrity +platform: [android, ios] +profiles: [R] +mappings: + masvs-v1: [MSTG-CODE-1] + masvs-v2: [MASVS-RESILIENCE-2] + cwe: [347, 693] + +refs: +- https://developer.apple.com/documentation/xcode/using-the-latest-code-signature-format +- https://developer.apple.com/documentation/devicecheck/preparing-to-use-the-app-attest-service +beta-coverage: [MASWE-0104, MASWE-0106] +draft: + description: | + The app does not attest its own authenticity/integrity, i.e. it doesn't implement effective + techniques to verify that the running binary is a genuine, unmodified copy of the app + (CWE-347). This includes verifying the app signature and binaries at runtime (e.g. detecting + an invalid app signing certificate, or an outdated signing scheme such as Android V1-only or + an iOS CodeDirectory version below 20400). + + This weakness previously focused on "Official Store Verification". Rather than only checking + whether the app was downloaded from an official store (e.g. by verifying the package name), + the emphasis is now on verifying the app's own signature / app attestation, which is a + stronger guarantee and also covers apps distributed through alternative stores. Checking the + app's signature or package name against the expected values remains one of the techniques. + topics: + - app signature / binaries checked at runtime + - native libraries verifying app integrity (e.g. AppAttest) + - invalid app signing certificate detection + - latest signing scheme not used (Android V1-only, iOS CodeDirectory < 20400) + - verifying the app's signature / package name (incl. official-store assurance) + - Effectiveness Assessment (e.g. bypassing the detection) + note: consider Static Code Modification? / Repackaging Detection Not Implemented +status: placeholder + +--- + diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0105.md b/weaknesses/MASVS-RESILIENCE/MASWE-0063.md similarity index 84% rename from weaknesses/MASVS-RESILIENCE/MASWE-0105.md rename to weaknesses/MASVS-RESILIENCE/MASWE-0063.md index 2e0ecdd..7809a57 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0105.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0063.md @@ -1,6 +1,6 @@ --- -title: Integrity of App Resources Not Verified -id: MASWE-0105 +title: App Resources Integrity Not Verified +id: MASWE-0063 alias: app-resources-integrity platform: [android, ios] profiles: [R] @@ -9,6 +9,7 @@ mappings: masvs-v2: [MASVS-RESILIENCE-2, MASVS-CODE-4] cwe: [693] +beta-coverage: [MASWE-0105] draft: description: The app's code doesn’t implement effective techniques to verify the integrity of its own resources (CWE-693). topics: diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0107.md b/weaknesses/MASVS-RESILIENCE/MASWE-0064.md similarity index 65% rename from weaknesses/MASVS-RESILIENCE/MASWE-0107.md rename to weaknesses/MASVS-RESILIENCE/MASWE-0064.md index b71fa44..a96dece 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0107.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0064.md @@ -1,6 +1,6 @@ --- -title: Runtime Code Integrity Not Verified -id: MASWE-0107 +title: Code Integrity Not Verified +id: MASWE-0064 alias: runtime-code-integrity platform: [android, ios] profiles: [R] @@ -9,10 +9,12 @@ mappings: masvs-v2: [MASVS-RESILIENCE-2] cwe: [693] +beta-coverage: [MASWE-0107] draft: - description: The app's code doesn’t implement effective techniques to verify the integrity of its own code at runtime (CWE-693). + description: The app's code doesn’t implement effective techniques to verify the integrity of its own code at runtime (CWE-693), e.g. detecting in-memory code/patch tampering or code injection. topics: - memory tampering detection + - runtime code/patch integrity checks status: placeholder --- diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0076.md b/weaknesses/MASVS-RESILIENCE/MASWE-0076.md new file mode 100644 index 0000000..e53c8cb --- /dev/null +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0076.md @@ -0,0 +1,32 @@ +--- +title: Malware Detection Not Implemented +id: MASWE-0076 +alias: malware-detection +platform: [android, ios] +profiles: [R] +mappings: + masvs-v2: [MASVS-RESILIENCE-2] + cwe: [693] + +refs: +- https://developers.google.com/android/play-protect +- https://support.google.com/googleplay/android-developer/answer/13375539 +draft: + description: | + The app does not implement or integrate techniques to detect the presence of malware on the + device or malicious apps/components that could target it (e.g. apps abusing accessibility + services, overlay-capable apps, known malicious packages, or a compromised runtime + environment). For high-assurance apps, detecting a potentially hostile environment allows + the app to warn the user, restrict functionality, or trigger other protective responses. + This complements environment-integrity checks such as + [MASWE-0056](MASWE-0056.md) (root/jailbreak detection) and platform services such as Google + Play Protect / the Play Integrity API. + topics: + - detecting known malicious apps/packages on the device + - detecting apps abusing accessibility services or screen overlays + - integrating platform malware/threat signals (e.g. Play Protect / Play Integrity) + - responses to a detected hostile environment (warn, restrict, block) + - Effectiveness Assessment (e.g. bypassing the detection) +status: placeholder + +--- diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0089.md b/weaknesses/MASVS-RESILIENCE/MASWE-0089.md deleted file mode 100644 index bb2e1ca..0000000 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0089.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: Code Obfuscation Not Implemented -id: MASWE-0089 -alias: code-obfuscation -platform: [android, ios] -profiles: [R] -mappings: - masvs-v1: [MSTG-RESILIENCE-9] - masvs-v2: [MASVS-RESILIENCE-3] - cwe: [693] - -draft: - description: The app's code doesn’t implement effective obfuscation techniques to protect against reverse engineering (CWE-693), e.g. polymorphic obfuscation, method-inlining, insertion of opaque predicates, instruction substitution, and instruction block chopping. - topics: - - polymorphic obfuscation - - method-inlining - - insertion of opaque predicates - - instruction substitution - - instruction block chopping -status: placeholder - ---- - diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0092.md b/weaknesses/MASVS-RESILIENCE/MASWE-0092.md deleted file mode 100644 index 6650d60..0000000 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0092.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -title: Static Analysis Tools Not Prevented -id: MASWE-0092 -alias: static-analysis-tools -platform: [android, ios] -profiles: [R] -mappings: - masvs-v2: [MASVS-RESILIENCE-3] - cwe: [693] - -draft: - description: AKA static damage control. The app's code doesn’t implement effective techniques to prevent static analysis tools from decompiling the app (CWE-693). - topics: - - prevent decompilation -status: placeholder - ---- - diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0093.md b/weaknesses/MASVS-RESILIENCE/MASWE-0093.md deleted file mode 100644 index a40d396..0000000 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0093.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: Debugging Symbols Not Removed -id: MASWE-0093 -alias: debugging-symbols -platform: [android, ios] -profiles: [R] -mappings: - masvs-v1: [MSTG-CODE-3] - masvs-v2: [MASVS-RESILIENCE-3] - cwe: [497, 540] - -draft: - description: The app contains debugging symbols, which can be exploited by attackers to understand the app's behavior (CWE-497). The app's debugging symbols are considered sensitive information (CWE-540) and should not be present in production builds. - topics: - - debugging symbols not removed -status: placeholder - ---- - diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0094.md b/weaknesses/MASVS-RESILIENCE/MASWE-0094.md deleted file mode 100644 index c383f95..0000000 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0094.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: Non-Production Resources Not Removed -id: MASWE-0094 -alias: non-production-resources -platform: [android, ios] -profiles: [R] -mappings: - masvs-v1: [MSTG-CODE-4] - masvs-v2: [MASVS-RESILIENCE-3] - cwe: [497, 540, 1295] - -draft: - description: The app contains non-production resources that should not be present in production builds, such as non-production URLs, code flows, or verbose logging. These resources help adversaries understand the app's behavior and potentially exploit it (CWE-497), may include sensitive information (CWE-540) or implementation details (CWE-1295). - topics: - - non-production URLs - - code flows - - verbose logging (e.g., using logging utilities) - - enabled testing utilities (e.g., StrictMode) -status: placeholder - ---- - diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0095.md b/weaknesses/MASVS-RESILIENCE/MASWE-0095.md deleted file mode 100644 index 3dabbd4..0000000 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0095.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: Code That Disables Security Controls Not Removed -id: MASWE-0095 -alias: code-disables-security -platform: [android, ios] -profiles: [R] -mappings: - masvs-v1: [MSTG-CODE-4] - masvs-v2: [MASVS-RESILIENCE-3] - cwe: [489, 912] - -draft: - description: The app contains leftover debugging logic or test code (CWE-489) that was not removed before release, which can disable critical protections like TLS certificate validation. It may also include hidden settings or functions that allow bypassing security controls (CWE-912), making the app vulnerable to manipulation. - topics: - - backdoors - - hidden settings to e.g. disable TLS verification -status: placeholder - ---- - diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0096.md b/weaknesses/MASVS-RESILIENCE/MASWE-0096.md deleted file mode 100644 index fe27399..0000000 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0096.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: Data Sent Unencrypted Over Encrypted Connections -id: MASWE-0096 -alias: data-unencrypted -platform: [android, ios] -profiles: [R] -mappings: - masvs-v1: [MSTG-RESILIENCE-13] - masvs-v2: [MASVS-RESILIENCE-3, MASVS-NETWORK-1] - cwe: [319] - -draft: - description: Use payload/End-2-End Encryption. Even if the connection is encrypted - (e.g. HTTPS), performing a MITM attack should not reveal any sensitive information - (e.g. about the inner workings of the app and its operations. This is not necessarily - related to privacy). - topics: null -status: placeholder - ---- - diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0103.md b/weaknesses/MASVS-RESILIENCE/MASWE-0103.md deleted file mode 100644 index 50509c2..0000000 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0103.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -title: RASP Techniques Not Implemented -id: MASWE-0103 -alias: rasp-techniques -platform: [android, ios] -profiles: [R] -mappings: - masvs-v1: [MSTG-RESILIENCE-8] - masvs-v2: [MASVS-RESILIENCE-4] - cwe: [693] - -draft: - description: The app's code doesn’t implement effective RASP techniques to detect if it is running in a compromised environment (CWE-693), e.g. Runtime Application Self-Protection, detection triggering different responses. - topics: - - detection triggering different responses -status: placeholder - ---- diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0104.md b/weaknesses/MASVS-RESILIENCE/MASWE-0104.md deleted file mode 100644 index bfdba9e..0000000 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0104.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: App Integrity Not Verified -id: MASWE-0104 -alias: app-integrity -platform: [android, ios] -profiles: [R] -mappings: - masvs-v1: [MSTG-CODE-1] - masvs-v2: [MASVS-RESILIENCE-2] - cwe: [347] - -refs: -- https://developer.apple.com/documentation/xcode/using-the-latest-code-signature-format -draft: - description: The app's code doesn’t implement effective techniques to verify the integrity of its own code (CWE-347), potentially relevant for apps in alternative app stores (not Google PlayStore or Apple AppStore). Also, e.g. Android V1 signing scheme only or iOS CodeDirectory v less than 20400. Also, e.g. App Signature or Binaries, native libraries including e.g. AppAttest. - topics: - - App Signature or Binaries check on runtime - - native libraries including e.g. AppAttest - - Invalid App Signing Certificate - - Latest Available Signing Scheme Not Used - Android V1 signing scheme only - - Latest Available Signing Scheme Not Used - iOS CodeDirectory v less than 20400 - - detection in place - - Effectiveness Assessment (e.g. bypassing the detection) - note: consider Static Code Modification? / Repackaging Detection Not Implemented -status: placeholder - ---- - diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0106.md b/weaknesses/MASVS-RESILIENCE/MASWE-0106.md deleted file mode 100644 index db5a2d7..0000000 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0106.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -title: Official Store Verification Not Implemented -id: MASWE-0106 -alias: store-verification -platform: [android, ios] -profiles: [R] -mappings: - masvs-v2: [MASVS-RESILIENCE-2] - cwe: [693] - -draft: - description: The app's code doesn’t implement effective techniques to verify if it is downloaded from an official store and therefore not relying on security and other assurances provided by the store (CWE-693). - topics: - - checking the app's signature or package name -status: placeholder - ---- - diff --git a/weaknesses/MASVS-STORAGE/MASWE-0001.md b/weaknesses/MASVS-STORAGE/MASWE-0001.md index cd3b511..3723c8a 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0001.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0001.md @@ -12,6 +12,7 @@ mappings: - https://developer.android.com/privacy-and-security/risks/log-info-disclosure refs: - https://stackoverflow.com/questions/45270547/is-read-logs-a-normal-or-dangerous-android-permission +beta-coverage: [MASWE-0001] status: new --- diff --git a/weaknesses/MASVS-STORAGE/MASWE-0002.md b/weaknesses/MASVS-STORAGE/MASWE-0002.md index 9ba2363..fde7b55 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0002.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0002.md @@ -1,30 +1,43 @@ --- -title: Sensitive Data Stored With Insufficient Access Restrictions in Internal Locations +title: Sensitive Data Not Excluded From Backup id: MASWE-0002 -alias: data-insufficient-access-restrictions-internal -platform: [android] -profiles: [L1, L2] +alias: data-not-excluded-backup +platform: [android, ios] +profiles: [L1, L2, P] mappings: - masvs-v1: [MSTG-STORAGE-2] - masvs-v2: [MASVS-STORAGE-2] - cwe: [200, 284, 732, 922] + masvs-v1: [MSTG-STORAGE-8] + masvs-v2: [MASVS-STORAGE-2, MASVS-PRIVACY-1] + cwe: [212, 313] android-risks: - - https://developer.android.com/privacy-and-security/risks/file-providers + - https://developer.android.com/privacy-and-security/risks/backup-best-practices refs: -- https://developer.android.com/about/versions/nougat/android-7.0-changes#permfilesys -- https://developer.android.com/privacy-and-security/security-tips#internal-storage -draft: - description: Sensitive data may be stored in internal locations without ensuring - exclusive app access (e.g. by using the wrong file permissions) and may be accessible - to other apps. - topics: - - File permissions (Android) - - improperly configured FileProvider (Android) - - Avoid the deprecated MODE_WORLD_WRITEABLE and MODE_WORLD_READABLE modes for IPC files, see https://developer.android.com/privacy-and-security/security-tips#internal-storage. They don't provide the ability to limit data access to particular applications, and they don't provide any control of data format. If you want to share your data with other app processes, consider using a content provider instead, which offers read and write permissions to other apps and can make dynamic permission grants on a case-by-case basis. - - Keychain items holding arbitrary data (excluding keys for this weakness) protected with weak protections such as kSecAttrAccessibleAlways, kSecAttrAccessibleAfterFirstUnlock, kSecAttrAccessibleWhenUnlocked (iOS) - -status: placeholder +- https://developer.android.com/guide/topics/data/autobackup#include-exclude-android-11 +- https://developer.android.com/guide/topics/data/autobackup#include-exclude-android-12 +- https://developer.android.com/guide/topics/data/autobackup#define-device-conditions +beta-coverage: [MASWE-0004, MASWE-0003] +status: new --- +## Overview + +iOS and Android automatically back up app data to cloud services, and users can also create local backups on physical machines, or backups are automatically created during data transfers when switching between phones. When developers fail to properly configure how their app handles backups and neglect to exclude sensitive files, the backups may contain sensitive user and app data. Under certain conditions, the backups may not be adequately secured by the cloud provider, or a malicious actor could tamper with the backed up files, potentially altering the app's behavior or extracting confidential information. + +## Impact + +- **Modification of App's Behavior**: An attacker can tamper with data inside the backup, altering the app's logic. For example, they could modify a database that tracks the state of premium features and then restore the modified backup to the device. Another common scenario is backing up the device before redeeming a one-time coupon and restoring the backup afterward, which would allow the malicious actor to reuse the same coupon multiple times. +- **Loss of Confidentiality**: Sensitive data stored in backups (e.g., personal information, photos, documents or audio files) may be extracted by attackers, leading to privacy breaches. +- **Leakage of Authentication Material**: An attacker can extract passwords, cryptographic keys, and session tokens to facilitate additional attacks, such as identity theft, account takeover, or unauthorized access. + +## Modes of Introduction + +- **Automatic System Backups**: By default, iOS and Android back up app data to the cloud once the user consents during the initial setup. +- **Local Backups**: Users can back up their devices to local systems (e.g., laptops). If local backups are stored unencrypted or not securely handled, attackers could tamper with this data. +- **Device-To-Device Transfer**: Transferring data between devices (e.g., via iCloud or Google's device-to-device migration tools) enables an attacker to perform similar attacks. + +## Mitigations + +- Exclude sensitive information, files, and key material from backups. +- If you have to include sensitive data in backups, ensure it is encrypted with an algorithm strong enough to protect the data for its entire required lifetime, even if the backup is later compromised. +- On Android, constrain when backups are allowed by declaring the appropriate [device conditions](https://developer.android.com/guide/topics/data/autobackup#define-device-conditions), such as requiring client-side encryption (`requireFlags="clientSideEncryption"`) and disabling device-to-device transfer (`deviceToDeviceTransfer`) for sensitive datasets, so that unencrypted copies are never produced. diff --git a/weaknesses/MASVS-STORAGE/MASWE-0003.md b/weaknesses/MASVS-STORAGE/MASWE-0003.md index 1addd59..57d6890 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0003.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0003.md @@ -1,25 +1,51 @@ --- -title: Backup Unencrypted +title: Sensitive Data Stored Unencrypted in Private Storage id: MASWE-0003 -alias: backup-unencrypted -platform: [android] +alias: data-unencrypted-private-storage +platform: [android, ios] profiles: [L2] mappings: - masvs-v1: [MSTG-STORAGE-8] - masvs-v2: [MASVS-STORAGE-2, MASVS-PRIVACY-1] - cwe: [313] + masvs-v1: [MSTG-STORAGE-2] + masvs-v2: [MASVS-STORAGE-1, MASVS-STORAGE-2, MASVS-CRYPTO-2, MASVS-PRIVACY-1] + mastg-v1: [MASTG-TEST-0052, MASTG-TEST-0001] + cwe: [200, 284, 312, 313, 732, 922] android-risks: - - https://developer.android.com/privacy-and-security/risks/backup-best-practices - + - https://developer.android.com/privacy-and-security/risks/file-providers refs: -- https://developer.android.com/guide/topics/data/autobackup#define-device-conditions -draft: - description: The app may not encrypt sensitive data in backups, which may compromise - data confidentiality. - topics: - - Backup Device Conditions clientSideEncryption and deviceToDeviceTransfer Not Checked - (Android) -status: placeholder - + - https://developer.apple.com/documentation/uikit/protecting_the_user_s_privacy/encrypting_your_app_s_files + - https://developer.android.com/about/versions/nougat/android-7.0-changes#permfilesys + - https://developer.android.com/privacy-and-security/security-tips#internal-storage +beta-coverage: [MASWE-0006, MASWE-0002, MASWE-0118] +status: new --- +## Overview + +Mobile apps may need to store sensitive data locally within private storage locations such as the application sandbox and this data is at risk of exposure via, for example, incorrect file permissions, an app vulnerability, device vulnerability or data backup mechanisms. + +[Sensitive data](../../Document/0x04b-Mobile-App-Security-Testing.md#identifying-sensitive-data "Sensitive Data") may include personally identifiable information (PII), passwords, cryptographic keys or session tokens. + +## Impact + +- **Loss of Confidentiality**: Under the right conditions an attacker could extract sensitive data stored internally within the application sandbox leading to loss of confidentiality and enable further attacks such as identity theft or account takeover. + +## Modes of Introduction + +- **Data Stored Unencrypted**: Sensitive data is written to the app's private data directory (sandbox) unencrypted. +- **Hardcoded Encryption Key**: Sensitive data is encrypted but the key is hardcoded inside the application. +- **Encryption Key Stored on Filesystem**: Sensitive data is encrypted but the key is stored alongside it or in another easily accessible location. +- **Encryption Used is Insufficient**: Sensitive data is encrypted but the encryption is not considered to be strong. +- **Insufficient Access Restrictions**: Even within private storage, sensitive files may be exposed to other apps through incorrect file permissions (e.g. the deprecated `MODE_WORLD_READABLE`/`MODE_WORLD_WRITEABLE` modes on Android), a misconfigured `FileProvider`, or Keychain items protected with weak accessibility attributes on iOS (e.g. `kSecAttrAccessibleAlways`). +- **Data Not Removed After Use**: Sensitive data written to private storage (including caches, temporary files, WebView state, and network caches) is retained longer than needed, widening the window of exposure. + +## Mitigations + +- Avoid storing sensitive data locally if not required for application functionality to reduce the likelihood and impact of this weakness. For example keeping PII server-side, rendering it at time of use, and removing any cached data on logout. +- Restrict access to private files: never use `MODE_WORLD_READABLE`/`MODE_WORLD_WRITEABLE`, share data through a properly configured `ContentProvider`/`FileProvider` with per-grant permissions instead, and on iOS store Keychain items with the strictest viable accessibility attribute (e.g. `kSecAttrAccessibleWhenUnlockedThisDeviceOnly`). +- Apply data minimization: clear sensitive data, caches, and temporary files as soon as they are no longer needed (e.g. on logout or when leaving a sensitive flow) to limit the window during which it can be exposed. +- Store cryptographic keys exclusively using the platform's hardware-backed keystore solution, such as the Android Keystore or the iOS Keychain. +- For storing other files and preferences, use platform-provided features for encrypting data at rest or other techniques implementing envelope encryption with Data Encryption Keys (DEK) and Key Encryption Keys (KEK) or equivalent methods. For example, on Android, use [`EncryptedFile`](https://developer.android.com/reference/androidx/security/crypto/EncryptedFile) or [`EncryptedSharedPreferences`](https://developer.android.com/reference/androidx/security/crypto/EncryptedSharedPreferences); on iOS, use [iOS Data Protection](https://developer.apple.com/documentation/uikit/protecting_the_user_s_privacy/encrypting_your_app_s_files). + +!!! Warning + + The **Jetpack security crypto library**, including the `EncryptedFile` and `EncryptedSharedPreferences` classes, has been [deprecated](https://developer.android.com/privacy-and-security/cryptography#jetpack_security_crypto_library). However, since an official replacement has not yet been released, we recommend using these classes until one is available. diff --git a/weaknesses/MASVS-STORAGE/MASWE-0004.md b/weaknesses/MASVS-STORAGE/MASWE-0004.md index 347ac52..bff40c3 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0004.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0004.md @@ -1,40 +1,52 @@ --- -title: Sensitive Data Not Excluded From Backup +title: Sensitive Data Stored Unencrypted Outside of Private Storage id: MASWE-0004 -alias: data-not-excluded-backup -platform: [android, ios] -profiles: [L1, L2, P] +alias: data-unencrypted-shared-storage-no-user-interaction +platform: [android] +profiles: [L1, L2] mappings: - masvs-v1: [MSTG-STORAGE-8] - masvs-v2: [MASVS-STORAGE-2, MASVS-PRIVACY-1] - cwe: [212] + masvs-v1: [MSTG-STORAGE-2] + masvs-v2: [MASVS-STORAGE-1, MASVS-STORAGE-2] + mastg-v1: [MASTG-TEST-0052, MASTG-TEST-0001] + cwe: [200, 284, 312, 313, 732, 921, 922] android-risks: - - https://developer.android.com/privacy-and-security/risks/backup-best-practices - -refs: -- https://developer.android.com/guide/topics/data/autobackup#include-exclude-android-11 -- https://developer.android.com/guide/topics/data/autobackup#include-exclude-android-12 + - https://developer.android.com/privacy-and-security/risks/sensitive-data-external-storage +beta-coverage: [MASWE-0007, MASWE-0002] status: new - --- ## Overview -iOS and Android automatically back up app data to cloud services, and users can also create local backups on physical machines, or backups are automatically created during data transfers when switching between phones. When developers fail to properly configure how their app handles backups and neglect to exclude sensitive files, the backups may contain sensitive user and app data. Under certain conditions, the backups may not be adequately secured by the cloud provider, or a malicious actor could tamper with the backed up files, potentially altering the app's behavior or extracting confidential information. +Apps frequently opt to store data in the external storage due to its larger capacity. However, this convenience comes with a potential security drawback. Once a malicious app is granted the relevant permissions, it can access this data without user consent or interaction at any time. Additionally, external storage like SD cards can be physically removed and read by a malicious actor. Even if the external storage is emulated by the system, the risk arises from improper file permissions or the misuse of APIs for saving files. In such cases, the files become vulnerable to unauthorized access, modifications and deletions, posing a security threat to the application. + +Developers may consider switching to Private Storage or Shared Storage Requiring User Interaction if they need more privacy and security. However, if the external storage is the most suitable for the app, it's a good practise to encrypt data stored in the external storage. Below you can find potential security impacts and mitigations linked to the use of the external storage. ## Impact -- **Modification of App's Behavior**: An attacker can tamper with data inside the backup, altering the app's logic. For example, they could modify a database that tracks the state of premium features and then restore the modified backup to the device. Another common scenario is backing up the device before redeeming a one-time coupon and restoring the backup afterward, which would allow the malicious actor to reuse the same coupon multiple times. -- **Loss of Confidentiality**: Sensitive data stored in backups (e.g., personal information, photos, documents or audio files) may be extracted by attackers, leading to privacy breaches. -- **Leakage of Authentication Material**: An attacker can extract passwords, cryptographic keys, and session tokens to facilitate additional attacks, such as identity theft, account takeover, or unauthorized access. +- **Loss of confidentiality**: An attacker can extract sensitive data stored externally, such as personal information and media like photos, documents, and audio files. + +- **Loss of secure material**: An attacker can extract passwords, cryptographic keys, and session tokens to facilitate additional attacks, such as identity theft or account takeover. + +- **Modification of app's behaviour**: An attacker can tamper with data used by the app, altering the app's logic. For example, they could modify a database describing the state of premium features or inject a malicious payload to enable further attacks such as SQL injection and Path Traversal. + +- **Modification of downloaded code**: An app can download new functionality from the Internet and store the executable code in external storage before loading it into the process. An attacker can modify this code before it is used by the app. ## Modes of Introduction -- **Automatic System Backups**: By default, iOS and Android back up app data to the cloud once the user consents during the initial setup. -- **Local Backups**: Users can back up their devices to local systems (e.g., laptops). If local backups are stored unencrypted or not securely handled, attackers could tamper with this data. -- **Device-To-Device Transfer**: Transferring data between devices (e.g., via iCloud or Google's device-to-device migration tools) enables an attacker to perform similar attacks. +This threat is primarily a concern for Android devices since they permit the use of external storage. Even if a device lacks physical external storage, Android emulates it to provide access to the external storage API. + +- **Data Stored Unencrypted**: Sensitive data is stored in the external storage unencrypted. +- **Hardcoded Encryption Key**: Sensitive data is encrypted and stored in the external storage but the key is hardcoded inside the application. +- **Encryption Key Stored on Filesystem**: Sensitive data is encrypted and stored in the external storage but the key is stored alongside it or in another easily accessible location. +- **Encryption Used is Insufficient**: Sensitive data is encrypted but the encryption is not considered to be strong. +- **Reuse of encryption key**: The encryption key is shared between two devices owned by a single user, enabling the process of data cloning between these devices in the external storage. + +On iOS, apps cannot directly write to or read from the arbitrary locations, as compared to desktop operating system or Android. iOS maintains strict sandboxing rules, meaning apps can only access their own sandboxed file directories. ## Mitigations -- Exclude sensitive information, files, and key material from backups. -- If you have to include sensitive data in backups, ensure it is encrypted with an algorithm strong enough to protect the data for its entire required lifetime, even if the backup is later compromised. +Sensitive data stored in the external storage should be encrypted, and any keys used for data encryption should be protected by the device's hardware-backed keystore, where available. It is highly discouraged to include cryptographic keys hardcoded inside the application. You can also consider storing your files in the [private app sandbox or internal storage](https://developer.android.com/training/data-storage/app-specific#internal) and using [Android's EncryptedFile API wrapper for file encryption](https://developer.android.com/reference/androidx/security/crypto/EncryptedFile). + +!!! Warning + + The **Jetpack security crypto library**, including the `EncryptedFile` and `EncryptedSharedPreferences` classes, has been [deprecated](https://developer.android.com/privacy-and-security/cryptography#jetpack_security_crypto_library). However, since an official replacement has not yet been released, we recommend using these classes until one is available. diff --git a/weaknesses/MASVS-STORAGE/MASWE-0005.md b/weaknesses/MASVS-STORAGE/MASWE-0005.md new file mode 100644 index 0000000..15b9789 --- /dev/null +++ b/weaknesses/MASVS-STORAGE/MASWE-0005.md @@ -0,0 +1,46 @@ +--- +title: Cryptographic Keys Stored Outside of Platform Keystore +id: MASWE-0005 +alias: crypto-keys-not-protected-at-rest +platform: [android, ios] +profiles: [L1, L2] +mappings: + masvs-v1: [MSTG-STORAGE-1, MSTG-CRYPTO-1] + masvs-v2: [MASVS-STORAGE-1, MASVS-CRYPTO-2] + cwe: [312, 318, 321, 322] + android-risks: + - https://developer.android.com/privacy-and-security/risks/hardcoded-cryptographic-secrets +refs: +- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf +- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-175Br1.pdf +- https://developer.android.com/privacy-and-security/keystore#ImportingEncryptedKeys +- https://developer.apple.com/documentation/security/certificate_key_and_trust_services/keys/storing_keys_as_data +beta-coverage: [MASWE-0013, MASWE-0014, MASWE-0016] +status: new +--- + +## Overview + +Cryptographic keys are essential for securing sensitive data in mobile applications. However, if these keys are not properly protected at rest, they can be easily compromised. This weakness involves storing cryptographic keys in insecure locations, such as unencrypted SharedPreferences, unprotected files, hardcoding them within the application code, or including them in source control and versioning systems which may end in the final application package in production. + +Attackers can decompile or reverse-engineer the app to extract hardcoded keys. + +## Impact + +- **Unauthorized Access**: If cryptographic keys are not properly protected, attackers may gain unauthorized access to sensitive data and potential identity theft. +- **Loss of Integrity**: Compromised keys can allow attackers to tamper with encrypted data. +- **Loss of Confidentiality**: Sensitive information can be exposed, resulting in a loss of confidentiality. Once keys are exposed, all data encrypted with those keys is at risk. + +## Modes of Introduction + +- **Insecure Storage Locations**: Storing cryptographic keys in locations that are not designed for secure storage, such as regular configuration or user preferences files, application data directories, or other areas lacking encryption and access control mechanisms. +- **Hardcoded Cryptographic Keys**: Including cryptographic keys directly in the application code, making them susceptible to extraction through decompilation and reverse-engineering. +- **Insecure Imported Keys**: Importing cryptographic keys from untrusted sources or without validating their integrity, which can lead to the introduction of malicious or compromised keys into the application environment. + +## Mitigations + +- **Use Platform Keystores**: Where possible, generate cryptographic keys dynamically on the device, rather than using predefined keys, and ensure that they are securely stored after creation. For this you can use the platform-specific keystores, such as the [Android KeyStore](https://developer.android.com/training/articles/keystore) or [iOS KeyChain](https://developer.apple.com/documentation/security/keychain_services). +- **Implement Strongest Hardware Security Solutions**: For the most critical cases and whenever [available and compatible](https://developer.android.com/privacy-and-security/keystore#HardwareSecurityModule) for the use case at hand, leverage the strongest hardware-backed security options such as [Android StrongBox](https://source.android.com/docs/security/features/keystore/strongbox) or iOS's Secure Enclave [`kSecAttrTokenIDSecureEnclave`](https://developer.apple.com/documentation/security/ksecattrtokenidsecureenclave) option to ensure the highest protection including physical and side-channel attacks. +- **Use Cryptographic Key Management Systems**: Securely retrieve keys from server-side services that provide secure storage, access control, and auditing for sensitive data. For example, AWS Secrets Manager, Azure Key Vault, or Google Cloud Secret Manager are some popular managed secrets storage solutions. The app can securely retrieve the necessary secrets at runtime through secure, authenticated API calls. +- **Encrypt and Wrap Keys**: Whenever storing keys in platform keystores is not suitable for the use case or keys need to be exported, use envelope encryption (DEK+KEK) and key wrapping techniques as specified in [NIST.SP.800-175Br1 5.3.5](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-175Br1.pdf) to protect cryptographic keys before storing them. +- **Follow Standard Key Management Best Practices**: Implement proper key management practices, including key rotation and robust protection mechanisms for keys in storage as outlined in [NIST.SP.800-57pt1r5 6.2.2](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf), ensuring availability, integrity, confidentiality, and proper association with usage, entities, and related information. diff --git a/weaknesses/MASVS-STORAGE/MASWE-0006.md b/weaknesses/MASVS-STORAGE/MASWE-0006.md index db84dd8..440ec0a 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0006.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0006.md @@ -1,42 +1,58 @@ --- -title: Sensitive Data Stored Unencrypted in Private Storage Locations +title: Sensitive Data Hardcoded in the App Package id: MASWE-0006 -alias: data-unencrypted-private-storage +alias: data-hardcoded-app-package platform: [android, ios] -profiles: [L2] +profiles: [L1, L2] mappings: - masvs-v1: [MSTG-STORAGE-2] - masvs-v2: [MASVS-STORAGE-1, MASVS-CRYPTO-2] - mastg-v1: [MASTG-TEST-0052, MASTG-TEST-0001] - cwe: [312, 313, 922] + masvs-v1: [MSTG-STORAGE-1, MSTG-CODE-2] + masvs-v2: [MASVS-STORAGE-1] + cwe: [312, 540, 798] + android-risks: + - https://developer.android.com/privacy-and-security/risks/insecure-api-usage refs: - - https://developer.apple.com/documentation/uikit/protecting_the_user_s_privacy/encrypting_your_app_s_files +- https://cloud.google.com/docs/authentication/api-keys#securing +- https://cloud.google.com/docs/authentication/api-keys#api_key_restrictions +- https://github.com/gitleaks/gitleaks +beta-coverage: [MASWE-0005, MASWE-0013, MASWE-0036] status: new --- ## Overview -Mobile apps may need to store sensitive data locally within private storage locations such as the application sandbox and this data is at risk of exposure via, for example, incorrect file permissions, an app vulnerability, device vulnerability or data backup mechanisms. +Mobile apps frequently ship sensitive data inside the app package (APK/IPA) itself. Because the package can be freely downloaded and reverse-engineered, any secret embedded in the source code, compiled binaries, resources, or bundled configuration files can be extracted with little effort. -[Sensitive data](../../Document/0x04b-Mobile-App-Security-Testing.md#identifying-sensitive-data "Sensitive Data") may include personally identifiable information (PII), passwords, cryptographic keys or session tokens. +This weakness covers any sensitive data that is hardcoded and shipped with the app, including: + +- **API keys and secrets** for first- or third-party services. +- **Credentials** such as passwords, session tokens, or other authentication material. +- **Cryptographic material** such as symmetric keys or private keys embedded directly in the package (as opposed to being generated and stored in a platform keystore, see [MASWE-0005](MASWE-0005.md)). +- **Developer leftover artifacts**, such as staging or integration URLs, developer emails and usernames, and source code files left in the package (e.g. `.swift`, `.cpp`, map files, or other build artifacts) that leak internal information. + +Note that developer _debug_ artifacts (verbose logging, backdoors, testing utilities, hidden switches) are covered separately under resilience in [MASWE-0054](../MASVS-RESILIENCE/MASWE-0054.md). The focus here is on hardcoded sensitive data that leaks confidentiality regardless of any anti-tampering considerations. ## Impact -- **Loss of Confidentiality**: Under the right conditions an attacker could extract sensitive data stored internally within the application sandbox leading to loss of confidentiality and enable further attacks such as identity theft or account takeover. +- **Loss of Confidentiality**: Hardcoded secrets, credentials, and internal information can be extracted by anyone able to obtain the app package. +- **Financial Loss**: Attackers can abuse compromised API keys to make unauthorized, billed API calls (e.g., AI/ML services), resulting in unexpected charges to the app owner. +- **Compromise of System Integrity and Business Operations**: Extracted keys and credentials can grant unauthorized access to sensitive resources and backend services, potentially leading to service disruption, policy-violation suspensions, or Denial of Service. +- **Bypass of Protection Mechanisms**: Hardcoded keys can make it easier to unlock paid features, access restricted content, or otherwise circumvent app protections. ## Modes of Introduction -- **Data Stored Unencrypted**: Sensitive data is written to the app's private data directory (sandbox) unencrypted. -- **Hardcoded Encryption Key**: Sensitive data is encrypted but the key is hardcoded inside the application. -- **Encryption Key Stored on Filesystem**: Sensitive data is encrypted but the key is stored alongside it or in another easily accessible location. -- **Encryption Used is Insufficient**: Sensitive data is encrypted but the encryption is not considered to be strong. +Sensitive data can be hardcoded in several places that end up in the final package: -## Mitigations +- **App Source Code**: secrets embedded directly in the compiled code. +- **App Assets and Resources**: configuration files, manifests, property lists, string resources, and other bundled files. +- **Libraries**: configuration files or source code of first-party, third-party, or transitive dependencies. +- **Build and Developer Leftovers**: staging/integration endpoints, developer identities, and source files inadvertently packaged with the app. -- Avoid storing sensitive data locally if not required for application functionality to reduce the likelihood and impact of this weakness. For example keeping PII server-side, rendering it at time of use, and removing any cached data on logout. -- Store cryptographic keys exclusively using the platform's hardware-backed keystore solution, such as the Android Keystore or the iOS Keychain. -- For storing other files and preferences, use platform-provided features for encrypting data at rest or other techniques implementing envelope encryption with Data Encryption Keys (DEK) and Key Encryption Keys (KEK) or equivalent methods. For example, on Android, use [`EncryptedFile`](https://developer.android.com/reference/androidx/security/crypto/EncryptedFile) or [`EncryptedSharedPreferences`](https://developer.android.com/reference/androidx/security/crypto/EncryptedSharedPreferences); on iOS, use [iOS Data Protection](https://developer.apple.com/documentation/uikit/protecting_the_user_s_privacy/encrypting_your_app_s_files). - -!!! Warning +## Mitigations - The **Jetpack security crypto library**, including the `EncryptedFile` and `EncryptedSharedPreferences` classes, has been [deprecated](https://developer.android.com/privacy-and-security/cryptography#jetpack_security_crypto_library). However, since an official replacement has not yet been released, we recommend using these classes until one is available. +- Use a stateful API service that provides secure authentication, client validation, and session controls. Implement dynamic tokens that expire after a reasonably short time (e.g., 1 hour) to reduce the impact of key exposure, and ensure proper error handling and logging to detect unauthorized access attempts. Consider OAuth 2.0 and libraries such as AppAuth to simplify secure OAuth flows. +- If a stateful API service is not viable, use a stateless API service fronted by a middleware solution (API proxy or gateway) that proxies requests between the app and the API endpoint, keeping the static secret server-side rather than in the client. Use JSON Web Tokens (JWT) and JSON Web Signature (JWS) as appropriate. +- If secrets must be hardcoded, configure them with the minimum required permissions and restrictions to reduce the impact in case of exposure. +- Consider using a [Key Management Service](https://cloud.google.com/kms/docs/key-management-service) to retrieve secrets at runtime after validating app integrity. +- Store cryptographic keys and authentication material using the platform's hardware-backed keystore (Android Keystore, iOS Keychain) instead of embedding them in the package. See [MASWE-0005](MASWE-0005.md). +- Regularly audit the codebase and dependencies for hardcoded sensitive data and developer leftovers (e.g. using tools such as [gitleaks](https://github.com/gitleaks/gitleaks)) and strip build artifacts and source files from release packages. +- As a **last resort** when no other secure option is available, white-box cryptography, code/resource obfuscation, and RASP can raise the effort required to extract secrets, ensuring keys are only assembled in memory when needed. These techniques deter but do not prevent extraction and must not replace the mitigations above. diff --git a/weaknesses/MASVS-STORAGE/MASWE-0007.md b/weaknesses/MASVS-STORAGE/MASWE-0007.md deleted file mode 100644 index fb362ee..0000000 --- a/weaknesses/MASVS-STORAGE/MASWE-0007.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: Sensitive Data Stored Unencrypted in Shared Storage Requiring No User Interaction -id: MASWE-0007 -alias: data-unencrypted-shared-storage-no-user-interaction -platform: [android] -profiles: [L1, L2] -mappings: - masvs-v1: [MSTG-STORAGE-2] - masvs-v2: [MASVS-STORAGE-1] - mastg-v1: [MASTG-TEST-0052, MASTG-TEST-0001] - cwe: [312, 313, 921, 922] - android-risks: - - https://developer.android.com/privacy-and-security/risks/sensitive-data-external-storage -status: new ---- - -## Overview - -Apps frequently opt to store data in the external storage due to its larger capacity. However, this convenience comes with a potential security drawback. Once a malicious app is granted the relevant permissions, it can access this data without user consent or interaction at any time. Additionally, external storage like SD cards can be physically removed and read by a malicious actor. Even if the external storage is emulated by the system, the risk arises from improper file permissions or the misuse of APIs for saving files. In such cases, the files become vulnerable to unauthorized access, modifications and deletions, posing a security threat to the application. - -Developers may consider switching to Private Storage or Shared Storage Requiring User Interaction if they need more privacy and security. However, if the external storage is the most suitable for the app, it's a good practise to encrypt data stored in the external storage. Below you can find potential security impacts and mitigations linked to the use of the external storage. - -## Impact - -- **Loss of confidentiality**: An attacker can extract sensitive data stored externally, such as personal information and media like photos, documents, and audio files. - -- **Loss of secure material**: An attacker can extract passwords, cryptographic keys, and session tokens to facilitate additional attacks, such as identity theft or account takeover. - -- **Modification of app's behaviour**: An attacker can tamper with data used by the app, altering the app's logic. For example, they could modify a database describing the state of premium features or inject a malicious payload to enable further attacks such as SQL injection and Path Traversal. - -- **Modification of downloaded code**: An app can download new functionality from the Internet and store the executable code in external storage before loading it into the process. An attacker can modify this code before it is used by the app. - -## Modes of Introduction - -This threat is primarily a concern for Android devices since they permit the use of external storage. Even if a device lacks physical external storage, Android emulates it to provide access to the external storage API. - -- **Data Stored Unencrypted**: Sensitive data is stored in the external storage unencrypted. -- **Hardcoded Encryption Key**: Sensitive data is encrypted and stored in the external storage but the key is hardcoded inside the application. -- **Encryption Key Stored on Filesystem**: Sensitive data is encrypted and stored in the external storage but the key is stored alongside it or in another easily accessible location. -- **Encryption Used is Insufficient**: Sensitive data is encrypted but the encryption is not considered to be strong. -- **Reuse of encryption key**: The encryption key is shared between two devices owned by a single user, enabling the process of data cloning between these devices in the external storage. - -On iOS, apps cannot directly write to or read from the arbitrary locations, as compared to desktop operating system or Android. iOS maintains strict sandboxing rules, meaning apps can only access their own sandboxed file directories. - -## Mitigations - -Sensitive data stored in the external storage should be encrypted, and any keys used for data encryption should be protected by the device's hardware-backed keystore, where available. It is highly discouraged to include cryptographic keys hardcoded inside the application. You can also consider storing your files in the [private app sandbox or internal storage](https://developer.android.com/training/data-storage/app-specific#internal) and using [Android's EncryptedFile API wrapper for file encryption](https://developer.android.com/reference/androidx/security/crypto/EncryptedFile). - -!!! Warning - - The **Jetpack security crypto library**, including the `EncryptedFile` and `EncryptedSharedPreferences` classes, has been [deprecated](https://developer.android.com/privacy-and-security/cryptography#jetpack_security_crypto_library). However, since an official replacement has not yet been released, we recommend using these classes until one is available. From ad574de2aae66e5a353e440c5df74653e24b490f Mon Sep 17 00:00:00 2001 From: Carlos Holguera Date: Sun, 19 Jul 2026 10:49:35 +0200 Subject: [PATCH 03/70] add richer draft descriptions --- weaknesses/MASVS-AUTH/MASWE-0022.md | 17 +++++++++++++---- weaknesses/MASVS-AUTH/MASWE-0023.md | 13 +++++++++++-- weaknesses/MASVS-CODE/MASWE-0040.md | 14 +++++++++++--- weaknesses/MASVS-CODE/MASWE-0043.md | 15 ++++++++++++--- weaknesses/MASVS-CODE/MASWE-0045.md | 14 +++++++++++--- weaknesses/MASVS-CODE/MASWE-0075.md | 4 ++-- weaknesses/MASVS-CRYPTO/MASWE-0011.md | 2 +- weaknesses/MASVS-CRYPTO/MASWE-0012.md | 2 +- weaknesses/MASVS-CRYPTO/MASWE-0013.md | 11 ++++++++++- weaknesses/MASVS-PLATFORM/MASWE-0032.md | 20 +++++++++++++------- weaknesses/MASVS-PLATFORM/MASWE-0034.md | 14 +++++++++++--- weaknesses/MASVS-RESILIENCE/MASWE-0049.md | 7 ++++++- weaknesses/MASVS-RESILIENCE/MASWE-0052.md | 12 +++++++++--- weaknesses/MASVS-RESILIENCE/MASWE-0053.md | 12 ++++++++++-- weaknesses/MASVS-RESILIENCE/MASWE-0057.md | 12 ++++++++++-- weaknesses/MASVS-RESILIENCE/MASWE-0059.md | 13 +++++++++++-- weaknesses/MASVS-RESILIENCE/MASWE-0060.md | 11 +++++++++-- weaknesses/MASVS-RESILIENCE/MASWE-0061.md | 13 ++++++++++--- weaknesses/MASVS-RESILIENCE/MASWE-0063.md | 14 ++++++++++---- weaknesses/MASVS-RESILIENCE/MASWE-0064.md | 15 +++++++++++---- weaknesses/MASVS-RESILIENCE/MASWE-0076.md | 2 +- weaknesses/MASVS-STORAGE/MASWE-0006.md | 6 +++--- 22 files changed, 186 insertions(+), 57 deletions(-) diff --git a/weaknesses/MASVS-AUTH/MASWE-0022.md b/weaknesses/MASVS-AUTH/MASWE-0022.md index 5a93f21..87b667d 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0022.md +++ b/weaknesses/MASVS-AUTH/MASWE-0022.md @@ -14,11 +14,20 @@ refs: - https://developer.apple.com/documentation/localauthentication/lapolicy/deviceownerauthenticationwithbiometrics/ beta-coverage: [MASWE-0045] draft: - description: e.g. via DEVICE_CREDENTIAL on Android and LAPolicy.deviceOwnerAuthentication - on iOS + description: | + For sensitive transactions, allowing authentication to silently fall back from biometrics to a + weaker device credential (PIN/pattern/password) can drop the assurance level below what the + operation requires. On Android this happens when `DEVICE_CREDENTIAL` is permitted as an + authenticator (e.g. via `BiometricPrompt.setAllowedAuthenticators`) for a high-value action; on + iOS when `LAPolicy.deviceOwnerAuthentication` is used instead of + `LAPolicy.deviceOwnerAuthenticationWithBiometrics`. Sensitive transactions should require + biometrics and be bound to a biometric-protected key rather than permitting a non-biometric + fallback. topics: - - DEVICE_CREDENTIAL on Android - - LAPolicy.deviceOwnerAuthentication on iOS + - allowing DEVICE_CREDENTIAL fallback on Android (BiometricPrompt.setAllowedAuthenticators) + - using LAPolicy.deviceOwnerAuthentication instead of ...WithBiometrics on iOS + - not binding the sensitive operation to a biometric-only key + - matching the required assurance level to the transaction sensitivity status: placeholder --- diff --git a/weaknesses/MASVS-AUTH/MASWE-0023.md b/weaknesses/MASVS-AUTH/MASWE-0023.md index 1ab8c18..2caac26 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0023.md +++ b/weaknesses/MASVS-AUTH/MASWE-0023.md @@ -10,14 +10,23 @@ mappings: beta-coverage: [MASWE-0046] draft: - description: Biometric related crypto keys should be is invalidated by default whenever - new biometric enrollments are added. + description: | + Cryptographic keys gated by biometric authentication should be invalidated when the set of + enrolled biometrics changes, so that an attacker who enrolls a new fingerprint or face cannot + unlock keys bound to the legitimate user's biometrics. On Android this invalidation is enabled by + default but can be turned off with `setInvalidatedByBiometricEnrollment(false)`; on iOS it must be + explicitly enabled by using `SecAccessControlCreateFlags.biometryCurrentSet` (formerly + `touchIDCurrentSet`) when creating the access control, which invalidates the keychain item when a + biometric is added or removed. This weakness occurs when the app leaves biometric-bound keys valid + across new enrollments. topics: - Enabled by default on Android but can be disabled by calling `setInvalidatedByBiometricEnrollment(false)` - Disabled by default on iOS but can be enabled using `SecAccessControlCreateFlags.biometryCurrentSet` (prev. `touchIDCurrentSet`) when setting access control (since iOS 9). This invalidates keychain items when a fingerprint is added or removed. See kSecAccessControlTouchIDCurrentSet, biometryCurrentSet. + - verifying invalidation-on-enrollment is not disabled on Android (setInvalidatedByBiometricEnrollment) + - responding safely when a key has been invalidated (e.g. requiring re-enrollment/re-auth) status: placeholder --- diff --git a/weaknesses/MASVS-CODE/MASWE-0040.md b/weaknesses/MASVS-CODE/MASWE-0040.md index 15d2c4e..98ba912 100644 --- a/weaknesses/MASVS-CODE/MASWE-0040.md +++ b/weaknesses/MASVS-CODE/MASWE-0040.md @@ -15,10 +15,18 @@ refs: - https://medium.com/swlh/updating-users-to-the-latest-app-release-on-ios-ed96e4c76705 - https://gist.github.com/DineshKachhot/f63fcebceca6351fc982cafd38f6f05c draft: - description: Check if the app enforces updates e.g. via AppUpdateManager on Android or itunes check on app version on iOS. However, the backend would be enforcing this and not only the app locally. + description: | + When a critical vulnerability is discovered in an app that is already in production, the developer + needs a way to force users onto a fixed version. This weakness occurs when the app has no + enforced-update mechanism (e.g. Android In-App Updates / `AppUpdateManager`, or an App Store + version check on iOS), or when the update requirement is enforced only on the client side and can + therefore be bypassed. Robust enforcement requires the backend to signal and enforce the minimum + acceptable version rather than relying solely on local checks. topics: - - The in‑app update mechanism isn't used at all (CWE-693). - - The update enforcement occurs purely locally (client‑side) without server‑side checks (CWE-602). + - no in-app / enforced update mechanism at all (CWE-693) + - update enforcement only client-side without a server-side check (CWE-602) + - AppUpdateManager (Android In-App Updates) / App Store version check (iOS) + - server-driven minimum-supported-version enforcement beta-coverage: [MASWE-0075] status: placeholder diff --git a/weaknesses/MASVS-CODE/MASWE-0043.md b/weaknesses/MASVS-CODE/MASWE-0043.md index 85ec151..4c47ada 100644 --- a/weaknesses/MASVS-CODE/MASWE-0043.md +++ b/weaknesses/MASVS-CODE/MASWE-0043.md @@ -9,10 +9,19 @@ mappings: cwe: [693, 1357] draft: - description: The app does not target the latest platform version (e.g., via targetSdkVersion on Android or by using an older Xcode/toolchain), and as a result, misses out on the most recent platform-enforced security protections (e.g., scoped storage, permission auto-reset, modern TLS handling) (CWE-693 and CWE-1357). + description: | + Targeting the latest platform version (via `targetSdkVersion` on Android or by building with a + recent Xcode/SDK on iOS) opts the app into the newest platform-enforced security protections and + behavior changes, such as scoped storage, stricter runtime-permission handling, permission + auto-reset, and modern TLS defaults. When an app targets an old version, the OS applies backward + compatibility behaviors and the app misses these protections (CWE-693, CWE-1357). This is distinct + from the minimum supported version (@MASWE-0042): here the concern is the + target/compiled version. topics: - - targetSDK on Android - - XCode version on iOS + - targetSdkVersion on Android + - Xcode / SDK version used to build on iOS + - missing newer platform-enforced protections (scoped storage, permission auto-reset, TLS defaults) + - backward-compatibility behaviors applied to apps targeting old versions beta-coverage: [MASWE-0078] status: placeholder diff --git a/weaknesses/MASVS-CODE/MASWE-0045.md b/weaknesses/MASVS-CODE/MASWE-0045.md index f8debf8..9b441c1 100644 --- a/weaknesses/MASVS-CODE/MASWE-0045.md +++ b/weaknesses/MASVS-CODE/MASWE-0045.md @@ -15,10 +15,18 @@ refs: - https://sensepost.com/blog/2021/on-ios-binary-protections/ - https://www.sans.org/blog/stack-canaries-gingerly-sidestepping-the-cage/ draft: - description: The app is compiled without enabling memory protection mechanisms such as stack canaries, address space layout randomization (ASLR), non-executable memory, or position-independent executables (PIE), reducing resistance to memory corruption attacks (CWE-693). + description: | + Compilers and toolchains provide exploit-mitigation features that make memory-corruption bugs + harder to exploit. This weakness occurs when the app's native code is built without them, such as + stack canaries, Address Space Layout Randomization (ASLR) / Position-Independent Executable (PIE), + non-executable memory (NX/DEP), and fortified (bounds-checked) libc functions. Missing these + mitigations lowers the effort required to exploit memory-corruption vulnerabilities (CWE-693). topics: - - PIC - - stack canaries + - Position-Independent Executable (PIE) / PIC + - stack canaries (stack-smashing protection) + - non-executable memory (NX / DEP) + - fortify-source / bounds-checked libc functions + - Automatic Reference Counting / memory-safe language usage where applicable note: PIC cannot be switched off in newer versions of Android, the NDK does not link against such libraries anymore [source](https://cs.android.com/android/platform/superproject/main/+/main:bionic/linker/linker_main.cpp;l=397?q=linker_main&ss=android%2Fplatform%2Fsuperproject%2Fmain). Alternative title could be Memory Anti-Exploitation Mechanisms Not Implemented. beta-coverage: [MASWE-0116] status: placeholder diff --git a/weaknesses/MASVS-CODE/MASWE-0075.md b/weaknesses/MASVS-CODE/MASWE-0075.md index d61e5ba..c87a34e 100644 --- a/weaknesses/MASVS-CODE/MASWE-0075.md +++ b/weaknesses/MASVS-CODE/MASWE-0075.md @@ -20,8 +20,8 @@ draft: unwanted content, or perform actions against the user's interest. Because the developer is responsible for all code shipped in the app (including third-party SDKs), the app must be reviewed and its supply chain controlled to detect and prevent inclusion of malicious code. - This complements [MASWE-0041](MASWE-0041.md) (dependencies with known vulnerabilities) and - [MASWE-0077](MASWE-0077.md) (non-reproducible builds). + This complements @MASWE-0041 (dependencies with known vulnerabilities) and + @MASWE-0077 (non-reproducible builds). topics: - intentionally introduced malicious code / insider threat - malicious or compromised third-party SDKs and dependencies (supply-chain) diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0011.md b/weaknesses/MASVS-CRYPTO/MASWE-0011.md index 913c2a2..4027b0b 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0011.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0011.md @@ -35,7 +35,7 @@ Improper encryption refers to cryptographic systems or implementations that are - **Broken Algorithms**: Relying on broken encryption algorithms (i.e., that are deprecated or disallowed by NIST or other standards) such as RC4. - **Predictable or Reused Initialization Vectors (IVs)**: Using IVs that are hardcoded, null, predictable, or reused in modes like AES-CBC or AES-CTR breaks semantic security, allowing attackers to detect patterns or recover plaintext differences. In AEAD modes like AES-GCM, reusing nonces or using authentication tags of insufficient length compromises both confidentiality and integrity. On Android, use `GCMParameterSpec` (not the legacy `IvParameterSpec`) for GCM. -- **Risky Padding**: Using a padding scheme susceptible to padding oracle attacks (e.g. PKCS#7 with unauthenticated AES-CBC, or PKCS#1 v1.5 for RSA) in combination with observable padding-error signals allows attackers to decrypt or forge ciphertext without the key. See [MASWE-0015](MASWE-0015.md) for signature verification and prefer authenticated encryption. +- **Risky Padding**: Using a padding scheme susceptible to padding oracle attacks (e.g. PKCS#7 with unauthenticated AES-CBC, or PKCS#1 v1.5 for RSA) in combination with observable padding-error signals allows attackers to decrypt or forge ciphertext without the key. See @MASWE-0015 for signature verification and prefer authenticated encryption. - **Broken Modes of Operation**: Using modes that are considered broken. For example, AES-ECB is broken due to practical known-plaintext attacks and it's disallowed by NIST. - **Insufficient Key Length**: The use of insufficient key sizes (e.g., 128-bit keys in AES) can compromise encryption strength making the encryption susceptible to brute-force attacks. - **Insecure or Wrong Key Usage**: Reusing a single key for multiple purposes (e.g. encryption and signing) or with an unauthorized algorithm violates key-separation principles. Per [NIST.SP.800-57pt1r5](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf), a single key should be used for only one purpose. diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0012.md b/weaknesses/MASVS-CRYPTO/MASWE-0012.md index a29784b..20473a3 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0012.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0012.md @@ -22,7 +22,7 @@ draft: are vulnerable to collision attacks and must not be used where collision or second-preimage resistance is required (e.g. digital signatures, integrity checks, certificate fingerprints). Note that password/passphrase handling requires a - dedicated password-based KDF rather than a plain hash (see [MASWE-0008](MASWE-0008.md)). + dedicated password-based KDF rather than a plain hash (see @MASWE-0008). topics: - broken hashing algorithms (e.g. MD5, SHA-1) - collision and second-preimage resistance requirements diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0013.md b/weaknesses/MASVS-CRYPTO/MASWE-0013.md index 660b341..a9adb54 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0013.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0013.md @@ -18,7 +18,16 @@ refs: - https://en.wikipedia.org/wiki/Replay_attack beta-coverage: [MASWE-0024, MASWE-0012] draft: - description: Improper use of MACs in security sensitive contexts affecting data integrity. + description: | + A Message Authentication Code (MAC) provides integrity and authenticity for a message using a + shared secret key. Improper use of a MAC in a security-sensitive context undermines these + guarantees and can let attackers forge or replay messages, or learn information through side + channels. Typical problems include using a MAC key for more than one purpose or with an + unauthorized algorithm, keys with insufficient entropy, MACs built on broken hash functions + (e.g. MD5/SHA-1), non-cryptographic checksums (e.g. CRC-32) used where a MAC is required, + fragile constructions (e.g. raw CBC-MAC on variable-length messages), truncated tags, missing + replay protection (timestamp/nonce), and incorrect MAC-then-encrypt / encrypt-then-MAC ordering + that leaks information via timing or error messages. topics: - Using a MAC key for more than one purpose or with an unauthorized algorithm (key separation) - Using HMAC with keys with insufficient entropy diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0032.md b/weaknesses/MASVS-PLATFORM/MASWE-0032.md index 66851f5..3b11c09 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0032.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0032.md @@ -10,14 +10,20 @@ mappings: cwe: [939, 917] draft: - description: e.g. use of URL Custom Schemes, unverified AppLinks/Universal Links, - not validating URLs. Deep Link parameters offers a wide range of possibilities. A malformed URI or parameter value, if not sanitized, may trigger an injection in different points of the application. For example, CWE-939 prevents the exploit of the URI checking the source and CWE-917 prevents the exploit of the URI checking the content. + description: | + Deep links (Android App Links and custom URL schemes, iOS Universal Links and custom schemes) let + other apps and websites launch the app at a specific screen and pass parameters. They become + insecure when the app relies on unverified custom URL schemes (which any app can claim), does not + verify App Links / Universal Links through domain association, or fails to validate and sanitize + the incoming URL and its parameters. Because deep-link input is attacker-controllable, a malformed + URI or parameter can trigger injection or logic abuse at various points in the app (CWE-939 for + source verification, CWE-917 for content/expression injection). topics: - - URL Custom Schemes - - AppLinks - - Universal Links - - URL validation - - Check for OS version. e.g. deep link are more secure after Android XX + - URL Custom Schemes (claimable by any app) + - Android App Links / iOS Universal Links domain association (autoVerify, apple-app-site-association) + - validating and sanitizing the deep-link URL and its parameters + - injection via unsanitized deep-link parameters (CWE-917 / CWE-939) + - platform/OS-version differences in deep-link security beta-coverage: [MASWE-0058] refs: - https://developer.apple.com/documentation/technotes/tn3155-debugging-universal-links diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0034.md b/weaknesses/MASVS-PLATFORM/MASWE-0034.md index 602ae9c..a40e3d0 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0034.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0034.md @@ -11,10 +11,18 @@ mappings: beta-coverage: [MASWE-0061] draft: - description: restricting use of certain extensions + description: | + On iOS, app extensions (e.g. custom keyboards, share and action extensions) run third-party code + that can interact with the host app and observe or exfiltrate the data the app hands to them. An + app that handles sensitive data should restrict which extension point identifiers it allows, for + example by implementing `application(_:shouldAllowExtensionPointIdentifier:)` to reject untrusted + extension categories, and by disabling third-party keyboards via the + `UIApplicationKeyboardExtensionPointIdentifier` for sensitive input fields. Allowing untrusted + extensions unconditionally can leak sensitive user input or content. topics: - - restricting use of certain extensions via `application:shouldAllowExtensionPointIdentifier:` - - Third-Party Keyboards Not Disabled via UIApplicationKeyboardExtensionPointIdentifier + - restricting extensions via application(_:shouldAllowExtensionPointIdentifier:) + - disabling third-party keyboards (UIApplicationKeyboardExtensionPointIdentifier) for sensitive fields + - risks of custom keyboard / share / action extensions handling sensitive data status: placeholder --- diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0049.md b/weaknesses/MASVS-RESILIENCE/MASWE-0049.md index 5530405..dfc966b 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0049.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0049.md @@ -13,7 +13,12 @@ refs: - https://grep.app/search?q=isdevicesecure%28&filter[repo][0]=threema-ch/threema-android - https://developer.android.com/reference/android/hardware/biometrics/BiometricManager#canAuthenticate(int) draft: - description: The app may not check for a secure device lock (e.g. device passcode) and may allow for unauthorized access to sensitive data. On iOS enforcing device lock security (i.e., ensuring a passcode is set) has an additional benefit which is that it is tightly coupled with data encryption, assuming the app leverages the correct data protection APIs. + description: | + Apps that protect sensitive data or operations should verify that the device has a secure lock + (passcode/PIN/pattern/biometric) configured before relying on it. If the app does not check for a + secure device lock, it may allow access to sensitive data on devices with no lock at all. On iOS, + enforcing that a passcode is set has the added benefit that it is tightly coupled with data + protection (file encryption), provided the app uses the correct data-protection APIs. topics: - user set a device passcode via `isDeviceSecure()` on Android better than only ensuring that the secure screen lock is set via `KeyguardManager.isKeyguardSecure()` - before attempting to authenticate, test to make sure that you actually have the ability to do so by calling the `LAContext.canEvaluatePolicy(_:error:)` method on iOS diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0052.md b/weaknesses/MASVS-RESILIENCE/MASWE-0052.md index ec39859..12e4bde 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0052.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0052.md @@ -11,11 +11,17 @@ mappings: beta-coverage: [MASWE-0090] draft: - description: e.g. resource obfuscation, binary encryption/packing + description: | + Beyond code, an app's resources and assets (e.g. strings, layouts, images, configuration, and + native binaries) can reveal how the app works and aid reverse engineering. This weakness occurs + when resources are left in clear, unobfuscated form and binaries are neither encrypted nor packed. + Note that obfuscation or encryption applied without integrity validation can itself be tampered + with (CWE-649), so resource protection should complement, not replace, integrity checks. topics: - - data/resource obfuscated/encrypted - - binaries encrypted/packed + - data/resources not obfuscated or encrypted + - native binaries not encrypted/packed - obfuscation/encryption used without integrity validation (CWE-649) + - resource/string identifier obfuscation status: placeholder --- diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0053.md b/weaknesses/MASVS-RESILIENCE/MASWE-0053.md index c99e9d5..b2e2269 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0053.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0053.md @@ -11,9 +11,17 @@ mappings: beta-coverage: [MASWE-0091] draft: - description: The app's code doesn’t implement effective anti-deobfuscation techniques to protect against reverse engineering (CWE-693) + description: | + Obfuscation alone can be undone by automated deobfuscation and static-analysis tooling. This + weakness occurs when the app does not implement anti-deobfuscation techniques that raise the cost + of reversing obfuscated code (CWE-693), such as anti-decompilation tricks, control-flow constructs + that defeat common deobfuscators, self-checks, and detection of tampering with the obfuscation. It + complements code obfuscation (@MASWE-0051) by protecting the obfuscation itself. topics: - - anti-deobfuscation techniques + - anti-deobfuscation / anti-decompilation techniques + - control-flow constructs resistant to automated deobfuscators + - detecting tampering with obfuscated code + - Effectiveness Assessment (e.g. attempting deobfuscation) status: placeholder --- diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0057.md b/weaknesses/MASVS-RESILIENCE/MASWE-0057.md index 05162da..59c0cea 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0057.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0057.md @@ -10,9 +10,17 @@ mappings: beta-coverage: [MASWE-0098] draft: - description: The app's code doesn’t implement effective techniques to detect if it is running in a virtualized environment (CWE-693), e.g. checking for known virtualization software or anomalies in the environment. + description: | + App virtualization/cloning frameworks (and "dual-app" containers) run an app inside another app's + process, letting an attacker instrument it, access its data, or run multiple cloned instances + without rooting the device. This weakness occurs when the app does not detect that it is running + inside such a virtualized or cloned environment (CWE-693), for example by checking its process path + and package structure for anomalies or looking for known virtualization frameworks, and does not + respond when one is detected. topics: - - detection in place for "cloned" apps or virtualized environments + - detection of cloned apps / virtualized (dual-app) environments + - checks for known virtualization frameworks and process/path anomalies + - responding to a detected virtualized environment - Effectiveness Assessment (e.g. bypassing the detection) status: placeholder diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0059.md b/weaknesses/MASVS-RESILIENCE/MASWE-0059.md index a4a943d..91df9bd 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0059.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0059.md @@ -21,9 +21,18 @@ refs: - https://blog.restlesslabs.com/john/ios-app-attest beta-coverage: [MASWE-0100] draft: - description: The app doesn't use App Attestation APIs, such as Google Play Integrity API, iOS DeviceCheck API,so the backend cannot ensure requests originate from a genuine app binary (CWE-693). This exposes the app to tampering, fraud, replay attacks, and unauthorized use of premium features. + description: | + Device attestation lets the backend gain assurance about the integrity of the device and platform + the app runs on, using platform services such as the Android Play Integrity API or iOS + DeviceCheck / App Attest. This weakness occurs when the app does not implement device attestation, + so the backend cannot distinguish requests from genuine, uncompromised devices from those coming + from rooted, emulated, tampered, or automated environments (CWE-693), exposing it to tampering, + fraud, replay attacks, and abuse of premium features. Attestation results must be verified + server-side (including nonce/freshness) to be meaningful. topics: - - detection in place + - Android Play Integrity API / iOS DeviceCheck & App Attest + - server-side verification of attestation results (nonce, freshness) + - detecting rooted/emulated/tampered environments via attestation - Effectiveness Assessment (e.g. bypassing the detection) status: placeholder diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0060.md b/weaknesses/MASVS-RESILIENCE/MASWE-0060.md index 81b283e..5a54259 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0060.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0060.md @@ -11,9 +11,16 @@ mappings: beta-coverage: [MASWE-0101] draft: - description: The app's code doesn’t implement effective techniques to detect if it is being debugged (CWE-693), e.g. checking for debugger presence. + description: | + A debugger attached to the running app lets an attacker inspect memory, set breakpoints, and alter + control flow to bypass client-side controls. This weakness occurs when the app does not detect the + presence of a debugger at runtime (CWE-693), for example via platform checks + (`Debug.isDebuggerConnected()` and the `TracerPid` in `/proc/self/status` on Android, or + `sysctl`/`ptrace`-based checks on iOS), and does not respond appropriately when one is detected. topics: - - debugger detection + - debugger presence detection (Android Debug.isDebuggerConnected() / TracerPid; iOS sysctl/ptrace) + - responding to a detected debugger + - Effectiveness Assessment (e.g. bypassing the detection) status: placeholder --- diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0061.md b/weaknesses/MASVS-RESILIENCE/MASWE-0061.md index ac611a9..5474691 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0061.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0061.md @@ -11,11 +11,18 @@ mappings: beta-coverage: [MASWE-0102] draft: - description: The app's code doesn’t implement effective techniques to detect if it is being analyzed by dynamic analysis tools (CWE-693), e.g. Frida, Xposed, Ellekit, etc. + description: | + Dynamic instrumentation and hooking frameworks let an attacker observe and modify the app at + runtime, bypassing client-side security controls. This weakness occurs when the app does not detect + the presence of such tools (CWE-693), e.g. Frida, Xposed/LSPosed, and ElleKit/Cydia Substrate, by + checking for their artifacts (loaded libraries, named pipes, listening ports, installed hooks), and + does not respond when they are detected. topics: - Frida detection - - Xposed detection - - ElleKit detection + - Xposed / LSPosed detection + - ElleKit / Cydia Substrate detection + - detecting hooking artifacts (loaded libraries, ports, named pipes) + - Effectiveness Assessment (e.g. bypassing the detection) status: placeholder --- diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0063.md b/weaknesses/MASVS-RESILIENCE/MASWE-0063.md index 7809a57..b76e5b3 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0063.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0063.md @@ -11,11 +11,17 @@ mappings: beta-coverage: [MASWE-0105] draft: - description: The app's code doesn’t implement effective techniques to verify the integrity of its own resources (CWE-693). + description: | + Beyond executable code, an app relies on resources and assets whose integrity should be verified, + including files in the app sandbox, downloaded resources, and dynamically loaded resources (e.g. + those restored from a backup). This weakness occurs when the app does not verify that these + resources have not been tampered with (CWE-693), allowing an attacker to change app behavior or + inject malicious content by altering resources. topics: - - Sandbox Integrity - - Integrity of downloaded resources - - Integrity of dynamically loaded resources (e.g. via backup restore) + - sandbox / app-resource integrity verification + - integrity of downloaded resources + - integrity of dynamically loaded resources (e.g. via backup restore) + - responding to failed resource-integrity checks status: placeholder --- diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0064.md b/weaknesses/MASVS-RESILIENCE/MASWE-0064.md index a96dece..27308fe 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0064.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0064.md @@ -11,10 +11,17 @@ mappings: beta-coverage: [MASWE-0107] draft: - description: The app's code doesn’t implement effective techniques to verify the integrity of its own code at runtime (CWE-693), e.g. detecting in-memory code/patch tampering or code injection. - topics: - - memory tampering detection - - runtime code/patch integrity checks + description: | + An app's executable code can be modified at runtime through in-memory patching, code injection, or + hooking. This weakness occurs when the app does not verify the integrity of its own code at runtime + (CWE-693), for example by detecting modifications to loaded code/segments, injected libraries, or + patched functions, and does not respond when tampering is detected. It complements static app + integrity/attestation (@MASWE-0062) by covering runtime tampering. + topics: + - in-memory code / patch tampering detection + - detecting injected libraries and function hooks + - runtime code/segment integrity checks + - Effectiveness Assessment (e.g. bypassing the detection) status: placeholder --- diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0076.md b/weaknesses/MASVS-RESILIENCE/MASWE-0076.md index e53c8cb..9354e51 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0076.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0076.md @@ -19,7 +19,7 @@ draft: environment). For high-assurance apps, detecting a potentially hostile environment allows the app to warn the user, restrict functionality, or trigger other protective responses. This complements environment-integrity checks such as - [MASWE-0056](MASWE-0056.md) (root/jailbreak detection) and platform services such as Google + @MASWE-0056 (root/jailbreak detection) and platform services such as Google Play Protect / the Play Integrity API. topics: - detecting known malicious apps/packages on the device diff --git a/weaknesses/MASVS-STORAGE/MASWE-0006.md b/weaknesses/MASVS-STORAGE/MASWE-0006.md index 440ec0a..1e21c64 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0006.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0006.md @@ -26,10 +26,10 @@ This weakness covers any sensitive data that is hardcoded and shipped with the a - **API keys and secrets** for first- or third-party services. - **Credentials** such as passwords, session tokens, or other authentication material. -- **Cryptographic material** such as symmetric keys or private keys embedded directly in the package (as opposed to being generated and stored in a platform keystore, see [MASWE-0005](MASWE-0005.md)). +- **Cryptographic material** such as symmetric keys or private keys embedded directly in the package (as opposed to being generated and stored in a platform keystore, see @MASWE-0005). - **Developer leftover artifacts**, such as staging or integration URLs, developer emails and usernames, and source code files left in the package (e.g. `.swift`, `.cpp`, map files, or other build artifacts) that leak internal information. -Note that developer _debug_ artifacts (verbose logging, backdoors, testing utilities, hidden switches) are covered separately under resilience in [MASWE-0054](../MASVS-RESILIENCE/MASWE-0054.md). The focus here is on hardcoded sensitive data that leaks confidentiality regardless of any anti-tampering considerations. +Note that developer _debug_ artifacts (verbose logging, backdoors, testing utilities, hidden switches) are covered separately under resilience in @MASWE-0054. The focus here is on hardcoded sensitive data that leaks confidentiality regardless of any anti-tampering considerations. ## Impact @@ -53,6 +53,6 @@ Sensitive data can be hardcoded in several places that end up in the final packa - If a stateful API service is not viable, use a stateless API service fronted by a middleware solution (API proxy or gateway) that proxies requests between the app and the API endpoint, keeping the static secret server-side rather than in the client. Use JSON Web Tokens (JWT) and JSON Web Signature (JWS) as appropriate. - If secrets must be hardcoded, configure them with the minimum required permissions and restrictions to reduce the impact in case of exposure. - Consider using a [Key Management Service](https://cloud.google.com/kms/docs/key-management-service) to retrieve secrets at runtime after validating app integrity. -- Store cryptographic keys and authentication material using the platform's hardware-backed keystore (Android Keystore, iOS Keychain) instead of embedding them in the package. See [MASWE-0005](MASWE-0005.md). +- Store cryptographic keys and authentication material using the platform's hardware-backed keystore (Android Keystore, iOS Keychain) instead of embedding them in the package. See @MASWE-0005. - Regularly audit the codebase and dependencies for hardcoded sensitive data and developer leftovers (e.g. using tools such as [gitleaks](https://github.com/gitleaks/gitleaks)) and strip build artifacts and source files from release packages. - As a **last resort** when no other secure option is available, white-box cryptography, code/resource obfuscation, and RASP can raise the effort required to extract secrets, ensuring keys are only assembled in memory when needed. These techniques deter but do not prevent extraction and must not replace the mitigations above. From 8797164ae181fd24322e34454bd6cdbf9abb674b Mon Sep 17 00:00:00 2001 From: Carlos Holguera Date: Sun, 19 Jul 2026 10:54:32 +0200 Subject: [PATCH 04/70] Add requirements --- weaknesses/MASVS-AUTH/MASWE-0017.md | 1 + weaknesses/MASVS-AUTH/MASWE-0018.md | 1 + weaknesses/MASVS-AUTH/MASWE-0019.md | 1 + weaknesses/MASVS-AUTH/MASWE-0020.md | 1 + weaknesses/MASVS-AUTH/MASWE-0021.md | 1 + weaknesses/MASVS-AUTH/MASWE-0022.md | 1 + weaknesses/MASVS-AUTH/MASWE-0023.md | 1 + weaknesses/MASVS-AUTH/MASWE-0024.md | 1 + weaknesses/MASVS-CODE/MASWE-0040.md | 1 + weaknesses/MASVS-CODE/MASWE-0041.md | 1 + weaknesses/MASVS-CODE/MASWE-0042.md | 1 + weaknesses/MASVS-CODE/MASWE-0043.md | 1 + weaknesses/MASVS-CODE/MASWE-0044.md | 1 + weaknesses/MASVS-CODE/MASWE-0045.md | 1 + weaknesses/MASVS-CODE/MASWE-0046.md | 1 + weaknesses/MASVS-CODE/MASWE-0047.md | 1 + weaknesses/MASVS-CODE/MASWE-0048.md | 1 + weaknesses/MASVS-CODE/MASWE-0075.md | 1 + weaknesses/MASVS-CODE/MASWE-0077.md | 1 + weaknesses/MASVS-CRYPTO/MASWE-0007.md | 1 + weaknesses/MASVS-CRYPTO/MASWE-0008.md | 1 + weaknesses/MASVS-CRYPTO/MASWE-0009.md | 1 + weaknesses/MASVS-CRYPTO/MASWE-0010.md | 1 + weaknesses/MASVS-CRYPTO/MASWE-0011.md | 1 + weaknesses/MASVS-CRYPTO/MASWE-0012.md | 1 + weaknesses/MASVS-CRYPTO/MASWE-0013.md | 1 + weaknesses/MASVS-CRYPTO/MASWE-0014.md | 1 + weaknesses/MASVS-CRYPTO/MASWE-0015.md | 1 + weaknesses/MASVS-CRYPTO/MASWE-0016.md | 1 + weaknesses/MASVS-NETWORK/MASWE-0025.md | 1 + weaknesses/MASVS-NETWORK/MASWE-0026.md | 1 + weaknesses/MASVS-NETWORK/MASWE-0027.md | 1 + weaknesses/MASVS-PLATFORM/MASWE-0028.md | 1 + weaknesses/MASVS-PLATFORM/MASWE-0029.md | 1 + weaknesses/MASVS-PLATFORM/MASWE-0030.md | 1 + weaknesses/MASVS-PLATFORM/MASWE-0031.md | 1 + weaknesses/MASVS-PLATFORM/MASWE-0032.md | 1 + weaknesses/MASVS-PLATFORM/MASWE-0033.md | 1 + weaknesses/MASVS-PLATFORM/MASWE-0034.md | 1 + weaknesses/MASVS-PLATFORM/MASWE-0035.md | 1 + weaknesses/MASVS-PLATFORM/MASWE-0036.md | 1 + weaknesses/MASVS-PLATFORM/MASWE-0037.md | 1 + weaknesses/MASVS-PLATFORM/MASWE-0038.md | 1 + weaknesses/MASVS-PLATFORM/MASWE-0039.md | 1 + weaknesses/MASVS-PRIVACY/MASWE-0065.md | 1 + weaknesses/MASVS-PRIVACY/MASWE-0066.md | 1 + weaknesses/MASVS-PRIVACY/MASWE-0067.md | 1 + weaknesses/MASVS-PRIVACY/MASWE-0068.md | 1 + weaknesses/MASVS-PRIVACY/MASWE-0069.md | 1 + weaknesses/MASVS-PRIVACY/MASWE-0070.md | 1 + weaknesses/MASVS-PRIVACY/MASWE-0071.md | 1 + weaknesses/MASVS-PRIVACY/MASWE-0072.md | 1 + weaknesses/MASVS-PRIVACY/MASWE-0073.md | 1 + weaknesses/MASVS-PRIVACY/MASWE-0074.md | 1 + weaknesses/MASVS-RESILIENCE/MASWE-0049.md | 1 + weaknesses/MASVS-RESILIENCE/MASWE-0050.md | 1 + weaknesses/MASVS-RESILIENCE/MASWE-0051.md | 1 + weaknesses/MASVS-RESILIENCE/MASWE-0052.md | 1 + weaknesses/MASVS-RESILIENCE/MASWE-0053.md | 1 + weaknesses/MASVS-RESILIENCE/MASWE-0054.md | 1 + weaknesses/MASVS-RESILIENCE/MASWE-0055.md | 1 + weaknesses/MASVS-RESILIENCE/MASWE-0056.md | 1 + weaknesses/MASVS-RESILIENCE/MASWE-0057.md | 1 + weaknesses/MASVS-RESILIENCE/MASWE-0058.md | 1 + weaknesses/MASVS-RESILIENCE/MASWE-0059.md | 1 + weaknesses/MASVS-RESILIENCE/MASWE-0060.md | 1 + weaknesses/MASVS-RESILIENCE/MASWE-0061.md | 1 + weaknesses/MASVS-RESILIENCE/MASWE-0062.md | 1 + weaknesses/MASVS-RESILIENCE/MASWE-0063.md | 1 + weaknesses/MASVS-RESILIENCE/MASWE-0064.md | 1 + weaknesses/MASVS-RESILIENCE/MASWE-0076.md | 1 + weaknesses/MASVS-STORAGE/MASWE-0001.md | 1 + weaknesses/MASVS-STORAGE/MASWE-0002.md | 1 + weaknesses/MASVS-STORAGE/MASWE-0003.md | 1 + weaknesses/MASVS-STORAGE/MASWE-0004.md | 1 + weaknesses/MASVS-STORAGE/MASWE-0005.md | 1 + weaknesses/MASVS-STORAGE/MASWE-0006.md | 1 + 77 files changed, 77 insertions(+) diff --git a/weaknesses/MASVS-AUTH/MASWE-0017.md b/weaknesses/MASVS-AUTH/MASWE-0017.md index e493f50..36a770d 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0017.md +++ b/weaknesses/MASVS-AUTH/MASWE-0017.md @@ -2,6 +2,7 @@ title: Step-Up Authentication Not Implemented for Sensitive Actions id: MASWE-0017 alias: step-up-auth +requirement: "The app enforces step-up authentication before granting access to sensitive functionality." platform: [android, ios] profiles: [L2] mappings: diff --git a/weaknesses/MASVS-AUTH/MASWE-0018.md b/weaknesses/MASVS-AUTH/MASWE-0018.md index a1680a0..1aeaa30 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0018.md +++ b/weaknesses/MASVS-AUTH/MASWE-0018.md @@ -2,6 +2,7 @@ title: Sensitive Data Accessible After Session Termination id: MASWE-0018 alias: reauth-state-changes +requirement: "The app makes sensitive data inaccessible after session termination." platform: [android, ios] profiles: [L2] mappings: diff --git a/weaknesses/MASVS-AUTH/MASWE-0019.md b/weaknesses/MASVS-AUTH/MASWE-0019.md index 92f09d8..750cccb 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0019.md +++ b/weaknesses/MASVS-AUTH/MASWE-0019.md @@ -2,6 +2,7 @@ title: Lack of Non-Repudiation for Critical Actions id: MASWE-0019 alias: insecure-android-confirmation +requirement: "The app ensures non-repudiation for critical actions." platform: [android, ios] profiles: [L2] mappings: diff --git a/weaknesses/MASVS-AUTH/MASWE-0020.md b/weaknesses/MASVS-AUTH/MASWE-0020.md index 8c7eb8d..f72be35 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0020.md +++ b/weaknesses/MASVS-AUTH/MASWE-0020.md @@ -2,6 +2,7 @@ title: Lack of Authentication or Authorization on App Components id: MASWE-0020 alias: missing-auth-app-components +requirement: "The app enforces authentication and authorization on its components." platform: [android, ios] profiles: [L1, L2] mappings: diff --git a/weaknesses/MASVS-AUTH/MASWE-0021.md b/weaknesses/MASVS-AUTH/MASWE-0021.md index 187e131..55c9dfc 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0021.md +++ b/weaknesses/MASVS-AUTH/MASWE-0021.md @@ -2,6 +2,7 @@ title: Local Authentication Can Be Bypassed id: MASWE-0021 alias: event-bound-biometric-auth +requirement: "The app implements local authentication securely." platform: [android, ios] profiles: [L2] mappings: diff --git a/weaknesses/MASVS-AUTH/MASWE-0022.md b/weaknesses/MASVS-AUTH/MASWE-0022.md index 87b667d..b5afd78 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0022.md +++ b/weaknesses/MASVS-AUTH/MASWE-0022.md @@ -2,6 +2,7 @@ title: Fallback to Non-biometric Credentials Allowed for Sensitive Transactions id: MASWE-0022 alias: no-biometric-fallback +requirement: "The app does not allow fallback to non-biometric credentials for sensitive transactions." platform: [android, ios] profiles: [L2] mappings: diff --git a/weaknesses/MASVS-AUTH/MASWE-0023.md b/weaknesses/MASVS-AUTH/MASWE-0023.md index 2caac26..75aec99 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0023.md +++ b/weaknesses/MASVS-AUTH/MASWE-0023.md @@ -2,6 +2,7 @@ title: Crypto Keys Not Invalidated on New Biometric Enrollment id: MASWE-0023 alias: crypto-keys-biometric-enrollment +requirement: "The app invalidates keys after any enrollment of new biometric data." platform: [android, ios] profiles: [L2] mappings: diff --git a/weaknesses/MASVS-AUTH/MASWE-0024.md b/weaknesses/MASVS-AUTH/MASWE-0024.md index a3e7325..3849e27 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0024.md +++ b/weaknesses/MASVS-AUTH/MASWE-0024.md @@ -2,6 +2,7 @@ title: Lack of Auto-fill Support for Authenticators id: MASWE-0024 alias: autofill-authenticators +requirement: "The app enables auto-fill support for authenticators." platform: [android, ios] profiles: [L2] mappings: diff --git a/weaknesses/MASVS-CODE/MASWE-0040.md b/weaknesses/MASVS-CODE/MASWE-0040.md index 98ba912..3ad4b33 100644 --- a/weaknesses/MASVS-CODE/MASWE-0040.md +++ b/weaknesses/MASVS-CODE/MASWE-0040.md @@ -2,6 +2,7 @@ title: Enforced Updating Not Implemented id: MASWE-0040 alias: enforced-updating +requirement: "The app terminates if an outdated app version is detected." platform: [android, ios] profiles: [L2] mappings: diff --git a/weaknesses/MASVS-CODE/MASWE-0041.md b/weaknesses/MASVS-CODE/MASWE-0041.md index 6f62f8b..abab90c 100644 --- a/weaknesses/MASVS-CODE/MASWE-0041.md +++ b/weaknesses/MASVS-CODE/MASWE-0041.md @@ -2,6 +2,7 @@ title: Dependencies with Known Vulnerabilities id: MASWE-0041 alias: dependencies-with-known-vulnerabilities +requirement: "The app's third-party components are regularly checked for known vulnerabilities." platform: [android, ios] profiles: [L1, L2] mappings: diff --git a/weaknesses/MASVS-CODE/MASWE-0042.md b/weaknesses/MASVS-CODE/MASWE-0042.md index 5a66153..0391b18 100644 --- a/weaknesses/MASVS-CODE/MASWE-0042.md +++ b/weaknesses/MASVS-CODE/MASWE-0042.md @@ -2,6 +2,7 @@ title: Running on a recent Platform Version Not Ensured id: MASWE-0042 alias: run-on-recent-platform-version +requirement: "The app terminates if an unsupported OS version is detected." platform: [android, ios] profiles: [L2] mappings: diff --git a/weaknesses/MASVS-CODE/MASWE-0043.md b/weaknesses/MASVS-CODE/MASWE-0043.md index 4c47ada..6e234ea 100644 --- a/weaknesses/MASVS-CODE/MASWE-0043.md +++ b/weaknesses/MASVS-CODE/MASWE-0043.md @@ -2,6 +2,7 @@ title: Latest Platform Version Not Targeted id: MASWE-0043 alias: target-latest-platform-version +requirement: "The app targets a recent OS version." platform: [android, ios] profiles: [L2] mappings: diff --git a/weaknesses/MASVS-CODE/MASWE-0044.md b/weaknesses/MASVS-CODE/MASWE-0044.md index 1dd6959..0320002 100644 --- a/weaknesses/MASVS-CODE/MASWE-0044.md +++ b/weaknesses/MASVS-CODE/MASWE-0044.md @@ -2,6 +2,7 @@ title: Unsafe Dynamic Code Loading id: MASWE-0044 alias: unsafe-code-loading +requirement: "The app loads dynamic code safely from trusted sources." platform: [android, ios] profiles: [L2] mappings: diff --git a/weaknesses/MASVS-CODE/MASWE-0045.md b/weaknesses/MASVS-CODE/MASWE-0045.md index 9b441c1..3a6b211 100644 --- a/weaknesses/MASVS-CODE/MASWE-0045.md +++ b/weaknesses/MASVS-CODE/MASWE-0045.md @@ -2,6 +2,7 @@ title: Compiler-Provided Security Features Not Used id: MASWE-0045 alias: compiler-provided-security-features-not-implemented +requirement: "The app uses the compiler-provided security features of the platform." platform: [android, ios] profiles: [L2] mappings: diff --git a/weaknesses/MASVS-CODE/MASWE-0046.md b/weaknesses/MASVS-CODE/MASWE-0046.md index 766892d..7905a77 100644 --- a/weaknesses/MASVS-CODE/MASWE-0046.md +++ b/weaknesses/MASVS-CODE/MASWE-0046.md @@ -2,6 +2,7 @@ title: Use of Deprecated APIs or Functionality id: MASWE-0046 alias: deprecated-apis +requirement: "The app does not use deprecated APIs or functionality." platform: [android, ios] profiles: [L2] mappings: diff --git a/weaknesses/MASVS-CODE/MASWE-0047.md b/weaknesses/MASVS-CODE/MASWE-0047.md index 0f170d1..3ea1ed7 100644 --- a/weaknesses/MASVS-CODE/MASWE-0047.md +++ b/weaknesses/MASVS-CODE/MASWE-0047.md @@ -2,6 +2,7 @@ title: Using Non-Standard Libraries for Security-Critical Functionality id: MASWE-0047 alias: non-standard-security-libs +requirement: "The app does not use non-standard libraries for security-critical functionality." platform: [android, ios] profiles: [L2] mappings: diff --git a/weaknesses/MASVS-CODE/MASWE-0048.md b/weaknesses/MASVS-CODE/MASWE-0048.md index 179e593..06311c6 100644 --- a/weaknesses/MASVS-CODE/MASWE-0048.md +++ b/weaknesses/MASVS-CODE/MASWE-0048.md @@ -2,6 +2,7 @@ title: Unsafe Handling of Untrusted Data id: MASWE-0048 alias: unsafe-untrusted-data +requirement: "The app securely handles untrusted data." platform: [android, ios] profiles: [L1, L2] mappings: diff --git a/weaknesses/MASVS-CODE/MASWE-0075.md b/weaknesses/MASVS-CODE/MASWE-0075.md index c87a34e..fe8149a 100644 --- a/weaknesses/MASVS-CODE/MASWE-0075.md +++ b/weaknesses/MASVS-CODE/MASWE-0075.md @@ -2,6 +2,7 @@ title: Malicious Code Included in the App id: MASWE-0075 alias: malicious-code-included +requirement: "The app package does not contain malicious code." platform: [android, ios] profiles: [L2] mappings: diff --git a/weaknesses/MASVS-CODE/MASWE-0077.md b/weaknesses/MASVS-CODE/MASWE-0077.md index e786626..6c8bb62 100644 --- a/weaknesses/MASVS-CODE/MASWE-0077.md +++ b/weaknesses/MASVS-CODE/MASWE-0077.md @@ -2,6 +2,7 @@ title: Non-Reproducible Builds id: MASWE-0077 alias: non-reproducible-builds +requirement: "The app offers reproducible builds." platform: [android, ios] profiles: [L2] mappings: diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0007.md b/weaknesses/MASVS-CRYPTO/MASWE-0007.md index 763f983..f6d1434 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0007.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0007.md @@ -2,6 +2,7 @@ title: Improper Cryptographic Key Generation id: MASWE-0007 alias: weak-crypto-key-generation +requirement: "The app securely generates cryptographic keys." platform: [android, ios] profiles: [L1, L2] mappings: diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0008.md b/weaknesses/MASVS-CRYPTO/MASWE-0008.md index 6b2b723..9d5b3b8 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0008.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0008.md @@ -2,6 +2,7 @@ title: Improper Cryptographic Key Derivation id: MASWE-0008 alias: weak-crypto-key-derivation +requirement: "The app derives cryptographic keys using approved key derivation functions." platform: [android, ios] profiles: [L1, L2] mappings: diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0009.md b/weaknesses/MASVS-CRYPTO/MASWE-0009.md index e3231bd..3eb782b 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0009.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0009.md @@ -2,6 +2,7 @@ title: Cryptographic Key Rotation Not Implemented id: MASWE-0009 alias: no-key-rotation +requirement: "The app rotates cryptographic keys regularly." platform: [android, ios] profiles: [L2] mappings: diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0010.md b/weaknesses/MASVS-CRYPTO/MASWE-0010.md index c042caa..87ec72c 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0010.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0010.md @@ -2,6 +2,7 @@ title: Cryptographic Key Access Not Restricted id: MASWE-0010 alias: crypto-key-access-not-restricted +requirement: "The app restricts access to cryptographic keys." platform: [android, ios] profiles: [L2] mappings: diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0011.md b/weaknesses/MASVS-CRYPTO/MASWE-0011.md index 4027b0b..e46d91a 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0011.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0011.md @@ -2,6 +2,7 @@ title: Improper Encryption id: MASWE-0011 alias: weak-encryption +requirement: "The app properly encrypts sensitive data." platform: [android, ios] profiles: [L1, L2] mappings: diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0012.md b/weaknesses/MASVS-CRYPTO/MASWE-0012.md index 20473a3..9425689 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0012.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0012.md @@ -2,6 +2,7 @@ title: Improper Hashing id: MASWE-0012 alias: improper-hashing +requirement: "The app properly hashes sensitive data." platform: [android, ios] profiles: [L1, L2] mappings: diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0013.md b/weaknesses/MASVS-CRYPTO/MASWE-0013.md index a9adb54..373306d 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0013.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0013.md @@ -2,6 +2,7 @@ title: Improper Use of Message Authentication Code (MAC) id: MASWE-0013 alias: improper-mac +requirement: "The app properly uses Message Authentication Codes (MACs)." platform: [android, ios] profiles: [L1, L2] mappings: diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0014.md b/weaknesses/MASVS-CRYPTO/MASWE-0014.md index cdd9c53..1fc49a0 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0014.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0014.md @@ -2,6 +2,7 @@ title: Improper Generation of Cryptographic Signatures id: MASWE-0014 alias: improper-signature-generation +requirement: "The app properly generates cryptographic signatures." platform: [android, ios] profiles: [L1, L2] mappings: diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0015.md b/weaknesses/MASVS-CRYPTO/MASWE-0015.md index 4c5fe52..faab32b 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0015.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0015.md @@ -2,6 +2,7 @@ title: Improper Verification of Cryptographic Signature id: MASWE-0015 alias: improper-signature-verification +requirement: "The app properly verifies cryptographic signatures." platform: [android, ios] profiles: [L1, L2] mappings: diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0016.md b/weaknesses/MASVS-CRYPTO/MASWE-0016.md index c5f9a1a..26f42f1 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0016.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0016.md @@ -2,6 +2,7 @@ title: Improper Random Number Generation id: MASWE-0016 alias: improper-random-number-generation +requirement: "The app properly generates random numbers." platform: ["android", "ios"] profiles: ["L1", "L2"] mappings: diff --git a/weaknesses/MASVS-NETWORK/MASWE-0025.md b/weaknesses/MASVS-NETWORK/MASWE-0025.md index e47a914..0c1f5c6 100644 --- a/weaknesses/MASVS-NETWORK/MASWE-0025.md +++ b/weaknesses/MASVS-NETWORK/MASWE-0025.md @@ -2,6 +2,7 @@ title: Network Traffic Not Encrypted id: MASWE-0025 alias: cleartext-traffic +requirement: "The app encrypts all network traffic." platform: [android, ios] profiles: [L1, L2] mappings: diff --git a/weaknesses/MASVS-NETWORK/MASWE-0026.md b/weaknesses/MASVS-NETWORK/MASWE-0026.md index 1dc48e8..d458811 100644 --- a/weaknesses/MASVS-NETWORK/MASWE-0026.md +++ b/weaknesses/MASVS-NETWORK/MASWE-0026.md @@ -2,6 +2,7 @@ title: Insecure Certificate Validation id: MASWE-0026 alias: insecure-cert-val +requirement: "The app validates certificates for all network traffic." platform: [android, ios] profiles: [L1, L2] mappings: diff --git a/weaknesses/MASVS-NETWORK/MASWE-0027.md b/weaknesses/MASVS-NETWORK/MASWE-0027.md index 80898a2..c9ad7ca 100644 --- a/weaknesses/MASVS-NETWORK/MASWE-0027.md +++ b/weaknesses/MASVS-NETWORK/MASWE-0027.md @@ -2,6 +2,7 @@ title: Insecure Identity Pinning id: MASWE-0027 alias: insecure-pinning +requirement: "The app correctly implements identity pinning." platform: [android, ios] profiles: [L2] mappings: diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0028.md b/weaknesses/MASVS-PLATFORM/MASWE-0028.md index 0a30889..5826927 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0028.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0028.md @@ -2,6 +2,7 @@ title: Sensitive Data Exposed via the User Interface id: MASWE-0028 alias: data-leak-ui +requirement: "The app does not unnecessarily expose sensitive data through the app user interface." platform: [android, ios] profiles: [L2] mappings: diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0029.md b/weaknesses/MASVS-PLATFORM/MASWE-0029.md index 5f2b784..7917682 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0029.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0029.md @@ -2,6 +2,7 @@ title: Sensitive Data Leaked via Notifications id: MASWE-0029 alias: data-leak-notifications +requirement: "The app does not unnecessarily expose sensitive data through system notifications." platform: [android, ios] profiles: [L2] mappings: diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0030.md b/weaknesses/MASVS-PLATFORM/MASWE-0030.md index a658550..88cbd4e 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0030.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0030.md @@ -2,6 +2,7 @@ title: Sensitive Data Leaked via Screenshots or Screen Recordings id: MASWE-0030 alias: data-leak-screenshots +requirement: "The app removes sensitive data from views when moved to the background or when being recorded." platform: [android, ios] profiles: [L2] mappings: diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0031.md b/weaknesses/MASVS-PLATFORM/MASWE-0031.md index 37d69ed..8756acd 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0031.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0031.md @@ -2,6 +2,7 @@ title: App Vulnerable to Overlay Attacks id: MASWE-0031 alias: tapjacking-attacks +requirement: "The app protects its sensitive screens against overlay attacks." platform: [android, ios] profiles: [L2] mappings: diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0032.md b/weaknesses/MASVS-PLATFORM/MASWE-0032.md index 3b11c09..afb1481 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0032.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0032.md @@ -2,6 +2,7 @@ title: Insecure Deep Links id: MASWE-0032 alias: insecure-deep-links +requirement: "The app securely handles deep links." platform: [android, ios] profiles: [L1, L2] mappings: diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0033.md b/weaknesses/MASVS-PLATFORM/MASWE-0033.md index 64f9e25..cc596cc 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0033.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0033.md @@ -2,6 +2,7 @@ title: Improper Use of the Clipboard id: MASWE-0033 alias: improper-clipboard +requirement: "The app avoids placing sensitive data on the system clipboard." platform: [android, ios] profiles: [L1, L2] mappings: diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0034.md b/weaknesses/MASVS-PLATFORM/MASWE-0034.md index a40e3d0..c807a5a 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0034.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0034.md @@ -2,6 +2,7 @@ title: Allowing Untrusted App Extensions id: MASWE-0034 alias: insecure-app-extensions +requirement: "The app only permits trusted app extensions to interact with it." platform: [ios] profiles: [L1, L2] mappings: diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0035.md b/weaknesses/MASVS-PLATFORM/MASWE-0035.md index ab6926f..766dddb 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0035.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0035.md @@ -2,6 +2,7 @@ title: Insecure Intents id: MASWE-0035 alias: insecure-intents +requirement: "The app securely handles intents." platform: [android] profiles: [L1, L2] mappings: diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0036.md b/weaknesses/MASVS-PLATFORM/MASWE-0036.md index 8fe0def..a3bbe0a 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0036.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0036.md @@ -2,6 +2,7 @@ title: Sensitive Functionality Exposed in WebViews id: MASWE-0036 alias: js-bridges-webviews +requirement: "The app does not expose sensitive native functionality to WebView content." platform: [android, ios] profiles: [L1, L2] mappings: diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0037.md b/weaknesses/MASVS-PLATFORM/MASWE-0037.md index 13f8692..7e9629d 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0037.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0037.md @@ -2,6 +2,7 @@ title: WebViews Allow Access to Local Resources with Untrusted Content id: MASWE-0037 alias: webviews-local-resources +requirement: "The app does not allow WebViews loading untrusted content to access local resources." platform: [android, ios] profiles: [L1, L2] mappings: diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0038.md b/weaknesses/MASVS-PLATFORM/MASWE-0038.md index 163e5a3..cfea171 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0038.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0038.md @@ -2,6 +2,7 @@ title: WebViews Loading Untrusted Content id: MASWE-0038 alias: webviews-untrusted-content +requirement: "The app does not allow WebViews to load untrusted content." platform: [android, ios] profiles: [L1, L2] mappings: diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0039.md b/weaknesses/MASVS-PLATFORM/MASWE-0039.md index 4012bff..d3709cb 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0039.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0039.md @@ -2,6 +2,7 @@ title: Sensitive Data Leaked via Accessibility Services id: MASWE-0039 alias: data-leak-accessibility +requirement: "The app prevents sensitive data from being exposed to, or captured by, accessibility services." platform: [android, ios] profiles: [L2] mappings: diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0065.md b/weaknesses/MASVS-PRIVACY/MASWE-0065.md index cfdc1d1..85e7b92 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0065.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0065.md @@ -2,6 +2,7 @@ title: Lack of Anonymization or Pseudonymisation Measures id: MASWE-0065 alias: anonymization-pseudonymization-measures +requirement: "The app uses anonymization or pseudonymisation measures." platform: ["android", "ios"] profiles: ["P"] mappings: diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0066.md b/weaknesses/MASVS-PRIVACY/MASWE-0066.md index fd0d0ed..f0a6c0c 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0066.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0066.md @@ -2,6 +2,7 @@ title: Incorrect Use of Identifiers for User Tracking id: MASWE-0066 alias: unique-identifiers-user-tracking +requirement: "The app does not use persistent or unique identifiers in a way that enables user tracking." platform: ["android", "ios"] profiles: ["P"] mappings: diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0067.md b/weaknesses/MASVS-PRIVACY/MASWE-0067.md index 9b9236f..6adf7d3 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0067.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0067.md @@ -2,6 +2,7 @@ title: Inadequate Privacy Policy id: MASWE-0067 alias: privacy-policy +requirement: "The app provides an adequate privacy policy." platform: ["android", "ios"] profiles: ["P"] mappings: diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0068.md b/weaknesses/MASVS-PRIVACY/MASWE-0068.md index 9c96b8a..654e786 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0068.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0068.md @@ -2,6 +2,7 @@ title: Inadequate Data Collection Declarations id: MASWE-0068 alias: data-collection-declarations +requirement: "The app adequately declares all user collected data." platform: ["android", "ios"] profiles: ["P"] mappings: diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0069.md b/weaknesses/MASVS-PRIVACY/MASWE-0069.md index 6b50c62..0c144f6 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0069.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0069.md @@ -2,6 +2,7 @@ title: Lack of Proper Data Management Controls id: MASWE-0069 alias: data-management-controls +requirement: "The app provides adequate controls to manage user data." platform: ["android", "ios"] profiles: ["P"] mappings: diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0070.md b/weaknesses/MASVS-PRIVACY/MASWE-0070.md index f97d6e3..17d5f6c 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0070.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0070.md @@ -2,6 +2,7 @@ title: Inadequate Data Visibility Controls id: MASWE-0070 alias: data-visibility-control +requirement: "The app provides adequate controls over the visibility of user data." platform: ["android", "ios"] profiles: ["P"] mappings: diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0071.md b/weaknesses/MASVS-PRIVACY/MASWE-0071.md index 65513ce..eaf9fd3 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0071.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0071.md @@ -2,6 +2,7 @@ title: Inadequate or Ambiguous User Consent Mechanisms id: MASWE-0071 alias: ambiguous-consent-mechanisms +requirement: "The app requests user consent prior to any data processing." platform: ["android", "ios"] profiles: ["P"] mappings: diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0072.md b/weaknesses/MASVS-PRIVACY/MASWE-0072.md index 11c7c16..986caf2 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0072.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0072.md @@ -2,6 +2,7 @@ title: Inadequate Permission Management id: MASWE-0072 alias: inadequate-permission-management +requirement: "The app adequately manages permissions." platform: ["android", "ios"] profiles: ["P"] mappings: diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0073.md b/weaknesses/MASVS-PRIVACY/MASWE-0073.md index fa8243b..265c0c3 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0073.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0073.md @@ -2,6 +2,7 @@ title: Inadequate Tracking Domains Declarations id: MASWE-0073 alias: tracking-domains-declarations +requirement: "The app adequately declares all tracking domains it connects to." platform: ["android", "ios"] profiles: ["P"] mappings: diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0074.md b/weaknesses/MASVS-PRIVACY/MASWE-0074.md index 500b636..1007078 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0074.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0074.md @@ -2,6 +2,7 @@ title: Usage of Non-Privacy-Preserving Functionality id: MASWE-0074 alias: non-privacy-preserving-functionality +requirement: "The app uses privacy-preserving functionality." platform: [android, ios] profiles: [P] mappings: diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0049.md b/weaknesses/MASVS-RESILIENCE/MASWE-0049.md index dfc966b..ddfee82 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0049.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0049.md @@ -2,6 +2,7 @@ title: Missing Device Secure Lock Verification Implementation id: MASWE-0049 alias: secured-device-detection-not-implemented +requirement: "The app verifies that the device has a secure lock screen configured before enabling sensitive functionality." platform: [android, ios] profiles: [L2] mappings: diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0050.md b/weaknesses/MASVS-RESILIENCE/MASWE-0050.md index d16952e..23873df 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0050.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0050.md @@ -2,6 +2,7 @@ title: Debug Mechanisms Not Disabled id: MASWE-0050 alias: debuggable-flag +requirement: "The app disables debug mechanisms." platform: [android, ios] profiles: [R] mappings: diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0051.md b/weaknesses/MASVS-RESILIENCE/MASWE-0051.md index 1699527..06e8bf0 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0051.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0051.md @@ -2,6 +2,7 @@ title: Code Obfuscation Not Implemented id: MASWE-0051 alias: code-obfuscation +requirement: "The app applies code obfuscation to hinder reverse engineering." platform: [android, ios] profiles: [R] mappings: diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0052.md b/weaknesses/MASVS-RESILIENCE/MASWE-0052.md index 12e4bde..f737b7b 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0052.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0052.md @@ -2,6 +2,7 @@ title: Resource Obfuscation Not Implemented id: MASWE-0052 alias: resource-obfuscation +requirement: "The app applies resource obfuscation to hinder reverse engineering." platform: [android, ios] profiles: [R] mappings: diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0053.md b/weaknesses/MASVS-RESILIENCE/MASWE-0053.md index b2e2269..1c38553 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0053.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0053.md @@ -2,6 +2,7 @@ title: Anti-Deobfuscation Techniques Not Implemented id: MASWE-0053 alias: anti-deobfuscation +requirement: "The app implements anti-deobfuscation techniques to protect its obfuscation." platform: [android, ios] profiles: [R] mappings: diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0054.md b/weaknesses/MASVS-RESILIENCE/MASWE-0054.md index 73a0aeb..e6a3f26 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0054.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0054.md @@ -2,6 +2,7 @@ title: Debug Artifacts Not Removed id: MASWE-0054 alias: non-production-resources +requirement: "The app removes debug artifacts." platform: [android, ios] profiles: [R] mappings: diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0055.md b/weaknesses/MASVS-RESILIENCE/MASWE-0055.md index 3ac96f7..495cfa2 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0055.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0055.md @@ -2,6 +2,7 @@ title: No Application-Level Payload Encryption id: MASWE-0055 alias: data-unencrypted +requirement: "The app applies application-level payload encryption in addition to transport-layer encryption." platform: [android, ios] profiles: [R] mappings: diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0056.md b/weaknesses/MASVS-RESILIENCE/MASWE-0056.md index cd7dedc..f0a668d 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0056.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0056.md @@ -2,6 +2,7 @@ title: Root/Jailbreak Detection Not Implemented id: MASWE-0056 alias: root-jailbreak-detection +requirement: "The app terminates if a rooted/jailbroken device is detected." platform: [android, ios] profiles: [R] mappings: diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0057.md b/weaknesses/MASVS-RESILIENCE/MASWE-0057.md index 59c0cea..0d5153c 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0057.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0057.md @@ -2,6 +2,7 @@ title: App Virtualization Environment Detection Not Implemented id: MASWE-0057 alias: app-virtualization-detection +requirement: "The app detects when it is running inside an app-virtualization environment." platform: [android, ios] profiles: [R] mappings: diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0058.md b/weaknesses/MASVS-RESILIENCE/MASWE-0058.md index ab32393..cdfb0f8 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0058.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0058.md @@ -2,6 +2,7 @@ title: Emulator Detection Not Implemented id: MASWE-0058 alias: emulator-detection +requirement: "The app detects when it is running on an emulator." platform: [android, ios] profiles: [R] mappings: diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0059.md b/weaknesses/MASVS-RESILIENCE/MASWE-0059.md index 91df9bd..0c99a69 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0059.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0059.md @@ -2,6 +2,7 @@ title: Device Attestation Not Implemented id: MASWE-0059 alias: device-attestation +requirement: "The app implements device attestation." platform: [android, ios] profiles: [R] mappings: diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0060.md b/weaknesses/MASVS-RESILIENCE/MASWE-0060.md index 5a54259..340085f 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0060.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0060.md @@ -2,6 +2,7 @@ title: Debugger Detection Not Implemented id: MASWE-0060 alias: debugger-detection +requirement: "The app terminates if a debugger is detected." platform: [android, ios] profiles: [R] mappings: diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0061.md b/weaknesses/MASVS-RESILIENCE/MASWE-0061.md index 5474691..56ccbd3 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0061.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0061.md @@ -2,6 +2,7 @@ title: Dynamic Analysis Tools Detection Not Implemented id: MASWE-0061 alias: dynamic-analysis-tools +requirement: "The app detects dynamic analysis tools." platform: [android, ios] profiles: [R] mappings: diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0062.md b/weaknesses/MASVS-RESILIENCE/MASWE-0062.md index 87dc8c8..b733b9f 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0062.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0062.md @@ -2,6 +2,7 @@ title: App Attestation Not Implemented id: MASWE-0062 alias: app-integrity +requirement: "The app implements app attestation." platform: [android, ios] profiles: [R] mappings: diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0063.md b/weaknesses/MASVS-RESILIENCE/MASWE-0063.md index b76e5b3..f764aa6 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0063.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0063.md @@ -2,6 +2,7 @@ title: App Resources Integrity Not Verified id: MASWE-0063 alias: app-resources-integrity +requirement: "The app verifies the integrity of its resources." platform: [android, ios] profiles: [R] mappings: diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0064.md b/weaknesses/MASVS-RESILIENCE/MASWE-0064.md index 27308fe..70abe46 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0064.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0064.md @@ -2,6 +2,7 @@ title: Code Integrity Not Verified id: MASWE-0064 alias: runtime-code-integrity +requirement: "The app verifies the integrity of its code." platform: [android, ios] profiles: [R] mappings: diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0076.md b/weaknesses/MASVS-RESILIENCE/MASWE-0076.md index 9354e51..c087e11 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0076.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0076.md @@ -2,6 +2,7 @@ title: Malware Detection Not Implemented id: MASWE-0076 alias: malware-detection +requirement: "The app detects attacks by malware." platform: [android, ios] profiles: [R] mappings: diff --git a/weaknesses/MASVS-STORAGE/MASWE-0001.md b/weaknesses/MASVS-STORAGE/MASWE-0001.md index 3723c8a..ea66588 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0001.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0001.md @@ -2,6 +2,7 @@ title: Insertion of Sensitive Data into Logs id: MASWE-0001 alias: data-in-logs +requirement: "The app excludes sensitive data from application logs." platform: ["android", "ios"] profiles: ["L1", "L2", "P"] mappings: diff --git a/weaknesses/MASVS-STORAGE/MASWE-0002.md b/weaknesses/MASVS-STORAGE/MASWE-0002.md index fde7b55..3313417 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0002.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0002.md @@ -2,6 +2,7 @@ title: Sensitive Data Not Excluded From Backup id: MASWE-0002 alias: data-not-excluded-backup +requirement: "The app excludes sensitive data from backups." platform: [android, ios] profiles: [L1, L2, P] mappings: diff --git a/weaknesses/MASVS-STORAGE/MASWE-0003.md b/weaknesses/MASVS-STORAGE/MASWE-0003.md index 57d6890..e1a8bcb 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0003.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0003.md @@ -2,6 +2,7 @@ title: Sensitive Data Stored Unencrypted in Private Storage id: MASWE-0003 alias: data-unencrypted-private-storage +requirement: "The app encrypts sensitive data stored in private storage." platform: [android, ios] profiles: [L2] mappings: diff --git a/weaknesses/MASVS-STORAGE/MASWE-0004.md b/weaknesses/MASVS-STORAGE/MASWE-0004.md index bff40c3..ef98ff5 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0004.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0004.md @@ -2,6 +2,7 @@ title: Sensitive Data Stored Unencrypted Outside of Private Storage id: MASWE-0004 alias: data-unencrypted-shared-storage-no-user-interaction +requirement: "The app encrypts sensitive data stored outside of private storage." platform: [android] profiles: [L1, L2] mappings: diff --git a/weaknesses/MASVS-STORAGE/MASWE-0005.md b/weaknesses/MASVS-STORAGE/MASWE-0005.md index 15b9789..2f5faf6 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0005.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0005.md @@ -2,6 +2,7 @@ title: Cryptographic Keys Stored Outside of Platform Keystore id: MASWE-0005 alias: crypto-keys-not-protected-at-rest +requirement: "The app stores cryptographic keys inside the platform-provided secure keystore." platform: [android, ios] profiles: [L1, L2] mappings: diff --git a/weaknesses/MASVS-STORAGE/MASWE-0006.md b/weaknesses/MASVS-STORAGE/MASWE-0006.md index 1e21c64..bae41d5 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0006.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0006.md @@ -2,6 +2,7 @@ title: Sensitive Data Hardcoded in the App Package id: MASWE-0006 alias: data-hardcoded-app-package +requirement: "The app does not hardcode sensitive data in the application package." platform: [android, ios] profiles: [L1, L2] mappings: From 64ae6df3e9872dd2f094c84f05f612b4f8192c1b Mon Sep 17 00:00:00 2001 From: Carlos Holguera Date: Sun, 19 Jul 2026 12:15:59 +0200 Subject: [PATCH 05/70] add missing android risks and fix existing ones --- weaknesses/MASVS-AUTH/MASWE-0020.md | 6 +++++ weaknesses/MASVS-CODE/MASWE-0041.md | 1 + weaknesses/MASVS-CODE/MASWE-0042.md | 5 +++- weaknesses/MASVS-CODE/MASWE-0044.md | 5 ++-- weaknesses/MASVS-CODE/MASWE-0045.md | 2 ++ weaknesses/MASVS-CODE/MASWE-0047.md | 33 ++++++++++++++++------- weaknesses/MASVS-CODE/MASWE-0048.md | 9 +++++++ weaknesses/MASVS-CODE/MASWE-0077.md | 1 + weaknesses/MASVS-CRYPTO/MASWE-0007.md | 2 +- weaknesses/MASVS-CRYPTO/MASWE-0011.md | 2 ++ weaknesses/MASVS-CRYPTO/MASWE-0016.md | 2 +- weaknesses/MASVS-PLATFORM/MASWE-0031.md | 2 ++ weaknesses/MASVS-PLATFORM/MASWE-0032.md | 2 ++ weaknesses/MASVS-PLATFORM/MASWE-0033.md | 2 ++ weaknesses/MASVS-PLATFORM/MASWE-0035.md | 6 +++++ weaknesses/MASVS-PLATFORM/MASWE-0036.md | 2 ++ weaknesses/MASVS-PLATFORM/MASWE-0038.md | 3 +++ weaknesses/MASVS-PRIVACY/MASWE-0074.md | 8 ++++-- weaknesses/MASVS-RESILIENCE/MASWE-0054.md | 2 ++ 19 files changed, 78 insertions(+), 17 deletions(-) diff --git a/weaknesses/MASVS-AUTH/MASWE-0020.md b/weaknesses/MASVS-AUTH/MASWE-0020.md index f72be35..df706ab 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0020.md +++ b/weaknesses/MASVS-AUTH/MASWE-0020.md @@ -9,6 +9,12 @@ mappings: masvs-v1: [MSTG-PLATFORM-4, MSTG-AUTH-3, MSTG-NETWORK-2, MSTG-STORAGE-6] masvs-v2: [MASVS-AUTH-1, MASVS-PLATFORM-1, MASVS-STORAGE-2] cwe: [200, 276, 284, 285, 287, 732, 749, 923, 925, 926] + android-risks: + - https://developer.android.com/privacy-and-security/risks/content-resolver + - https://developer.android.com/privacy-and-security/risks/insecure-broadcast-receiver + - https://developer.android.com/privacy-and-security/risks/access-control-to-exported-components + - https://developer.android.com/privacy-and-security/risks/android-exported + - https://developer.android.com/privacy-and-security/risks/custom-permissions refs: - https://developer.android.com/privacy-and-security/security-tips#IPNetworking diff --git a/weaknesses/MASVS-CODE/MASWE-0041.md b/weaknesses/MASVS-CODE/MASWE-0041.md index abab90c..c8dc613 100644 --- a/weaknesses/MASVS-CODE/MASWE-0041.md +++ b/weaknesses/MASVS-CODE/MASWE-0041.md @@ -12,6 +12,7 @@ mappings: android-core-app-quality: [SC-N3, PS-T4] android-risks: - https://developer.android.com/privacy-and-security/risks/insecure-library + - https://developer.android.com/privacy-and-security/risks/unsafe-download-manager nist-ssdf: [PS.3.2] status: new refs: diff --git a/weaknesses/MASVS-CODE/MASWE-0042.md b/weaknesses/MASVS-CODE/MASWE-0042.md index 0391b18..39f29e6 100644 --- a/weaknesses/MASVS-CODE/MASWE-0042.md +++ b/weaknesses/MASVS-CODE/MASWE-0042.md @@ -1,5 +1,5 @@ --- -title: Running on a recent Platform Version Not Ensured +title: Running on a Recent Platform Version Not Ensured id: MASWE-0042 alias: run-on-recent-platform-version requirement: "The app terminates if an unsupported OS version is detected." @@ -8,6 +8,9 @@ profiles: [L2] mappings: masvs-v2: [MASVS-CODE-1] cwe: [451, 693, 1104, 1357] + android-risks: + - https://developer.android.com/privacy-and-security/risks/strandhogg + - https://developer.android.com/privacy-and-security/risks/unsafe-download-manager refs: - https://developer.android.com/topic/security/risks/strandhogg diff --git a/weaknesses/MASVS-CODE/MASWE-0044.md b/weaknesses/MASVS-CODE/MASWE-0044.md index 0320002..ea5029e 100644 --- a/weaknesses/MASVS-CODE/MASWE-0044.md +++ b/weaknesses/MASVS-CODE/MASWE-0044.md @@ -8,9 +8,10 @@ profiles: [L2] mappings: masvs-v2: [MASVS-CODE-4] cwe: [494] + android-risks: + - https://developer.android.com/privacy-and-security/risks/dynamic-code-loading + - https://developer.android.com/privacy-and-security/risks/create-package-context -refs: -- https://developer.android.com/privacy-and-security/risks/runtime-code-loading beta-coverage: [MASWE-0085] draft: description: | diff --git a/weaknesses/MASVS-CODE/MASWE-0045.md b/weaknesses/MASVS-CODE/MASWE-0045.md index 3a6b211..4654fbe 100644 --- a/weaknesses/MASVS-CODE/MASWE-0045.md +++ b/weaknesses/MASVS-CODE/MASWE-0045.md @@ -8,6 +8,8 @@ profiles: [L2] mappings: masvs-v2: [MASVS-CODE-3, MASVS-CODE-4] cwe: [693] + android-risks: + - https://developer.android.com/privacy-and-security/risks/use-of-native-code refs: - https://cs.android.com/android/platform/superproject/main/+/main:bionic/linker/linker_main.cpp;l=397?q=linker_main&ss=android%2Fplatform%2Fsuperproject%2Fmain - https://partners.trellix.com/enterprise/en-us/assets/white-papers/wp-secure-coding-android-applications.pdf diff --git a/weaknesses/MASVS-CODE/MASWE-0047.md b/weaknesses/MASVS-CODE/MASWE-0047.md index 3ea1ed7..369f927 100644 --- a/weaknesses/MASVS-CODE/MASWE-0047.md +++ b/weaknesses/MASVS-CODE/MASWE-0047.md @@ -1,14 +1,16 @@ --- -title: Using Non-Standard Libraries for Security-Critical Functionality +title: Using Non-Standard APIs for Security-Critical Functionality id: MASWE-0047 -alias: non-standard-security-libs -requirement: "The app does not use non-standard libraries for security-critical functionality." +alias: non-standard-security-apis +requirement: "The app does not use non-standard APIs for security-critical functionality." platform: [android, ios] profiles: [L2] mappings: masvs-v1: [MSTG-CRYPTO-2, MSTG-NETWORK-6] masvs-v2: [MASVS-CODE-3, MASVS-AUTH-1, MASVS-CRYPTO-1, MASVS-NETWORK-1] cwe: [287, 326, 327, 1240] + android-risks: + - https://developer.android.com/privacy-and-security/risks/bad-dns refs: - https://developer.android.com/privacy-and-security/security-tips#Credentials @@ -18,29 +20,40 @@ refs: beta-coverage: [MASWE-0019, MASWE-0032, MASWE-0049] draft: description: | - Security-critical functionality (cryptography, networking/TLS, and authentication) should - rely on well-vetted, platform-provided APIs or established, peer-reviewed libraries rather - than custom ("roll-your-own") implementations or unproven third-party libraries. Platform - APIs are designed and maintained by experts, incorporate security best practices, and are - regularly updated to address new threats. Custom or non-standard implementations are far - more likely to contain subtle, exploitable flaws and to miss timely security updates. + Security-critical functionality (cryptography, networking/TLS, DNS, and authentication) should + rely on platform-provided APIs and functionality or established, peer-reviewed libraries, + rather than on custom ("roll-your-own") implementations or unproven third-party components. + Platform APIs and vetted libraries are designed and maintained by experts, incorporate security + best practices, and receive timely updates; custom or non-standard implementations are far more + likely to contain subtle, exploitable flaws and to miss security updates. This weakness also + covers cases where the app fails to leverage secure functionality the platform already provides, + for example using an insecure custom DNS setup instead of the platform's Private DNS / + DNS-over-TLS support. This weakness consolidates: - **Risky cryptography implementations**: custom or non-compliant crypto (e.g. not meeting standards such as FIPS 140-2/3), unproven algorithms, or home-grown constructions that haven't undergone rigorous peer review and formal validation. - - **Non-standard networking**: rolling a custom networking/TLS stack or using outdated + - **Non-standard networking**: rolling a custom networking/TLS stack, using an insecure custom + DNS setup instead of the platform's secure name-resolution functionality, or using outdated third-party networking libraries instead of proven APIs such as `URLSession`/`NSURLSession` on iOS or `HttpsURLConnection`/`OkHttp` on Android. - **Non-standard authentication**: implementing custom authentication instead of using platform-provided authentication APIs (e.g. Android Credential Manager/`AccountManager`, iOS Authentication Services / Password AutoFill). + + Note: this can be seen as the security-focused counterpart to @MASWE-0074 (Usage of Non-Privacy-Preserving + Functionality), which applies the same "leverage platform-provided features rather than custom + or non-standard alternatives" principle from a privacy angle. The overlap is intentional: some + platform APIs (e.g. `ASWebAuthenticationSession` / Custom Tabs) improve both security and + privacy. topics: - roll-your-own cryptography vs. vetted, standards-compliant libraries - custom networking/TLS stacks vs. proven networking APIs (URLSession, HttpsURLConnection, OkHttp, Alamofire) - custom authentication vs. platform-provided authentication APIs (Credential Manager, AccountManager, Authentication Services) - unmaintained/unproven third-party security libraries + - Custom DNS Resolution, the app bypasses platform-provided name resolution by implementing or configuring a custom resolver without equivalent transport security, trust management, and update guarantees. status: placeholder --- diff --git a/weaknesses/MASVS-CODE/MASWE-0048.md b/weaknesses/MASVS-CODE/MASWE-0048.md index 06311c6..d371cc9 100644 --- a/weaknesses/MASVS-CODE/MASWE-0048.md +++ b/weaknesses/MASVS-CODE/MASWE-0048.md @@ -9,6 +9,14 @@ mappings: masvs-v1: [MSTG-PLATFORM-2] masvs-v2: [MASVS-CODE-4] cwe: [20, 22, 73, 89, 116, 345, 348, 349, 502, 611, 924] + android-risks: + - https://developer.android.com/privacy-and-security/risks/path-traversal + - https://developer.android.com/privacy-and-security/risks/zip-path-traversal + - https://developer.android.com/privacy-and-security/risks/sql-injection + - https://developer.android.com/privacy-and-security/risks/unsafe-deserialization + - https://developer.android.com/privacy-and-security/risks/xml-external-entities-injection + - https://developer.android.com/privacy-and-security/risks/untrustworthy-contentprovider-provided-filename + - https://developer.android.com/privacy-and-security/risks/use-of-native-code refs: - https://developer.android.com/topic/security/risks/path-traversal @@ -44,6 +52,7 @@ draft: - SQL injection / parameterized queries - insecure parsing and escaping (XXE, output encoding) - insecure object deserialization (Serializable, Parcelable, NSCoding, XML/JSON) + - use of the Uri class on Android which applies little to no validation on untrusted input (see android docs for Uri) status: placeholder --- diff --git a/weaknesses/MASVS-CODE/MASWE-0077.md b/weaknesses/MASVS-CODE/MASWE-0077.md index 6c8bb62..8b95aef 100644 --- a/weaknesses/MASVS-CODE/MASWE-0077.md +++ b/weaknesses/MASVS-CODE/MASWE-0077.md @@ -12,6 +12,7 @@ mappings: refs: - https://reproducible-builds.org/ - https://slsa.dev/ +- https://github.com/signalapp/Signal-Android/blob/main/reproducible-builds/README.md draft: description: | A build is reproducible when compiling the same source with the same build environment diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0007.md b/weaknesses/MASVS-CRYPTO/MASWE-0007.md index f6d1434..cb87f14 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0007.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0007.md @@ -9,7 +9,7 @@ mappings: masvs-v1: [MSTG-CRYPTO-2] masvs-v2: [MASVS-CRYPTO-2] cwe: [331, 337, 338, 522] - android-risks: + android-risks: - https://developer.android.com/privacy-and-security/risks/weak-prng refs: - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0011.md b/weaknesses/MASVS-CRYPTO/MASWE-0011.md index e46d91a..aed7f8a 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0011.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0011.md @@ -9,6 +9,8 @@ mappings: masvs-v1: [MSTG-CRYPTO-4, MSTG-CRYPTO-5] masvs-v2: [MASVS-CRYPTO-1, MASVS-CRYPTO-2] cwe: [208, 323, 325, 326, 327, 329, 780] + android-risks: + - https://developer.android.com/privacy-and-security/risks/broken-cryptographic-algorithm refs: - https://support.google.com/faqs/answer/10046138?hl=en diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0016.md b/weaknesses/MASVS-CRYPTO/MASWE-0016.md index 26f42f1..afea995 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0016.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0016.md @@ -9,7 +9,7 @@ mappings: masvs-v1: [MSTG-CRYPTO-6] masvs-v2: [MASVS-CRYPTO-1] cwe: [332, 337, 338] - android-risks: + android-risks: - https://developer.android.com/privacy-and-security/risks/weak-prng observed_examples: - https://nvd.nist.gov/vuln/detail/CVE-2013-6386 diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0031.md b/weaknesses/MASVS-PLATFORM/MASWE-0031.md index 8756acd..047bf5a 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0031.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0031.md @@ -9,6 +9,8 @@ mappings: masvs-v1: [MSTG-PLATFORM-9] masvs-v2: [MASVS-PLATFORM-3, MASVS-CODE-1] cwe: [1021] + android-risks: + - https://developer.android.com/privacy-and-security/risks/tapjacking refs: - https://developer.android.com/topic/security/risks/tapjacking diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0032.md b/weaknesses/MASVS-PLATFORM/MASWE-0032.md index afb1481..6301c35 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0032.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0032.md @@ -9,6 +9,8 @@ mappings: masvs-v1: [MSTG-PLATFORM-3] masvs-v2: [MASVS-PLATFORM-1, MASVS-STORAGE-2, MASVS-CODE-4] cwe: [939, 917] + android-risks: + - https://developer.android.com/privacy-and-security/risks/unsafe-use-of-deeplinks draft: description: | diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0033.md b/weaknesses/MASVS-PLATFORM/MASWE-0033.md index cc596cc..cb6cb7f 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0033.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0033.md @@ -8,6 +8,8 @@ profiles: [L1, L2] mappings: masvs-v2: [MASVS-PLATFORM-1, MASVS-STORAGE-2] cwe: [200, 668] + android-risks: + - https://developer.android.com/privacy-and-security/risks/secure-clipboard-handling refs: - https://developer.android.com/develop/ui/views/touch-and-input/copy-paste#PreventingSensitiveData diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0035.md b/weaknesses/MASVS-PLATFORM/MASWE-0035.md index 766dddb..096d2ab 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0035.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0035.md @@ -8,6 +8,12 @@ profiles: [L1, L2] mappings: masvs-v2: [MASVS-PLATFORM-1, MASVS-STORAGE-2] cwe: [927, 940] + android-risks: + - https://developer.android.com/privacy-and-security/risks/implicit-intent-hijacking + - https://developer.android.com/privacy-and-security/risks/intent-redirection + - https://developer.android.com/privacy-and-security/risks/pending-intent + - https://developer.android.com/privacy-and-security/risks/sender-of-pending-intents + - https://developer.android.com/privacy-and-security/risks/sticky-broadcast refs: - https://support.google.com/faqs/answer/9267555?hl=en diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0036.md b/weaknesses/MASVS-PLATFORM/MASWE-0036.md index a3bbe0a..bf7208a 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0036.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0036.md @@ -9,6 +9,8 @@ mappings: masvs-v1: [MSTG-PLATFORM-7] masvs-v2: [MASVS-PLATFORM-2, MASVS-STORAGE-2] cwe: [749, 94] + android-risks: + - https://developer.android.com/privacy-and-security/risks/insecure-webview-native-bridges refs: - https://support.google.com/faqs/answer/9095419 diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0038.md b/weaknesses/MASVS-PLATFORM/MASWE-0038.md index cfea171..626f2a3 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0038.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0038.md @@ -8,6 +8,9 @@ profiles: [L1, L2] mappings: masvs-v2: [MASVS-PLATFORM-2, MASVS-CODE-4] cwe: [79, 601, 829] + android-risks: + - https://developer.android.com/privacy-and-security/risks/cross-app-scripting + - https://developer.android.com/privacy-and-security/risks/unsafe-uri-loading refs: - https://blog.oversecured.com/Evernote-Universal-XSS-theft-of-all-cookies-from-all-sites-and-more/ diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0074.md b/weaknesses/MASVS-PRIVACY/MASWE-0074.md index 1007078..bbcd796 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0074.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0074.md @@ -32,8 +32,12 @@ draft: (`PHPickerViewController` on iOS, the Android Photo Picker), which returns only the items the user selects without any permission grant. - Note: this weakness is intended to also incorporate the original content on non-privacy-preserving - functionality; confirm the intended source material before finalizing. + Note: this can be seen as the privacy-focused counterpart to @MASWE-0047 (Using Non-Standard APIs for + Security-Critical Functionality), which applies the same "leverage platform-provided features + rather than custom or non-standard alternatives" principle from a security angle. The overlap is + intentional: some platform features (e.g. `ASWebAuthenticationSession` / Custom Tabs) improve + both privacy and security. Here the focus is specifically on choosing privacy-preserving + functionality. topics: - use of ASWebAuthenticationSession / Custom Tabs instead of embedded WebViews or SFAuthenticationSession - RFC 8252 best practices for OAuth in native apps diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0054.md b/weaknesses/MASVS-RESILIENCE/MASWE-0054.md index e6a3f26..f30081a 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0054.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0054.md @@ -9,6 +9,8 @@ mappings: masvs-v1: [MSTG-CODE-3, MSTG-CODE-4] masvs-v2: [MASVS-RESILIENCE-3] cwe: [489, 497, 540, 912, 1295] + android-risks: + - https://developer.android.com/privacy-and-security/risks/test-debug beta-coverage: [MASWE-0094, MASWE-0093, MASWE-0095] draft: From fcf738b623e6586bbb1d129a1d1b79609586ccff Mon Sep 17 00:00:00 2001 From: Carlos Holguera Date: Sun, 19 Jul 2026 12:21:03 +0200 Subject: [PATCH 06/70] fix some maswe refs --- weaknesses/MASVS-PLATFORM/MASWE-0033.md | 3 +-- weaknesses/MASVS-RESILIENCE/MASWE-0054.md | 2 +- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0033.md b/weaknesses/MASVS-PLATFORM/MASWE-0033.md index cb6cb7f..e8b7e58 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0033.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0033.md @@ -25,8 +25,7 @@ draft: excluding items from universal clipboard on iOS), and clear it when appropriate. Note: the general IPC / localhost-server aspects previously covered here have moved to - [MASWE-0020](../MASVS-AUTH/MASWE-0020.md); this weakness exclusively covers improper use of - the clipboard. + @MASWE-0020; this weakness exclusively covers improper use of the clipboard. topics: - copying sensitive data to the clipboard - not marking clipboard content as sensitive (e.g. Android EXTRA_IS_SENSITIVE) diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0054.md b/weaknesses/MASVS-RESILIENCE/MASWE-0054.md index f30081a..3cf763e 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0054.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0054.md @@ -24,7 +24,7 @@ draft: implementation details (CWE-1295), and may allow bypassing security controls (CWE-489, CWE-912). - Note the distinction from [MASWE-0006](../MASVS-STORAGE/MASWE-0006.md): that weakness (in + Note the distinction from @MASWE-0006: that weakness (in STORAGE) covers developer _leftover artifacts_ that leak confidentiality, such as staging / integration URLs, developer emails/usernames, and source code files hardcoded in the package. This weakness (in RESILIENCE) covers developer _debug artifacts_ that weaken the app's From 2991103c9f709c38f2bf41c90674701cb0f9c256 Mon Sep 17 00:00:00 2001 From: Carlos Holguera Date: Sun, 19 Jul 2026 12:52:20 +0200 Subject: [PATCH 07/70] beta-coverage: has been moved from a top-level frontmatter key into the mappings: block, renamed to maswe-beta: --- weaknesses/MASVS-AUTH/MASWE-0017.md | 3 +-- weaknesses/MASVS-AUTH/MASWE-0018.md | 3 +-- weaknesses/MASVS-AUTH/MASWE-0019.md | 3 +-- weaknesses/MASVS-AUTH/MASWE-0020.md | 3 +-- weaknesses/MASVS-AUTH/MASWE-0021.md | 3 +-- weaknesses/MASVS-AUTH/MASWE-0022.md | 3 +-- weaknesses/MASVS-AUTH/MASWE-0023.md | 3 +-- weaknesses/MASVS-AUTH/MASWE-0024.md | 3 +-- weaknesses/MASVS-CODE/MASWE-0040.md | 3 +-- weaknesses/MASVS-CODE/MASWE-0041.md | 2 +- weaknesses/MASVS-CODE/MASWE-0042.md | 3 +-- weaknesses/MASVS-CODE/MASWE-0043.md | 3 +-- weaknesses/MASVS-CODE/MASWE-0044.md | 3 +-- weaknesses/MASVS-CODE/MASWE-0045.md | 2 +- weaknesses/MASVS-CODE/MASWE-0046.md | 3 +-- weaknesses/MASVS-CODE/MASWE-0047.md | 3 +-- weaknesses/MASVS-CODE/MASWE-0048.md | 3 +-- weaknesses/MASVS-CRYPTO/MASWE-0007.md | 2 +- weaknesses/MASVS-CRYPTO/MASWE-0008.md | 3 +-- weaknesses/MASVS-CRYPTO/MASWE-0009.md | 3 +-- weaknesses/MASVS-CRYPTO/MASWE-0010.md | 3 +-- weaknesses/MASVS-CRYPTO/MASWE-0011.md | 3 +-- weaknesses/MASVS-CRYPTO/MASWE-0012.md | 3 +-- weaknesses/MASVS-CRYPTO/MASWE-0013.md | 3 +-- weaknesses/MASVS-CRYPTO/MASWE-0014.md | 3 +-- weaknesses/MASVS-CRYPTO/MASWE-0015.md | 3 +-- weaknesses/MASVS-CRYPTO/MASWE-0016.md | 2 +- weaknesses/MASVS-NETWORK/MASWE-0025.md | 2 +- weaknesses/MASVS-NETWORK/MASWE-0026.md | 2 +- weaknesses/MASVS-NETWORK/MASWE-0027.md | 2 +- weaknesses/MASVS-PLATFORM/MASWE-0028.md | 3 +-- weaknesses/MASVS-PLATFORM/MASWE-0029.md | 3 +-- weaknesses/MASVS-PLATFORM/MASWE-0030.md | 3 +-- weaknesses/MASVS-PLATFORM/MASWE-0031.md | 3 +-- weaknesses/MASVS-PLATFORM/MASWE-0032.md | 3 +-- weaknesses/MASVS-PLATFORM/MASWE-0033.md | 3 +-- weaknesses/MASVS-PLATFORM/MASWE-0034.md | 3 +-- weaknesses/MASVS-PLATFORM/MASWE-0035.md | 3 +-- weaknesses/MASVS-PLATFORM/MASWE-0036.md | 3 +-- weaknesses/MASVS-PLATFORM/MASWE-0037.md | 3 +-- weaknesses/MASVS-PLATFORM/MASWE-0038.md | 3 +-- weaknesses/MASVS-PRIVACY/MASWE-0065.md | 2 +- weaknesses/MASVS-PRIVACY/MASWE-0066.md | 2 +- weaknesses/MASVS-PRIVACY/MASWE-0067.md | 2 +- weaknesses/MASVS-PRIVACY/MASWE-0068.md | 2 +- weaknesses/MASVS-PRIVACY/MASWE-0069.md | 2 +- weaknesses/MASVS-PRIVACY/MASWE-0070.md | 2 +- weaknesses/MASVS-PRIVACY/MASWE-0071.md | 2 +- weaknesses/MASVS-PRIVACY/MASWE-0072.md | 2 +- weaknesses/MASVS-PRIVACY/MASWE-0073.md | 2 +- weaknesses/MASVS-RESILIENCE/MASWE-0049.md | 3 +-- weaknesses/MASVS-RESILIENCE/MASWE-0050.md | 3 +-- weaknesses/MASVS-RESILIENCE/MASWE-0051.md | 3 +-- weaknesses/MASVS-RESILIENCE/MASWE-0052.md | 3 +-- weaknesses/MASVS-RESILIENCE/MASWE-0053.md | 3 +-- weaknesses/MASVS-RESILIENCE/MASWE-0054.md | 3 +-- weaknesses/MASVS-RESILIENCE/MASWE-0055.md | 3 +-- weaknesses/MASVS-RESILIENCE/MASWE-0056.md | 3 +-- weaknesses/MASVS-RESILIENCE/MASWE-0057.md | 3 +-- weaknesses/MASVS-RESILIENCE/MASWE-0058.md | 3 +-- weaknesses/MASVS-RESILIENCE/MASWE-0059.md | 3 +-- weaknesses/MASVS-RESILIENCE/MASWE-0060.md | 3 +-- weaknesses/MASVS-RESILIENCE/MASWE-0061.md | 3 +-- weaknesses/MASVS-RESILIENCE/MASWE-0062.md | 3 +-- weaknesses/MASVS-RESILIENCE/MASWE-0063.md | 3 +-- weaknesses/MASVS-RESILIENCE/MASWE-0064.md | 3 +-- weaknesses/MASVS-STORAGE/MASWE-0001.md | 2 +- weaknesses/MASVS-STORAGE/MASWE-0002.md | 3 +-- weaknesses/MASVS-STORAGE/MASWE-0003.md | 2 +- weaknesses/MASVS-STORAGE/MASWE-0004.md | 2 +- weaknesses/MASVS-STORAGE/MASWE-0005.md | 2 +- weaknesses/MASVS-STORAGE/MASWE-0006.md | 2 +- 72 files changed, 72 insertions(+), 123 deletions(-) diff --git a/weaknesses/MASVS-AUTH/MASWE-0017.md b/weaknesses/MASVS-AUTH/MASWE-0017.md index 36a770d..36ae056 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0017.md +++ b/weaknesses/MASVS-AUTH/MASWE-0017.md @@ -9,14 +9,13 @@ mappings: masvs-v1: [MSTG-AUTH-10] masvs-v2: [MASVS-AUTH-3, MASVS-PLATFORM-3] cwe: [306] - + maswe-beta: [MASWE-0029] refs: - https://developer.apple.com/documentation/localauthentication - https://auth0.com/blog/what-is-step-up-authentication-when-to-use-it/ - https://tdcolvin.medium.com/is-firebase-auth-secure-dace0563d41b - https://github.com/WICG/trust-token-api - https://blog.cloudflare.com/eliminating-captchas-on-iphones-and-macs-using-new-standard/ -beta-coverage: [MASWE-0029] draft: description: | Step-up authentication requires the user to re-authenticate or provide an additional diff --git a/weaknesses/MASVS-AUTH/MASWE-0018.md b/weaknesses/MASVS-AUTH/MASWE-0018.md index 1aeaa30..f3110c1 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0018.md +++ b/weaknesses/MASVS-AUTH/MASWE-0018.md @@ -8,11 +8,10 @@ profiles: [L2] mappings: masvs-v2: [MASVS-AUTH-3] cwe: [285, 287, 613] - + maswe-beta: [MASWE-0030] refs: - https://developers.google.com/identity/sign-in/android/disconnect - https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html -beta-coverage: [MASWE-0030] draft: description: | When a session is terminated (explicit logout, timeout, or a contextual state change such diff --git a/weaknesses/MASVS-AUTH/MASWE-0019.md b/weaknesses/MASVS-AUTH/MASWE-0019.md index 750cccb..4a8a2c6 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0019.md +++ b/weaknesses/MASVS-AUTH/MASWE-0019.md @@ -8,11 +8,10 @@ profiles: [L2] mappings: masvs-v2: [MASVS-AUTH-3] cwe: [287, 778] - + maswe-beta: [MASWE-0031] refs: - https://developer.android.com/training/articles/security-android-protected-confirmation - https://source.android.com/docs/security/features/protected-confirmation -beta-coverage: [MASWE-0031] draft: description: | Critical actions (e.g. confirming a payment or a high-value transaction) should be diff --git a/weaknesses/MASVS-AUTH/MASWE-0020.md b/weaknesses/MASVS-AUTH/MASWE-0020.md index df706ab..19cce3b 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0020.md +++ b/weaknesses/MASVS-AUTH/MASWE-0020.md @@ -15,7 +15,7 @@ mappings: - https://developer.android.com/privacy-and-security/risks/access-control-to-exported-components - https://developer.android.com/privacy-and-security/risks/android-exported - https://developer.android.com/privacy-and-security/risks/custom-permissions - + maswe-beta: [MASWE-0033, MASWE-0038, MASWE-0040, MASWE-0051, MASWE-0059, MASWE-0062, MASWE-0063, MASWE-0064, MASWE-0065, MASWE-0119] refs: - https://developer.android.com/privacy-and-security/security-tips#IPNetworking - https://developer.android.com/privacy-and-security/security-tips#Services @@ -24,7 +24,6 @@ refs: - https://developer.android.com/privacy-and-security/security-tips#binder-and-messenger-interfaces - https://developer.android.com/topic/security/risks/content-resolver - https://developer.android.com/topic/security/risks/file-providers -beta-coverage: [MASWE-0033, MASWE-0038, MASWE-0040, MASWE-0051, MASWE-0059, MASWE-0062, MASWE-0063, MASWE-0064, MASWE-0065, MASWE-0119] draft: description: | App components that expose functionality or data must enforce proper authentication and diff --git a/weaknesses/MASVS-AUTH/MASWE-0021.md b/weaknesses/MASVS-AUTH/MASWE-0021.md index 55c9dfc..8b2c690 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0021.md +++ b/weaknesses/MASVS-AUTH/MASWE-0021.md @@ -9,7 +9,7 @@ mappings: masvs-v1: [MSTG-AUTH-8, MSTG-AUTH-1, MSTG-AUTH-12] masvs-v2: [MASVS-AUTH-2, MASVS-CRYPTO-2] cwe: [285, 287, 312, 319, 326, 602, 603, 863, 922] - + maswe-beta: [MASWE-0034, MASWE-0044, MASWE-0041, MASWE-0042, MASWE-0043] refs: - https://developer.android.com/training/sign-in/biometric-auth#crypto - https://labs.withsecure.com/publications/how-secure-is-your-android-keystore-authentication @@ -17,7 +17,6 @@ refs: - https://github.com/sensepost/objection/issues/136#issuecomment-419664574 - https://github.com/sensepost/objection/wiki/Understanding-the-iOS-Biometrics-Bypass - https://developer.apple.com/documentation/security/secaccesscontrolcreateflags/applicationpassword -beta-coverage: [MASWE-0034, MASWE-0044, MASWE-0041, MASWE-0042, MASWE-0043] draft: description: | Local authentication (biometrics, device credential, a custom app PIN/password, or diff --git a/weaknesses/MASVS-AUTH/MASWE-0022.md b/weaknesses/MASVS-AUTH/MASWE-0022.md index b5afd78..916ef09 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0022.md +++ b/weaknesses/MASVS-AUTH/MASWE-0022.md @@ -8,12 +8,11 @@ profiles: [L2] mappings: masvs-v2: [MASVS-AUTH-2] cwe: [288, 287] - + maswe-beta: [MASWE-0045] refs: - https://developer.android.com/training/sign-in/biometric-auth#allow-fallback - https://developer.apple.com/documentation/localauthentication/logging_a_user_into_your_app_with_face_id_or_touch_id#3148834 - https://developer.apple.com/documentation/localauthentication/lapolicy/deviceownerauthenticationwithbiometrics/ -beta-coverage: [MASWE-0045] draft: description: | For sensitive transactions, allowing authentication to silently fall back from biometrics to a diff --git a/weaknesses/MASVS-AUTH/MASWE-0023.md b/weaknesses/MASVS-AUTH/MASWE-0023.md index 75aec99..c69a3f6 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0023.md +++ b/weaknesses/MASVS-AUTH/MASWE-0023.md @@ -8,8 +8,7 @@ profiles: [L2] mappings: masvs-v2: [MASVS-AUTH-2, MASVS-CRYPTO-2] cwe: [287, 522] - -beta-coverage: [MASWE-0046] + maswe-beta: [MASWE-0046] draft: description: | Cryptographic keys gated by biometric authentication should be invalidated when the set of diff --git a/weaknesses/MASVS-AUTH/MASWE-0024.md b/weaknesses/MASVS-AUTH/MASWE-0024.md index 3849e27..b528f58 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0024.md +++ b/weaknesses/MASVS-AUTH/MASWE-0024.md @@ -9,13 +9,12 @@ mappings: masvs-v1: [MSTG-AUTH-9] masvs-v2: [MASVS-AUTH-1, MASVS-AUTH-3] cwe: [287, 522] - + maswe-beta: [MASWE-0028, MASWE-0032, MASWE-0035, MASWE-0039] refs: - https://developer.apple.com/documentation/security/password_autofill - https://developer.apple.com/documentation/authenticationservices/aswebauthenticationsession - https://developer.android.com/guide/topics/text/autofill - https://developer.apple.com/documentation/authenticationservices/public-private_key_authentication/supporting_passkeys -beta-coverage: [MASWE-0028, MASWE-0032, MASWE-0035, MASWE-0039] draft: description: | Apps should support the platform's auto-fill mechanisms for authenticators so that diff --git a/weaknesses/MASVS-CODE/MASWE-0040.md b/weaknesses/MASVS-CODE/MASWE-0040.md index 3ad4b33..482cb58 100644 --- a/weaknesses/MASVS-CODE/MASWE-0040.md +++ b/weaknesses/MASVS-CODE/MASWE-0040.md @@ -9,7 +9,7 @@ mappings: masvs-v1: [MSTG-ARCH-9] masvs-v2: [MASVS-CODE-2] cwe: [602, 693] - + maswe-beta: [MASWE-0075] refs: - https://developer.android.com/guide/playcore/in-app-updates - https://developer.android.com/reference/com/google/android/play/core/appupdate/AppUpdateManager @@ -28,7 +28,6 @@ draft: - update enforcement only client-side without a server-side check (CWE-602) - AppUpdateManager (Android In-App Updates) / App Store version check (iOS) - server-driven minimum-supported-version enforcement -beta-coverage: [MASWE-0075] status: placeholder --- diff --git a/weaknesses/MASVS-CODE/MASWE-0041.md b/weaknesses/MASVS-CODE/MASWE-0041.md index c8dc613..1a784c9 100644 --- a/weaknesses/MASVS-CODE/MASWE-0041.md +++ b/weaknesses/MASVS-CODE/MASWE-0041.md @@ -14,6 +14,7 @@ mappings: - https://developer.android.com/privacy-and-security/risks/insecure-library - https://developer.android.com/privacy-and-security/risks/unsafe-download-manager nist-ssdf: [PS.3.2] + maswe-beta: [MASWE-0076] status: new refs: - https://developer.android.com/privacy-and-security/risks/insecure-library @@ -27,7 +28,6 @@ refs: - https://developer.apple.com/support/third-party-SDK-requirements/ - https://www.youtube.com/watch?v=3klmiHX0uVQ - https://developer.apple.com/videos/play/wwdc2023/10060/ -beta-coverage: [MASWE-0076] --- ## Overview diff --git a/weaknesses/MASVS-CODE/MASWE-0042.md b/weaknesses/MASVS-CODE/MASWE-0042.md index 39f29e6..719f728 100644 --- a/weaknesses/MASVS-CODE/MASWE-0042.md +++ b/weaknesses/MASVS-CODE/MASWE-0042.md @@ -11,10 +11,9 @@ mappings: android-risks: - https://developer.android.com/privacy-and-security/risks/strandhogg - https://developer.android.com/privacy-and-security/risks/unsafe-download-manager - + maswe-beta: [MASWE-0077, MASWE-0057] refs: - https://developer.android.com/topic/security/risks/strandhogg -beta-coverage: [MASWE-0077, MASWE-0057] draft: description: | e.g. via minSdkVersion on Android and MinimumOSVersion on iOS. Ensuring a recent minimum diff --git a/weaknesses/MASVS-CODE/MASWE-0043.md b/weaknesses/MASVS-CODE/MASWE-0043.md index 6e234ea..03e45de 100644 --- a/weaknesses/MASVS-CODE/MASWE-0043.md +++ b/weaknesses/MASVS-CODE/MASWE-0043.md @@ -8,7 +8,7 @@ profiles: [L2] mappings: masvs-v2: [MASVS-CODE-1] cwe: [693, 1357] - + maswe-beta: [MASWE-0078] draft: description: | Targeting the latest platform version (via `targetSdkVersion` on Android or by building with a @@ -23,7 +23,6 @@ draft: - Xcode / SDK version used to build on iOS - missing newer platform-enforced protections (scoped storage, permission auto-reset, TLS defaults) - backward-compatibility behaviors applied to apps targeting old versions -beta-coverage: [MASWE-0078] status: placeholder --- diff --git a/weaknesses/MASVS-CODE/MASWE-0044.md b/weaknesses/MASVS-CODE/MASWE-0044.md index ea5029e..cf0d195 100644 --- a/weaknesses/MASVS-CODE/MASWE-0044.md +++ b/weaknesses/MASVS-CODE/MASWE-0044.md @@ -11,8 +11,7 @@ mappings: android-risks: - https://developer.android.com/privacy-and-security/risks/dynamic-code-loading - https://developer.android.com/privacy-and-security/risks/create-package-context - -beta-coverage: [MASWE-0085] + maswe-beta: [MASWE-0085] draft: description: | Loading and executing code that is fetched or resolved at runtime (e.g. via `dlopen`, diff --git a/weaknesses/MASVS-CODE/MASWE-0045.md b/weaknesses/MASVS-CODE/MASWE-0045.md index 4654fbe..5b87a51 100644 --- a/weaknesses/MASVS-CODE/MASWE-0045.md +++ b/weaknesses/MASVS-CODE/MASWE-0045.md @@ -10,6 +10,7 @@ mappings: cwe: [693] android-risks: - https://developer.android.com/privacy-and-security/risks/use-of-native-code + maswe-beta: [MASWE-0116] refs: - https://cs.android.com/android/platform/superproject/main/+/main:bionic/linker/linker_main.cpp;l=397?q=linker_main&ss=android%2Fplatform%2Fsuperproject%2Fmain - https://partners.trellix.com/enterprise/en-us/assets/white-papers/wp-secure-coding-android-applications.pdf @@ -31,7 +32,6 @@ draft: - fortify-source / bounds-checked libc functions - Automatic Reference Counting / memory-safe language usage where applicable note: PIC cannot be switched off in newer versions of Android, the NDK does not link against such libraries anymore [source](https://cs.android.com/android/platform/superproject/main/+/main:bionic/linker/linker_main.cpp;l=397?q=linker_main&ss=android%2Fplatform%2Fsuperproject%2Fmain). Alternative title could be Memory Anti-Exploitation Mechanisms Not Implemented. -beta-coverage: [MASWE-0116] status: placeholder observed_examples: - https://nvd.nist.gov/vuln/detail/CVE-2019-3568 diff --git a/weaknesses/MASVS-CODE/MASWE-0046.md b/weaknesses/MASVS-CODE/MASWE-0046.md index 7905a77..3a8ded9 100644 --- a/weaknesses/MASVS-CODE/MASWE-0046.md +++ b/weaknesses/MASVS-CODE/MASWE-0046.md @@ -9,12 +9,11 @@ mappings: masvs-v1: [MSTG-CRYPTO-4] masvs-v2: [MASVS-CODE-3, MASVS-CRYPTO-2] cwe: [327, 477, 522] - + maswe-beta: [MASWE-0015] refs: - https://developer.android.com/about/versions/12/behavior-changes-all#bouncy-castle - https://developer.android.com/reference/java/security/KeyStore - https://labs.withsecure.com/publications/how-secure-is-your-android-keystore-authentication -beta-coverage: [MASWE-0015] draft: description: | The app relies on deprecated APIs or functionality that are no longer maintained, may lack diff --git a/weaknesses/MASVS-CODE/MASWE-0047.md b/weaknesses/MASVS-CODE/MASWE-0047.md index 369f927..e376b8e 100644 --- a/weaknesses/MASVS-CODE/MASWE-0047.md +++ b/weaknesses/MASVS-CODE/MASWE-0047.md @@ -11,13 +11,12 @@ mappings: cwe: [287, 326, 327, 1240] android-risks: - https://developer.android.com/privacy-and-security/risks/bad-dns - + maswe-beta: [MASWE-0019, MASWE-0032, MASWE-0049] refs: - https://developer.android.com/privacy-and-security/security-tips#Credentials - https://developer.apple.com/documentation/security/password_autofill - https://developer.android.com/privacy-and-security/cryptography#crypto_provider - https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf?__blob=publicationFile -beta-coverage: [MASWE-0019, MASWE-0032, MASWE-0049] draft: description: | Security-critical functionality (cryptography, networking/TLS, DNS, and authentication) should diff --git a/weaknesses/MASVS-CODE/MASWE-0048.md b/weaknesses/MASVS-CODE/MASWE-0048.md index d371cc9..6d62abd 100644 --- a/weaknesses/MASVS-CODE/MASWE-0048.md +++ b/weaknesses/MASVS-CODE/MASWE-0048.md @@ -17,13 +17,12 @@ mappings: - https://developer.android.com/privacy-and-security/risks/xml-external-entities-injection - https://developer.android.com/privacy-and-security/risks/untrustworthy-contentprovider-provided-filename - https://developer.android.com/privacy-and-security/risks/use-of-native-code - + maswe-beta: [MASWE-0079, MASWE-0080, MASWE-0081, MASWE-0082, MASWE-0083, MASWE-0084, MASWE-0086, MASWE-0087, MASWE-0088] refs: - https://developer.android.com/topic/security/risks/path-traversal - https://developer.android.com/topic/security/risks/sql-injection - https://developer.android.com/privacy-and-security/risks/unsafe-deserialization - https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html -beta-coverage: [MASWE-0079, MASWE-0080, MASWE-0081, MASWE-0082, MASWE-0083, MASWE-0084, MASWE-0086, MASWE-0087, MASWE-0088] draft: description: | Any data that originates outside the app's trust boundary must be treated as untrusted and diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0007.md b/weaknesses/MASVS-CRYPTO/MASWE-0007.md index cb87f14..2f19acb 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0007.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0007.md @@ -11,6 +11,7 @@ mappings: cwe: [331, 337, 338, 522] android-risks: - https://developer.android.com/privacy-and-security/risks/weak-prng + maswe-beta: [MASWE-0009, MASWE-0017] refs: - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf @@ -19,7 +20,6 @@ refs: - https://developer.android.com/reference/javax/crypto/KeyGenerator - https://developer.android.com/reference/kotlin/android/security/keystore/KeyProtection - https://developer.apple.com/documentation/cryptokit/aes/keywrap -beta-coverage: [MASWE-0009, MASWE-0017] status: new --- diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0008.md b/weaknesses/MASVS-CRYPTO/MASWE-0008.md index 9d5b3b8..26ac125 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0008.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0008.md @@ -9,12 +9,11 @@ mappings: masvs-v1: [MSTG-CRYPTO-2] masvs-v2: [MASVS-CRYPTO-2] cwe: [326, 327, 916] - + maswe-beta: [MASWE-0010] refs: - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-132.pdf - https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html -beta-coverage: [MASWE-0010] draft: description: | Cryptographic keys are frequently derived from passwords, passphrases, or other diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0009.md b/weaknesses/MASVS-CRYPTO/MASWE-0009.md index 3eb782b..96402d0 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0009.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0009.md @@ -8,11 +8,10 @@ profiles: [L2] mappings: masvs-v2: [MASVS-CRYPTO-2] cwe: [262, 324] - + maswe-beta: [MASWE-0011] refs: - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf - https://developers.google.com/tink/managing-key-rotation -beta-coverage: [MASWE-0011] draft: description: | Cryptographic keys have a limited cryptoperiod after which they should be retired and diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0010.md b/weaknesses/MASVS-CRYPTO/MASWE-0010.md index 87ec72c..8037ab3 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0010.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0010.md @@ -8,7 +8,7 @@ profiles: [L2] mappings: masvs-v2: [MASVS-CRYPTO-2, MASVS-AUTH-2, MASVS-AUTH-3] cwe: [284] - + maswe-beta: [MASWE-0018] refs: - https://developer.android.com/reference/android/security/keystore/KeyGenParameterSpec.Builder#setUnlockedDeviceRequired(boolean) - https://developer.apple.com/documentation/security/ksecattraccessiblewhenunlockedthisdeviceonly @@ -16,7 +16,6 @@ refs: - https://developer.apple.com/documentation/security/restricting-keychain-item-accessibility - https://source.android.com/docs/security/features/keystore/strongbox - https://developer.apple.com/documentation/security/ksecattrtokenidsecureenclave -beta-coverage: [MASWE-0018] draft: description: Ensuring that cryptographic keys are accessible only under strict conditions, such as when the device is unlocked by an authenticated user, within secure application diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0011.md b/weaknesses/MASVS-CRYPTO/MASWE-0011.md index aed7f8a..4650bc5 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0011.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0011.md @@ -11,7 +11,7 @@ mappings: cwe: [208, 323, 325, 326, 327, 329, 780] android-risks: - https://developer.android.com/privacy-and-security/risks/broken-cryptographic-algorithm - + maswe-beta: [MASWE-0020, MASWE-0012, MASWE-0022, MASWE-0023] refs: - https://support.google.com/faqs/answer/10046138?hl=en - https://support.google.com/faqs/answer/9450925?hl=en @@ -20,7 +20,6 @@ refs: - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Br2.pdf - https://www.usenix.org/legacy/event/woot10/tech/full_papers/Rizzo.pdf -beta-coverage: [MASWE-0020, MASWE-0012, MASWE-0022, MASWE-0023] status: new --- diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0012.md b/weaknesses/MASVS-CRYPTO/MASWE-0012.md index 9425689..676e3d5 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0012.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0012.md @@ -9,13 +9,12 @@ mappings: masvs-v1: [MSTG-CRYPTO-4] masvs-v2: [MASVS-CRYPTO-1] cwe: [328] - + maswe-beta: [MASWE-0021] refs: - https://developer.android.com/privacy-and-security/cryptography#deprecated-functionality - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf - https://en.wikipedia.org/wiki/Collision_attack - https://csrc.nist.gov/pubs/ir/8547/ipd -beta-coverage: [MASWE-0021] draft: description: | Using broken or unsuitable hash functions in a security-sensitive context can diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0013.md b/weaknesses/MASVS-CRYPTO/MASWE-0013.md index 373306d..18219da 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0013.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0013.md @@ -9,7 +9,7 @@ mappings: masvs-v1: [MSTG-CRYPTO-4, MSTG-CRYPTO-5] masvs-v2: [MASVS-CRYPTO-1, MASVS-CRYPTO-2] cwe: [323, 327, 807, 915] - + maswe-beta: [MASWE-0024, MASWE-0012] refs: - https://developer.android.com/privacy-and-security/cryptography#deprecated-functionality - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf @@ -17,7 +17,6 @@ refs: - https://datatracker.ietf.org/doc/html/rfc6151 - https://web.archive.org/web/20170810051504/http://www.tcs.hut.fi/old/papers/aura/aura-csfws97.pdf - https://en.wikipedia.org/wiki/Replay_attack -beta-coverage: [MASWE-0024, MASWE-0012] draft: description: | A Message Authentication Code (MAC) provides integrity and authenticity for a message using a diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0014.md b/weaknesses/MASVS-CRYPTO/MASWE-0014.md index 1fc49a0..40611dc 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0014.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0014.md @@ -9,13 +9,12 @@ mappings: masvs-v1: [MSTG-CRYPTO-4, MSTG-CRYPTO-5] masvs-v2: [MASVS-CRYPTO-1, MASVS-CRYPTO-2] cwe: [323, 327] - + maswe-beta: [MASWE-0025, MASWE-0012] refs: - https://developer.android.com/privacy-and-security/cryptography#deprecated-functionality - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf - https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf - https://csrc.nist.gov/pubs/ir/8547/ipd -beta-coverage: [MASWE-0025, MASWE-0012] draft: description: | Cryptographic signatures must be generated with algorithms and parameters of diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0015.md b/weaknesses/MASVS-CRYPTO/MASWE-0015.md index faab32b..bf9a262 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0015.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0015.md @@ -9,11 +9,10 @@ mappings: masvs-v1: [MSTG-CRYPTO-4] masvs-v2: [MASVS-CRYPTO-1] cwe: [347] - + maswe-beta: [MASWE-0026] refs: - https://cwe.mitre.org/data/definitions/347.html - https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf -beta-coverage: [MASWE-0026] draft: description: | Cryptographic signature verification must be implemented correctly to guarantee the diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0016.md b/weaknesses/MASVS-CRYPTO/MASWE-0016.md index afea995..fbe332c 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0016.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0016.md @@ -11,13 +11,13 @@ mappings: cwe: [332, 337, 338] android-risks: - https://developer.android.com/privacy-and-security/risks/weak-prng + maswe-beta: [MASWE-0027] observed_examples: - https://nvd.nist.gov/vuln/detail/CVE-2013-6386 - https://nvd.nist.gov/vuln/detail/CVE-2013-6386 - https://nvd.nist.gov/vuln/detail/CVE-2006-3419 - https://nvd.nist.gov/vuln/detail/CVE-2008-4102 - https://www.zellic.io/blog/proton-dart-flutter-csprng-prng/ -beta-coverage: [MASWE-0027] status: new --- diff --git a/weaknesses/MASVS-NETWORK/MASWE-0025.md b/weaknesses/MASVS-NETWORK/MASWE-0025.md index 0c1f5c6..635326e 100644 --- a/weaknesses/MASVS-NETWORK/MASWE-0025.md +++ b/weaknesses/MASVS-NETWORK/MASWE-0025.md @@ -13,7 +13,7 @@ mappings: - https://developer.android.com/privacy-and-security/risks/cleartext-communications - https://developer.android.com/privacy-and-security/risks/insecure-machine-to-machine android-core-app-quality: [SC-9, SC-N1, SC-N2] -beta-coverage: [MASWE-0050, MASWE-0037, MASWE-0048] + maswe-beta: [MASWE-0050, MASWE-0037, MASWE-0048] refs: - https://developer.apple.com/documentation/security/preventing-insecure-network-connections - https://developer.apple.com/documentation/bundleresources/information_property_list/nsapptransportsecurity/nsexceptiondomains diff --git a/weaknesses/MASVS-NETWORK/MASWE-0026.md b/weaknesses/MASVS-NETWORK/MASWE-0026.md index d458811..cf8e241 100644 --- a/weaknesses/MASVS-NETWORK/MASWE-0026.md +++ b/weaknesses/MASVS-NETWORK/MASWE-0026.md @@ -12,6 +12,7 @@ mappings: android-risks: - https://developer.android.com/privacy-and-security/risks/unsafe-trustmanager - https://developer.android.com/privacy-and-security/risks/unsafe-hostname + maswe-beta: [MASWE-0052] refs: - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf#page=17 - https://developer.android.com/privacy-and-security/security-ssl#tls-1.3-enabled-by-default @@ -23,7 +24,6 @@ refs: - https://developer.apple.com/forums/thread/707320 - https://support.apple.com/en-us/102390 - https://developer.apple.com/documentation/foundation/performing-manual-server-trust-authentication -beta-coverage: [MASWE-0052] status: new --- diff --git a/weaknesses/MASVS-NETWORK/MASWE-0027.md b/weaknesses/MASVS-NETWORK/MASWE-0027.md index c9ad7ca..45226de 100644 --- a/weaknesses/MASVS-NETWORK/MASWE-0027.md +++ b/weaknesses/MASVS-NETWORK/MASWE-0027.md @@ -9,7 +9,7 @@ mappings: masvs-v1: [MSTG-NETWORK-4] masvs-v2: [MASVS-NETWORK-2] cwe: [295] -beta-coverage: [MASWE-0047] + maswe-beta: [MASWE-0047] status: new --- diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0028.md b/weaknesses/MASVS-PLATFORM/MASWE-0028.md index 5826927..9746d9f 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0028.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0028.md @@ -9,8 +9,7 @@ mappings: masvs-v1: [MSTG-STORAGE-7] masvs-v2: [MASVS-PLATFORM-3, MASVS-STORAGE-2] cwe: [200, 359] - -beta-coverage: [MASWE-0053] + maswe-beta: [MASWE-0053] draft: description: | Sensitive data such as passwords, PINs, card numbers, or other PII may be exposed diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0029.md b/weaknesses/MASVS-PLATFORM/MASWE-0029.md index 7917682..b765183 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0029.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0029.md @@ -8,8 +8,7 @@ profiles: [L2] mappings: masvs-v2: [MASVS-PLATFORM-3, MASVS-STORAGE-2] cwe: [200, 359] - -beta-coverage: [MASWE-0054] + maswe-beta: [MASWE-0054] draft: description: | Apps may place sensitive data (e.g. OTPs, message contents, account details) into diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0030.md b/weaknesses/MASVS-PLATFORM/MASWE-0030.md index 88cbd4e..68ba916 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0030.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0030.md @@ -9,10 +9,9 @@ mappings: masvs-v1: [MSTG-STORAGE-9] masvs-v2: [MASVS-PLATFORM-3, MASVS-STORAGE-2] cwe: [200, 359] - + maswe-beta: [MASWE-0055] refs: - https://developer.android.com/about/versions/14/features/screenshot-detection -beta-coverage: [MASWE-0055] status: new --- diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0031.md b/weaknesses/MASVS-PLATFORM/MASWE-0031.md index 047bf5a..2442586 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0031.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0031.md @@ -11,10 +11,9 @@ mappings: cwe: [1021] android-risks: - https://developer.android.com/privacy-and-security/risks/tapjacking - + maswe-beta: [MASWE-0056] refs: - https://developer.android.com/topic/security/risks/tapjacking -beta-coverage: [MASWE-0056] draft: description: | Overlay attacks occur when a malicious app (or an attacker-controlled window) draws content diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0032.md b/weaknesses/MASVS-PLATFORM/MASWE-0032.md index 6301c35..a8fdb1f 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0032.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0032.md @@ -11,7 +11,7 @@ mappings: cwe: [939, 917] android-risks: - https://developer.android.com/privacy-and-security/risks/unsafe-use-of-deeplinks - + maswe-beta: [MASWE-0058] draft: description: | Deep links (Android App Links and custom URL schemes, iOS Universal Links and custom schemes) let @@ -27,7 +27,6 @@ draft: - validating and sanitizing the deep-link URL and its parameters - injection via unsanitized deep-link parameters (CWE-917 / CWE-939) - platform/OS-version differences in deep-link security -beta-coverage: [MASWE-0058] refs: - https://developer.apple.com/documentation/technotes/tn3155-debugging-universal-links status: placeholder diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0033.md b/weaknesses/MASVS-PLATFORM/MASWE-0033.md index e8b7e58..044317b 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0033.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0033.md @@ -10,11 +10,10 @@ mappings: cwe: [200, 668] android-risks: - https://developer.android.com/privacy-and-security/risks/secure-clipboard-handling - + maswe-beta: [MASWE-0059] refs: - https://developer.android.com/develop/ui/views/touch-and-input/copy-paste#PreventingSensitiveData - https://developer.apple.com/documentation/uikit/uipasteboard -beta-coverage: [MASWE-0059] draft: description: | The system clipboard is a shared resource: any app (and, on some platforms, nearby devices diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0034.md b/weaknesses/MASVS-PLATFORM/MASWE-0034.md index c807a5a..a786e42 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0034.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0034.md @@ -9,8 +9,7 @@ mappings: masvs-v1: [MSTG-PLATFORM-11] masvs-v2: [MASVS-PLATFORM-1, MASVS-STORAGE-2] cwe: [200] - -beta-coverage: [MASWE-0061] + maswe-beta: [MASWE-0061] draft: description: | On iOS, app extensions (e.g. custom keyboards, share and action extensions) run third-party code diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0035.md b/weaknesses/MASVS-PLATFORM/MASWE-0035.md index 096d2ab..cfc3d00 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0035.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0035.md @@ -14,7 +14,7 @@ mappings: - https://developer.android.com/privacy-and-security/risks/pending-intent - https://developer.android.com/privacy-and-security/risks/sender-of-pending-intents - https://developer.android.com/privacy-and-security/risks/sticky-broadcast - + maswe-beta: [MASWE-0066] refs: - https://support.google.com/faqs/answer/9267555?hl=en - https://developer.android.com/privacy-and-security/security-tips#intents @@ -22,7 +22,6 @@ refs: - https://developer.android.com/topic/security/risks/implicit-intent-hijacking - https://developer.android.com/topic/security/risks/pending-intent - https://developer.android.com/topic/security/risks/sticky-broadcast -beta-coverage: [MASWE-0066] draft: description: | This weakness covers everything related to the insecure handling of Android Intents, e.g. diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0036.md b/weaknesses/MASVS-PLATFORM/MASWE-0036.md index bf7208a..07f04ee 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0036.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0036.md @@ -11,10 +11,9 @@ mappings: cwe: [749, 94] android-risks: - https://developer.android.com/privacy-and-security/risks/insecure-webview-native-bridges - + maswe-beta: [MASWE-0068] refs: - https://support.google.com/faqs/answer/9095419 -beta-coverage: [MASWE-0068] draft: description: | WebViews can expose native/sensitive functionality to the web content they render, most diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0037.md b/weaknesses/MASVS-PLATFORM/MASWE-0037.md index 7e9629d..2c9924d 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0037.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0037.md @@ -11,10 +11,9 @@ mappings: cwe: [22, 79, 200, 669] android-risks: - https://developer.android.com/privacy-and-security/risks/webview-unsafe-file-inclusion - + maswe-beta: [MASWE-0069, MASWE-0073] refs: - https://blog.oversecured.com/Android-Exploring-vulnerabilities-in-WebResourceResponse/ -beta-coverage: [MASWE-0069, MASWE-0073] draft: description: | When a WebView is configured to access local resources (e.g. `setAllowFileAccessFromFileURLs`, diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0038.md b/weaknesses/MASVS-PLATFORM/MASWE-0038.md index 626f2a3..70352e3 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0038.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0038.md @@ -11,10 +11,9 @@ mappings: android-risks: - https://developer.android.com/privacy-and-security/risks/cross-app-scripting - https://developer.android.com/privacy-and-security/risks/unsafe-uri-loading - + maswe-beta: [MASWE-0071, MASWE-0070, MASWE-0072] refs: - https://blog.oversecured.com/Evernote-Universal-XSS-theft-of-all-cookies-from-all-sites-and-more/ -beta-coverage: [MASWE-0071, MASWE-0070, MASWE-0072] draft: description: | WebView objects shouldn't load URLs, HTML, or JavaScript from untrusted sources, and the app diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0065.md b/weaknesses/MASVS-PRIVACY/MASWE-0065.md index 85e7b92..7bea17d 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0065.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0065.md @@ -9,6 +9,7 @@ mappings: masvs-v1: [] masvs-v2: [MASVS-PRIVACY-2] cwe: [359] + maswe-beta: [MASWE-0109] refs: - https://cloud.google.com/sensitive-data-protection/docs/classification-redaction - https://gdpr-info.eu/recitals/no-26/ @@ -16,7 +17,6 @@ refs: - https://gdpr-info.eu/art-4-gdpr/ - https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2014/wp216_en.pdf - https://www.statista.com/topics/9460/app-tracking-and-mobile-privacy/ -beta-coverage: [MASWE-0109] status: new --- diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0066.md b/weaknesses/MASVS-PRIVACY/MASWE-0066.md index f0a6c0c..fc1a7c0 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0066.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0066.md @@ -9,6 +9,7 @@ mappings: masvs-v1: [] masvs-v2: [MASVS-PRIVACY-2] cwe: [359] + maswe-beta: [MASWE-0110] refs: - https://developer.android.com/reference/android/provider/Settings.Secure#ANDROID_ID - https://developer.android.com/privacy-and-security/about#resettable-identifiers @@ -24,7 +25,6 @@ refs: - https://developer.apple.com/app-store/ad-attribution/ - https://developer.apple.com/documentation/adattributionkit - https://gdpr-info.eu/recitals/no-30/ -beta-coverage: [MASWE-0110] status: new --- diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0067.md b/weaknesses/MASVS-PRIVACY/MASWE-0067.md index 6adf7d3..bea9bfe 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0067.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0067.md @@ -9,11 +9,11 @@ mappings: masvs-v1: [MASVS-STORAGE-12] masvs-v2: [MASVS-PRIVACY-3] cwe: [359] + maswe-beta: [MASWE-0111] refs: - https://support.google.com/googleplay/android-developer/answer/9859455#privacy_policy - https://developer.apple.com/app-store/app-privacy-details/#privacy-links - https://developer.apple.com/app-store/review/guidelines/#5.1.1 -beta-coverage: [MASWE-0111] status: new --- diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0068.md b/weaknesses/MASVS-PRIVACY/MASWE-0068.md index 654e786..759f702 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0068.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0068.md @@ -9,6 +9,7 @@ mappings: masvs-v1: [MSTG-STORAGE-12, MSTG-NETWORK-1] masvs-v2: [MASVS-PRIVACY-3, MASVS-PRIVACY-1] cwe: [359] + maswe-beta: [MASWE-0112, MASWE-0108] refs: - https://support.apple.com/en-us/102188 - https://support.apple.com/kb/HT211970 @@ -19,7 +20,6 @@ refs: - https://support.google.com/googleplay/answer/11416267 - https://www.youtube.com/watch?v=J7TM0Yy0aTQ - https://www.youtube.com/watch?v=4rfF3y4xchU -beta-coverage: [MASWE-0112, MASWE-0108] status: new --- diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0069.md b/weaknesses/MASVS-PRIVACY/MASWE-0069.md index 0c144f6..f251b8b 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0069.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0069.md @@ -9,9 +9,9 @@ mappings: masvs-v1: [] masvs-v2: [MASVS-PRIVACY-4] cwe: [359] + maswe-beta: [MASWE-0113] refs: - https://developer.apple.com/app-store/app-privacy-details/#privacy-links -beta-coverage: [MASWE-0113] status: new --- diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0070.md b/weaknesses/MASVS-PRIVACY/MASWE-0070.md index 17d5f6c..af4ede8 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0070.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0070.md @@ -9,10 +9,10 @@ mappings: masvs-v1: [] masvs-v2: [MASVS-PRIVACY-4] cwe: [359] + maswe-beta: [MASWE-0114] refs: - https://firebase.google.com/support/privacy/storing-privacy-settings - https://www.researchgate.net/publication/335863205_Demystifying_Hidden_Privacy_Settings_in_Mobile_Apps -beta-coverage: [MASWE-0114] status: new --- diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0071.md b/weaknesses/MASVS-PRIVACY/MASWE-0071.md index eaf9fd3..672829d 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0071.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0071.md @@ -9,11 +9,11 @@ mappings: masvs-v1: [] masvs-v2: [MASVS-PRIVACY-4] cwe: [200, 285, 358, 359] + maswe-beta: [MASWE-0115, MASWE-0060] refs: - https://developer.apple.com/design/human-interface-guidelines/privacy#Requesting-permission - https://developer.apple.com/documentation/uikit/protecting_the_user_s_privacy/requesting_access_to_protected_resources - https://developer.android.com/training/permissions/requesting#explain -beta-coverage: [MASWE-0115, MASWE-0060] status: new --- diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0072.md b/weaknesses/MASVS-PRIVACY/MASWE-0072.md index 986caf2..8822656 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0072.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0072.md @@ -9,6 +9,7 @@ mappings: masvs-v1: [] masvs-v2: [MASVS-PRIVACY-1] cwe: [250] + maswe-beta: [MASWE-0117] refs: - https://developer.apple.com/design/human-interface-guidelines/privacy#Requesting-permission - https://developer.apple.com/documentation/uikit/protecting_the_user_s_privacy/requesting_access_to_protected_resources @@ -20,7 +21,6 @@ refs: - https://arxiv.org/pdf/2203.10583 - https://ieeexplore.ieee.org/document/9001128 - https://www.enisa.europa.eu/sites/default/files/publications/WP2017%20O-2-2-4%20GDPR%20Mobile.pdf -beta-coverage: [MASWE-0117] status: new --- diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0073.md b/weaknesses/MASVS-PRIVACY/MASWE-0073.md index 265c0c3..f6a88c9 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0073.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0073.md @@ -9,12 +9,12 @@ mappings: masvs-v1: [] masvs-v2: [MASVS-PRIVACY-3] cwe: [359] + maswe-beta: [MASWE-0108] refs: - https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api - https://developer.apple.com/documentation/bundleresources/privacy_manifest_files - https://developer.apple.com/app-store/app-privacy-details/#user-tracking - https://developer.apple.com/documentation/apptrackingtransparency/ -beta-coverage: [MASWE-0108] draft: description: | Platforms increasingly require apps to declare the domains they use for tracking so the diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0049.md b/weaknesses/MASVS-RESILIENCE/MASWE-0049.md index ddfee82..7bd8fc3 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0049.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0049.md @@ -8,7 +8,7 @@ profiles: [L2] mappings: masvs-v1: [MSTG-STORAGE-11] masvs-v2: [MASVS-RESILIENCE-1] - + maswe-beta: [MASWE-0008] refs: - https://developer.apple.com/documentation/localauthentication/logging_a_user_into_your_app_with_face_id_or_touch_id - https://grep.app/search?q=isdevicesecure%28&filter[repo][0]=threema-ch/threema-android @@ -24,7 +24,6 @@ draft: - user set a device passcode via `isDeviceSecure()` on Android better than only ensuring that the secure screen lock is set via `KeyguardManager.isKeyguardSecure()` - before attempting to authenticate, test to make sure that you actually have the ability to do so by calling the `LAContext.canEvaluatePolicy(_:error:)` method on iOS - to make sure that biometrics can be used, verify that the `kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly` or the `kSecAttrAccessibleWhenPasscodeSet` protection class is set when the `SecAccessControlCreateWithFlags` method is called -beta-coverage: [MASWE-0008] status: placeholder --- diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0050.md b/weaknesses/MASVS-RESILIENCE/MASWE-0050.md index 23873df..18919da 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0050.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0050.md @@ -11,12 +11,11 @@ mappings: android-risks: - https://developer.android.com/privacy-and-security/risks/android-debuggable cwe: [489] - + maswe-beta: [MASWE-0067, MASWE-0074] refs: - https://developer.android.com/guide/topics/manifest/application-element - https://developer.android.com/reference/android/webkit/WebView#setWebContentsDebuggingEnabled(boolean) - https://developer.apple.com/documentation/webkit/wkwebview/4111163-isinspectable -beta-coverage: [MASWE-0067, MASWE-0074] status: new --- diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0051.md b/weaknesses/MASVS-RESILIENCE/MASWE-0051.md index 06e8bf0..df45894 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0051.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0051.md @@ -9,8 +9,7 @@ mappings: masvs-v1: [MSTG-RESILIENCE-9] masvs-v2: [MASVS-RESILIENCE-3] cwe: [693] - -beta-coverage: [MASWE-0089, MASWE-0092] + maswe-beta: [MASWE-0089, MASWE-0092] draft: description: The app's code doesn’t implement effective obfuscation techniques to protect against reverse engineering and static analysis (CWE-693), e.g. polymorphic obfuscation, method-inlining, insertion of opaque predicates, instruction substitution, and instruction block chopping. This also covers failing to hinder static analysis tools from decompiling the app ("static damage control"). topics: diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0052.md b/weaknesses/MASVS-RESILIENCE/MASWE-0052.md index f737b7b..5624661 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0052.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0052.md @@ -9,8 +9,7 @@ mappings: masvs-v1: [MSTG-RESILIENCE-11] masvs-v2: [MASVS-RESILIENCE-3] cwe: [693] - -beta-coverage: [MASWE-0090] + maswe-beta: [MASWE-0090] draft: description: | Beyond code, an app's resources and assets (e.g. strings, layouts, images, configuration, and diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0053.md b/weaknesses/MASVS-RESILIENCE/MASWE-0053.md index 1c38553..4f459bb 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0053.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0053.md @@ -9,8 +9,7 @@ mappings: masvs-v1: [MSTG-RESILIENCE-12] masvs-v2: [MASVS-RESILIENCE-3] cwe: [693] - -beta-coverage: [MASWE-0091] + maswe-beta: [MASWE-0091] draft: description: | Obfuscation alone can be undone by automated deobfuscation and static-analysis tooling. This diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0054.md b/weaknesses/MASVS-RESILIENCE/MASWE-0054.md index 3cf763e..a174e4f 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0054.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0054.md @@ -11,8 +11,7 @@ mappings: cwe: [489, 497, 540, 912, 1295] android-risks: - https://developer.android.com/privacy-and-security/risks/test-debug - -beta-coverage: [MASWE-0094, MASWE-0093, MASWE-0095] + maswe-beta: [MASWE-0094, MASWE-0093, MASWE-0095] draft: description: | The app contains developer debug artifacts that should not be present in production builds. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0055.md b/weaknesses/MASVS-RESILIENCE/MASWE-0055.md index 495cfa2..4be183d 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0055.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0055.md @@ -9,8 +9,7 @@ mappings: masvs-v1: [MSTG-RESILIENCE-13] masvs-v2: [MASVS-RESILIENCE-3, MASVS-NETWORK-1] cwe: [319] - -beta-coverage: [MASWE-0096] + maswe-beta: [MASWE-0096] draft: description: | The app does not apply an additional layer of application-level (payload / end-to-end) diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0056.md b/weaknesses/MASVS-RESILIENCE/MASWE-0056.md index f0a668d..06fc01d 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0056.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0056.md @@ -9,8 +9,7 @@ mappings: masvs-v1: [MSTG-RESILIENCE-1, MSTG-RESILIENCE-8] masvs-v2: [MASVS-RESILIENCE-1, MASVS-RESILIENCE-4] cwe: [693] - -beta-coverage: [MASWE-0097, MASWE-0103] + maswe-beta: [MASWE-0097, MASWE-0103] draft: description: no root/jailbreak detection implemented e.g. check for Cydia, SuperSU, Magisk, Xposed, etc. The app does not implement effective techniques to detect if the device is rooted or jailbroken (CWE-693). More broadly, the app should apply Runtime Application Self-Protection (RASP) techniques that detect a compromised environment and trigger appropriate responses. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0057.md b/weaknesses/MASVS-RESILIENCE/MASWE-0057.md index 0d5153c..ab0e917 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0057.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0057.md @@ -8,8 +8,7 @@ profiles: [R] mappings: masvs-v2: [MASVS-RESILIENCE-1] cwe: [693] - -beta-coverage: [MASWE-0098] + maswe-beta: [MASWE-0098] draft: description: | App virtualization/cloning frameworks (and "dual-app" containers) run an app inside another app's diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0058.md b/weaknesses/MASVS-RESILIENCE/MASWE-0058.md index cdfb0f8..30eea86 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0058.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0058.md @@ -9,8 +9,7 @@ mappings: masvs-v1: [MSTG-RESILIENCE-5, MSTG-RESILIENCE-8] masvs-v2: [MASVS-RESILIENCE-1, MASVS-RESILIENCE-4] cwe: [693] - -beta-coverage: [MASWE-0099, MASWE-0103] + maswe-beta: [MASWE-0099, MASWE-0103] draft: description: The app's code doesn’t implement effective techniques to detect if it is running in an emulator (CWE-693), e.g. identifying features and limitations available for commonly used emulation solutions. More broadly, the app should apply Runtime Application Self-Protection (RASP) techniques that detect a compromised environment and trigger appropriate responses. topics: diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0059.md b/weaknesses/MASVS-RESILIENCE/MASWE-0059.md index 0c99a69..653f680 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0059.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0059.md @@ -9,7 +9,7 @@ mappings: masvs-v1: [MSTG-RESILIENCE-10] masvs-v2: [MASVS-RESILIENCE-1] cwe: [693] - + maswe-beta: [MASWE-0100] refs: - https://developer.android.com/google/play/integrity - https://support.google.com/googleplay/android-developer/answer/11395166?hl=en @@ -20,7 +20,6 @@ refs: - https://github.com/iansampson/AppAttest - https://github.com/firebase/firebase-ios-sdk/blob/v8.15.0/FirebaseAppCheck/Sources/AppAttestProvider/DCAppAttestService%2BFIRAppAttestService.h - https://blog.restlesslabs.com/john/ios-app-attest -beta-coverage: [MASWE-0100] draft: description: | Device attestation lets the backend gain assurance about the integrity of the device and platform diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0060.md b/weaknesses/MASVS-RESILIENCE/MASWE-0060.md index 340085f..94686eb 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0060.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0060.md @@ -9,8 +9,7 @@ mappings: masvs-v1: [MSTG-RESILIENCE-2] masvs-v2: [MASVS-RESILIENCE-4] cwe: [693] - -beta-coverage: [MASWE-0101] + maswe-beta: [MASWE-0101] draft: description: | A debugger attached to the running app lets an attacker inspect memory, set breakpoints, and alter diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0061.md b/weaknesses/MASVS-RESILIENCE/MASWE-0061.md index 56ccbd3..a008a56 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0061.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0061.md @@ -9,8 +9,7 @@ mappings: masvs-v1: [MSTG-RESILIENCE-4] masvs-v2: [MASVS-RESILIENCE-4] cwe: [693] - -beta-coverage: [MASWE-0102] + maswe-beta: [MASWE-0102] draft: description: | Dynamic instrumentation and hooking frameworks let an attacker observe and modify the app at diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0062.md b/weaknesses/MASVS-RESILIENCE/MASWE-0062.md index b733b9f..18be328 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0062.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0062.md @@ -9,11 +9,10 @@ mappings: masvs-v1: [MSTG-CODE-1] masvs-v2: [MASVS-RESILIENCE-2] cwe: [347, 693] - + maswe-beta: [MASWE-0104, MASWE-0106] refs: - https://developer.apple.com/documentation/xcode/using-the-latest-code-signature-format - https://developer.apple.com/documentation/devicecheck/preparing-to-use-the-app-attest-service -beta-coverage: [MASWE-0104, MASWE-0106] draft: description: | The app does not attest its own authenticity/integrity, i.e. it doesn't implement effective diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0063.md b/weaknesses/MASVS-RESILIENCE/MASWE-0063.md index f764aa6..2a938e8 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0063.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0063.md @@ -9,8 +9,7 @@ mappings: masvs-v1: [MSTG-RESILIENCE-3] masvs-v2: [MASVS-RESILIENCE-2, MASVS-CODE-4] cwe: [693] - -beta-coverage: [MASWE-0105] + maswe-beta: [MASWE-0105] draft: description: | Beyond executable code, an app relies on resources and assets whose integrity should be verified, diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0064.md b/weaknesses/MASVS-RESILIENCE/MASWE-0064.md index 70abe46..4f738b0 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0064.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0064.md @@ -9,8 +9,7 @@ mappings: masvs-v1: [MSTG-RESILIENCE-6] masvs-v2: [MASVS-RESILIENCE-2] cwe: [693] - -beta-coverage: [MASWE-0107] + maswe-beta: [MASWE-0107] draft: description: | An app's executable code can be modified at runtime through in-memory patching, code injection, or diff --git a/weaknesses/MASVS-STORAGE/MASWE-0001.md b/weaknesses/MASVS-STORAGE/MASWE-0001.md index ea66588..bf230bd 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0001.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0001.md @@ -11,9 +11,9 @@ mappings: cwe: [209, 359, 497, 532] android-risks: - https://developer.android.com/privacy-and-security/risks/log-info-disclosure + maswe-beta: [MASWE-0001] refs: - https://stackoverflow.com/questions/45270547/is-read-logs-a-normal-or-dangerous-android-permission -beta-coverage: [MASWE-0001] status: new --- diff --git a/weaknesses/MASVS-STORAGE/MASWE-0002.md b/weaknesses/MASVS-STORAGE/MASWE-0002.md index 3313417..1c38422 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0002.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0002.md @@ -11,12 +11,11 @@ mappings: cwe: [212, 313] android-risks: - https://developer.android.com/privacy-and-security/risks/backup-best-practices - + maswe-beta: [MASWE-0004, MASWE-0003] refs: - https://developer.android.com/guide/topics/data/autobackup#include-exclude-android-11 - https://developer.android.com/guide/topics/data/autobackup#include-exclude-android-12 - https://developer.android.com/guide/topics/data/autobackup#define-device-conditions -beta-coverage: [MASWE-0004, MASWE-0003] status: new --- diff --git a/weaknesses/MASVS-STORAGE/MASWE-0003.md b/weaknesses/MASVS-STORAGE/MASWE-0003.md index e1a8bcb..e2bd4b9 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0003.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0003.md @@ -12,11 +12,11 @@ mappings: cwe: [200, 284, 312, 313, 732, 922] android-risks: - https://developer.android.com/privacy-and-security/risks/file-providers + maswe-beta: [MASWE-0006, MASWE-0002, MASWE-0118] refs: - https://developer.apple.com/documentation/uikit/protecting_the_user_s_privacy/encrypting_your_app_s_files - https://developer.android.com/about/versions/nougat/android-7.0-changes#permfilesys - https://developer.android.com/privacy-and-security/security-tips#internal-storage -beta-coverage: [MASWE-0006, MASWE-0002, MASWE-0118] status: new --- diff --git a/weaknesses/MASVS-STORAGE/MASWE-0004.md b/weaknesses/MASVS-STORAGE/MASWE-0004.md index ef98ff5..87a585c 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0004.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0004.md @@ -12,7 +12,7 @@ mappings: cwe: [200, 284, 312, 313, 732, 921, 922] android-risks: - https://developer.android.com/privacy-and-security/risks/sensitive-data-external-storage -beta-coverage: [MASWE-0007, MASWE-0002] + maswe-beta: [MASWE-0007, MASWE-0002] status: new --- diff --git a/weaknesses/MASVS-STORAGE/MASWE-0005.md b/weaknesses/MASVS-STORAGE/MASWE-0005.md index 2f5faf6..d5d73ef 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0005.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0005.md @@ -11,12 +11,12 @@ mappings: cwe: [312, 318, 321, 322] android-risks: - https://developer.android.com/privacy-and-security/risks/hardcoded-cryptographic-secrets + maswe-beta: [MASWE-0013, MASWE-0014, MASWE-0016] refs: - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-175Br1.pdf - https://developer.android.com/privacy-and-security/keystore#ImportingEncryptedKeys - https://developer.apple.com/documentation/security/certificate_key_and_trust_services/keys/storing_keys_as_data -beta-coverage: [MASWE-0013, MASWE-0014, MASWE-0016] status: new --- diff --git a/weaknesses/MASVS-STORAGE/MASWE-0006.md b/weaknesses/MASVS-STORAGE/MASWE-0006.md index bae41d5..81583ff 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0006.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0006.md @@ -11,11 +11,11 @@ mappings: cwe: [312, 540, 798] android-risks: - https://developer.android.com/privacy-and-security/risks/insecure-api-usage + maswe-beta: [MASWE-0005, MASWE-0013, MASWE-0036] refs: - https://cloud.google.com/docs/authentication/api-keys#securing - https://cloud.google.com/docs/authentication/api-keys#api_key_restrictions - https://github.com/gitleaks/gitleaks -beta-coverage: [MASWE-0005, MASWE-0013, MASWE-0036] status: new --- From 42bc9cdddcfe8f338082af402d333a8b689c96a2 Mon Sep 17 00:00:00 2001 From: Carlos Holguera Date: Sun, 19 Jul 2026 20:21:47 +0200 Subject: [PATCH 08/70] Improve MASWE instructions and canonical attack paths, labels, and patterns --- .github/instructions/impact-attacks.yaml | 41 +++++++ .github/instructions/impact-labels.yaml | 9 ++ .github/instructions/impact-patterns.yaml | 10 ++ .github/instructions/maswe.instructions.md | 121 +++++++++++++++++---- weaknesses/MASVS-CODE/MASWE-0041.md | 32 +++--- weaknesses/MASVS-CRYPTO/MASWE-0007.md | 35 +++--- weaknesses/MASVS-CRYPTO/MASWE-0011.md | 38 ++++--- weaknesses/MASVS-CRYPTO/MASWE-0016.md | 38 ++++--- weaknesses/MASVS-NETWORK/MASWE-0025.md | 56 +++++----- weaknesses/MASVS-NETWORK/MASWE-0026.md | 50 +++++---- weaknesses/MASVS-NETWORK/MASWE-0027.md | 40 ++++--- weaknesses/MASVS-PLATFORM/MASWE-0030.md | 28 ++--- weaknesses/MASVS-PRIVACY/MASWE-0065.md | 24 ++-- weaknesses/MASVS-PRIVACY/MASWE-0066.md | 36 +++--- weaknesses/MASVS-PRIVACY/MASWE-0067.md | 27 +++-- weaknesses/MASVS-PRIVACY/MASWE-0068.md | 27 +++-- weaknesses/MASVS-PRIVACY/MASWE-0069.md | 23 ++-- weaknesses/MASVS-PRIVACY/MASWE-0070.md | 30 +++-- weaknesses/MASVS-PRIVACY/MASWE-0071.md | 27 +++-- weaknesses/MASVS-PRIVACY/MASWE-0072.md | 49 ++++----- weaknesses/MASVS-RESILIENCE/MASWE-0050.md | 31 ++++-- weaknesses/MASVS-STORAGE/MASWE-0001.md | 41 +++---- weaknesses/MASVS-STORAGE/MASWE-0002.md | 33 ++++-- weaknesses/MASVS-STORAGE/MASWE-0003.md | 47 ++++---- weaknesses/MASVS-STORAGE/MASWE-0004.md | 43 +++++--- weaknesses/MASVS-STORAGE/MASWE-0005.md | 27 +++-- weaknesses/MASVS-STORAGE/MASWE-0006.md | 47 ++++---- 27 files changed, 641 insertions(+), 369 deletions(-) create mode 100644 .github/instructions/impact-attacks.yaml create mode 100644 .github/instructions/impact-labels.yaml create mode 100644 .github/instructions/impact-patterns.yaml diff --git a/.github/instructions/impact-attacks.yaml b/.github/instructions/impact-attacks.yaml new file mode 100644 index 0000000..d3395f7 --- /dev/null +++ b/.github/instructions/impact-attacks.yaml @@ -0,0 +1,41 @@ +- Obtaining the app package and reverse engineering it. +- Debugging the app at runtime. +- Using dynamic instrumentation. +- Attaching a remote inspector to the app's debuggable web content. +- Accessing the device storage on a compromised device. +- Accessing the system logs on a compromised device or from an app holding log-access permissions. +- Accessing files exposed through incorrect file permissions or misconfigured content providers. +- Extracting local or cloud backups of the device. +- Tampering with backup contents and restoring the modified backup to a device. +- Accessing shared or external storage from any app holding the corresponding permissions. +- Physically removing and reading external storage media such as SD cards. +- Monitoring network traffic on the same network (e.g., public Wi-Fi or a compromised router). +- Monitoring local or proximity interfaces such as Bluetooth, NFC, or USB. +- Performing a Machine-in-the-Middle (MITM) attack, e.g., via ARP poisoning, DNS spoofing, or a rogue access point. +- Presenting a fraudulent or otherwise invalid certificate that the app accepts. +- Obtaining a valid certificate for the target domain from a compromised, coerced, or rogue Certificate Authority (CA). +- Installing an attacker-controlled CA certificate on a device they control to inspect the app's traffic. +- Brute-forcing cryptographic material generated with insufficient length. +- Predicting or reproducing values generated with insufficient entropy. +- Intercepting cryptographic keys exported in plaintext. +- Performing cryptanalysis of broken algorithms, modes, or parameters. +- Exploiting predictable or reused IVs or nonces to detect patterns or recover plaintext. +- Exploiting padding oracles exposed through observable error signals or timing differences. +- Observing enough outputs to recover the internal state of a non-cryptographic PRNG. +- Capturing or recording the screen from another app or an external tool. +- Accessing screenshots automatically taken by the system, e.g., when the app moves to the background. +- Identifying vulnerable dependency versions in the app package and using public advisories or exploits. +- Collecting and correlating identifiers and usage data across apps, devices, and services. +- Collecting non-resettable identifiers or misusing resettable ones. +- Linking directly identifiable data to real-world identities. +- Operating without a privacy policy or under a vague, generic, or inaccessible one. +- Deviating from the practices stated in the published privacy policy. +- Collecting or sharing data categories that are not declared in the platform's privacy labels. +- Transmitting undeclared identifiers or analytics data to first- or third-party services over the network. +- Providing no way for users to delete, export, modify, or opt out of the collection of their data. +- Making profile details, activity status, or discoverability visible to other users or third parties by default. +- Collecting data under consent that is bundled, implied, or otherwise not freely and specifically given. +- Continuing to collect data under an outdated consent after practices have changed. +- Exporting or sharing data through flows whose privacy consequences are not evident to the user. +- Holding excessive or no-longer-needed permissions granted to the app. +- Inheriting the app's permissions in third-party SDKs, whose data collection is difficult to audit and control. diff --git a/.github/instructions/impact-labels.yaml b/.github/instructions/impact-labels.yaml new file mode 100644 index 0000000..77fc3c0 --- /dev/null +++ b/.github/instructions/impact-labels.yaml @@ -0,0 +1,9 @@ +- Compromise of Sensitive Data +- Authentication or Authorization Bypass +- Bypass of Protection Mechanisms +- Execution of Unauthorized Code +- Financial Loss +- Compromise of System Integrity and Business Operations +- Violation of User Privacy +- Loss of User Trust +- Legal and Regulatory Non-Compliance diff --git a/.github/instructions/impact-patterns.yaml b/.github/instructions/impact-patterns.yaml new file mode 100644 index 0000000..a8c87f7 --- /dev/null +++ b/.github/instructions/impact-patterns.yaml @@ -0,0 +1,10 @@ +- Attackers can extract [...] by +- Attackers can obtain [...] while they are in use by +- Attackers can access [...] by +- Attackers can extract or tamper with [...] by +- Attackers can intercept or modify [...] by +- Attackers can predict or reproduce [...] by +- Attackers can decrypt or forge [...] by +- Attackers can inspect and manipulate [...] by +- Attackers can exploit [...] by +- Apps and embedded third-party components can [...] by diff --git a/.github/instructions/maswe.instructions.md b/.github/instructions/maswe.instructions.md index f7dbe08..b6a2830 100644 --- a/.github/instructions/maswe.instructions.md +++ b/.github/instructions/maswe.instructions.md @@ -47,12 +47,13 @@ Required fields: title: id: MASWE-XXXX alias: +requirement: "" platform: [android, ios] profiles: [L1, L2] mappings: - masvs-v1: [MSTG-- + masvs-v1: [MSTG--] masvs-v2: [MASVS--] - cwe:[CWE-ID, CWE-ID] + cwe: [CWE-ID, CWE-ID] android-risks: - If applicable refs: @@ -62,20 +63,27 @@ status: --- ``` +YAML style: do not quote list items unless required (`[android, ios]`, not `["android", "ios"]`). Keep the fields in the order shown above, with `status` last. + Field rules: - **title**: Noun phrase naming the weakness, not a sentence. No trailing period. Use title case. Avoid vendor names unless they are part of the standardized term (e.g. "Android KeyStore"). - **alias**: Short, lowercase, dash-separated version of the title. This is used for cross-referencing the weakness in MASTG content. It should be unique across all weaknesses. Examples: `weak-crypto-key-derivation`, `no-key-rotation`. +- **requirement**: A single sentence, in quotes, stating the positive security requirement that the app must fulfill (the inverse of the weakness). Example: `"The app encrypts all network traffic."` - **platform**: List of affected platforms. Use `[android, ios]` if the weakness applies to both. Use a single-item list if it is platform-specific (e.g. `[android]` for StrandHogg). - **profiles**: MAS Testing Profiles that the weakness is relevant for. Most weaknesses apply to `L1` and `L2`. Resilience weaknesses apply to `R` and Privacy to `P`. Use the current profile values defined in - **mappings**: Cross-references to related controls and weaknesses in other standards. At least one MASVS v2 control is required. Mappings to MASVS v1, CWE, and Android risks are optional but encouraged when applicable. - - **mappings.masvs-v1**: One or more MSTG v1 controls that covered this topic. This helps identify content to port from MASTG v1. - - **mappings.masvs-v2**: One or more MASVS v2 controls this weakness helps verify. At least one entry is required. + - **masvs-v1**: One or more MSTG v1 controls that covered this topic. This helps identify content to port from MASTG v1. + - **masvs-v2**: One or more MASVS v2 controls this weakness helps verify. At least one entry is required. + - **mastg-v1**: One or more MASTG v1 tests that covered this topic. Optional; helps identify content to port from MASTG v1. + - **maswe-beta**: One or more MASWE v0.x (pre-1.0.0-rc) weaknesses that this weakness supersedes or absorbs. This is optional but encouraged for traceability. - **cwe**: One or more CWE IDs that correspond to this weakness. This helps link to the broader software security ecosystem. - **android-risks**: One or more specific risks from the Android developer documentation (https://developer.android.com/privacy-and-security/risks) that correspond to this weakness. This is an optional field that can help link to Android-specific guidance, but it should only be used when there is a clear match + - **android-core-app-quality**: One or more security checklist IDs from the [Android Core App Quality guidelines](https://developer.android.com/docs/quality-guidelines/core-app-quality). Optional. + - **nist-ssdf**: One or more practice IDs from the [NIST Secure Software Development Framework (SP 800-218)](https://csrc.nist.gov/projects/ssdf). Optional. +- **observed_examples**: Links to public, real-world occurrences of the weakness (e.g. CVE entries or published research). Optional. - **refs**: External references. Prefer stable, vendor-neutral sources (official platform docs, CWE, NIST, academic papers). -- **status**: When you generate a new MASWE draft, set -`status: new`. +- **status**: When you generate a new MASWE draft, set `status: new`. Do not invent additional front matter fields. If you believe a new field is needed, open an issue first. @@ -88,9 +96,6 @@ Use exactly these top-level section headings, in this order, all at `##` level. 3. `## Impact` 4. `## Mitigations` -Some existing approved MASWEs order `## Impact` before -`## Modes of Introduction`. Prefer the order above for new content, but do not re-order existing approved pages in an unrelated PR. - ### `## Overview` - 2-5 short paragraphs in plain prose. @@ -103,24 +108,98 @@ materially differs. ### `## Modes of Introduction` - How the weakness gets introduced into an app. Typical causes: unsafe defaults, missing configuration, unsafe API usage, copy-pasted code, outdated libraries, insufficient input validation, misuse of platform features. -- Prefer a short bulleted list (3-5 bullets). -- Each bullet starts with a **bold short label** followed by a colon and then the explanation. For example: - `- **Hardcoded Keys**: Including cryptographic keys directly in the application code, making them susceptible to extraction through decompilation and reverse-engineering.` -- Each bullet describes a developer-facing cause, not a consequence. -- If the weakness can be introduced through a third-party SDK or cross-platform framework, call that out explicitly. +- They must reflect the testable aspects of the weakness, which is what developers introduced and can fix. Avoid describing the consequences of the weakness here. +- They must be **platform-agnostic** as much as possible. Only mention platform-specific details when it really matters to the introduction of the weakness or when the specific example is especially helpful to illustrate the weakness. + - It is ok to mention the Android Keystore or iOS Keychain as examples of secure storage. + - It is ok to mention Android's `SharedPreferences` or iOS's `UserDefaults` as examples of insecure storage. + - It is not ok to mention Android's `WebView` or iOS's `WKWebView` as examples of web content containers. Mentioning WebView is sufficient. +- Use a short bulleted list where each bullet starts with a **bold short label** followed by a colon and then the explanation. + +For example: + +- `**Hardcoded Keys**: Including cryptographic keys directly in the application code, making them susceptible to extraction through decompilation and reverse-engineering.` + - This should not contain the consequences (e.g. "making them susceptible to extraction through decompilation and reverse-engineering") — that belongs in the Impact section. Instead, it should describe how the weakness is introduced (e.g. "Including cryptographic keys directly in the application code"). ### `## Impact` -- What an attacker can do, or what the user loses, if the weakness is present. -- Short bulleted list (3-5 bullets). Each bullet starts with a **bold short label** followed by a colon and then the concrete outcome. For example: - `- **Loss of Confidentiality**: Sensitive information can be exposed, resulting in a loss of confidentiality. Once keys are exposed, all data encrypted with those keys is at risk.` -- Avoid vague risk labels. Each outcome should be specific and actionable. -- No CVSS numbers. Severity is context-dependent and cannot be universally assigned to a weakness. Instead, the impact section should provide enough detail for testers and developers to make their own informed severity assessments based on the specific app context. +The Impact section describes what attackers can achieve, how they can achieve it, and the consequences that may follow. + +Use these files. + +- `.github/instructions/impact-patterns.yaml`, reusable patterns for the opening sentence. +- `.github/instructions/impact-attacks.yaml`, reusable descriptions of attack paths. +- `.github/instructions/impact-labels.yaml`, canonical labels for consequences. + +Reuse the same language and terms across MASWEs whenever the outcome, attack path, or consequence is equivalent. + +#### Structure + +Start with the immediate outcome attackers can achieve, using a pattern from `impact-patterns.yaml`. + +```md +Attackers can [obtain, expose, modify, bypass, or disrupt something] by: +``` + +List all relevant attack paths, using wording from `impact-attacks.yaml` whenever applicable. + +```md +- [Attack path]. +- [Alternative attack path]. +``` + +Do not repeat consequences for each attack path when they are the same. + +Then add. + +```md +This can lead to: +``` + +List the consequences using this pattern. + +```md +- **[Canonical Impact Label]**: [Concrete attacker action or consequence], resulting in [specific harm]. +``` + +Each consequence must. + +- Use an exact label from `impact-labels.yaml`. +- Explain what attackers can do after achieving the stated outcome. +- Include a `resulting in` clause. +- Be specific to the affected user, app, service, or organization. +- Avoid unsupported, duplicate, or generic consequences. + +#### Example 1 + +```md +Attackers can extract hardcoded secrets, credentials, and internal information by: + +- Obtaining the app package and reverse engineering it. + +This can lead to: + +- **Financial Loss**: Attackers can abuse compromised API keys to make unauthorized billed API calls, resulting in unexpected charges to the app owner. +- **Compromise of System Integrity and Business Operations**: Attackers can use extracted credentials to access backend services, resulting in service disruption, account suspension, or denial of service. +``` + +#### Example 2 + +```md +Attackers can obtain cryptographic keys while they are in use by: + +- Using a debugger. +- Using dynamic instrumentation. +- Accessing the device storage on a compromised device. + +This can lead to: + +- **Compromise of Sensitive Data**: Attackers can decrypt protected information or forge encrypted data, resulting in unauthorized disclosure or modification of sensitive data. +- **Authentication or Authorization Bypass**: Attackers can create valid cryptographic values or impersonate trusted parties, resulting in unauthorized access to protected accounts, data, or functionality. +``` ### `## Mitigations` - What developers must do to prevent or reduce the impact of the weakness. +- Mitigations typically correspond to the modes of introduction. Each mitigation should be actionable and specific, providing clear guidance on how to address the weakness. - Short bulleted list. Each bullet starts with a **bold short label** followed by a colon and then an imperative sentence addressed to the developer. For example: `- **Use Platform Keystores**: Where possible, generate cryptographic keys dynamically on the device, rather than using predefined keys, and ensure that they are securely stored after creation.` -- When a mitigation is fully captured by a MASTG-BEST entry, link to it with `@MASTG-BEST-XXXX` and keep the bullet short. Do not duplicate the content of the best practice. -- Do not include testing steps here. diff --git a/weaknesses/MASVS-CODE/MASWE-0041.md b/weaknesses/MASVS-CODE/MASWE-0041.md index 1a784c9..27831b3 100644 --- a/weaknesses/MASVS-CODE/MASWE-0041.md +++ b/weaknesses/MASVS-CODE/MASWE-0041.md @@ -9,13 +9,12 @@ mappings: masvs-v1: [MSTG-CODE-5] masvs-v2: [MASVS-CODE-3] cwe: [1395, 1357] - android-core-app-quality: [SC-N3, PS-T4] android-risks: - https://developer.android.com/privacy-and-security/risks/insecure-library - https://developer.android.com/privacy-and-security/risks/unsafe-download-manager + android-core-app-quality: [SC-N3, PS-T4] nist-ssdf: [PS.3.2] maswe-beta: [MASWE-0076] -status: new refs: - https://developer.android.com/privacy-and-security/risks/insecure-library - https://www.cisa.gov/sites/default/files/2023-04/sbom-types-document-508c.pdf @@ -28,13 +27,14 @@ refs: - https://developer.apple.com/support/third-party-SDK-requirements/ - https://www.youtube.com/watch?v=3klmiHX0uVQ - https://developer.apple.com/videos/play/wwdc2023/10060/ +status: new --- ## Overview -Mobile apps often depend on third-party libraries, software development kits (SDKs), or frameworks, either open-source components maintained by the community or closed-source products provided by commercial vendors, to implement functionality, streamline development, or integrate platform services. +This weakness occurs when an app includes third-party libraries, software development kits (SDKs), or frameworks that contain publicly known vulnerabilities. -When these dependencies contain vulnerabilities, they can be more easily exploited than vulnerabilities in first-party code because these vulnerabilities (and some exploits) are often documented in public databases, such as the CVE list, or accessible through security advisories. +Mobile apps often depend on such components, either open-source components maintained by the community or closed-source products provided by commercial vendors, to implement functionality, streamline development, or integrate platform services. Vulnerabilities in dependencies can be more easily exploited than vulnerabilities in first-party code because they (and some exploits) are often documented in public databases, such as the CVE list, or accessible through security advisories. **The developer is responsible** for ensuring all dependencies are secure and up to date because they are part of the app's codebase and therefore extend the app's attack surface. Google and Apple emphasize this in their security best practices: @@ -58,21 +58,25 @@ In terms of privacy, dependencies can introduce risks if they collect or transmi For more information on privacy and data collection declarations, see @MASWE-0068. +## Modes of Introduction + +- **Direct Dependencies**: Including vulnerable dependencies either manually (by copying and linking source or binary files) or, more commonly, via package managers and build tools (e.g., Gradle, CocoaPods, Swift Package Manager). This includes both first- and third-party SDKs, and may involve both statically and dynamically linked libraries. +- **Transitive Dependencies**: Pulling in vulnerable dependencies indirectly through other libraries or SDKs that the app uses, even if the app does not directly include the vulnerable library itself. +- **Dynamically Loaded Dependencies**: Loading libraries dynamically at runtime, which can make it difficult to track and manage dependencies and can lead to a vulnerable version being used without the developer's knowledge. +- **Outdated Platform Security Components**: Relying on platform-provided security components, such as cryptographic libraries or SSL/TLS implementations, that are outdated or lack timely updates. For instance, on Android, the system's security provider responsible for secure network communications must be explicitly updated by the developer at app startup. +- **Usage of Third-Party Frameworks**: Building the app on a third-party application framework such as Flutter or React Native, where the framework itself, as well as any platform-specific bindings, may contain vulnerabilities. + ## Impact -Using dependencies with known vulnerabilities in mobile apps can result in various security risks, including but not limited to: +Attackers can exploit publicly known vulnerabilities in the app's dependencies by: -- **Sensitive Data Exposure**: Vulnerable dependencies may be exploited to bypass access controls or cryptographic protections, which could lead to the exposure of sensitive user data, including credentials, session tokens, and personally identifiable information (PII). This can result in data breaches, which can have legal, financial and reputational consequences. -- **Execution of Unauthorized Code or Privilege Escalation**: Exploitable vulnerabilities in embedded dependencies can allow attackers to execute arbitrary code within the app's context (e.g., through code injection), escalate privileges, or manipulate app behavior. The overall impact can range from full compromise of user accounts, abuse of backend services or persistent access to protected resources. The business impact can be severe, including financial loss, service disruption, and damage to customer trust. -- **Regulatory and Policy Non-Compliance**: Including dependencies with publicly known CVEs may violate regulatory requirements (e.g., GDPR, HIPAA, PCI-DSS) or platform security policies (e.g., Google Play or App Store guidelines). Failure to update or remediate such vulnerabilities can result in app rejection, fines, or mandatory disclosures. +- Identifying vulnerable dependency versions in the app package and using public advisories or exploits. -## Modes of Introduction +This can lead to: -- **Direct Dependencies**: Vulnerable dependencies can be introduced into the app either manually (by copying and linking source or binary files) or more commonly via package managers and build tools (e.g., Gradle, CocoaPods, Swift Package Manager). This includes both first- and third-party SDKs, and may involve both statically and dynamically linked libraries. -- **Transitive Dependencies**: Dependencies can be pulled in indirectly through other libraries or SDKs that the app uses. This means that an app may still be affected by a vulnerable library if one of its dependencies includes it, even if the app does not directly include the library itself. -- **Dynamically Loaded Dependencies**: Some libraries may be dynamically loaded at runtime, which can make it difficult to track and manage dependencies. This can lead to situations where a vulnerable version of a library is used without the developer's knowledge. -- **Outdated Platform Security Components**: Mobile apps may depend on platform-provided security components, such as cryptographic libraries or SSL/TLS implementations. If these components are outdated or lack timely updates, they can introduce known vulnerabilities into the application. For instance, on Android, the system's security provider responsible for secure network communications must be explicitly updated by the developer at app startup. -- **Usage of Third-Party Frameworks**: Applications may be built in a third-party application framework such as Flutter or React Native. The framework itself, as well as any platform-specific bindings may contain vulnerabilities. +- **Compromise of Sensitive Data**: Attackers can exploit vulnerable components to bypass access controls or cryptographic protections and expose credentials, session tokens, or personally identifiable information (PII), resulting in data breaches with legal, financial, and reputational consequences for the app owner. +- **Execution of Unauthorized Code**: Attackers can exploit vulnerabilities in embedded dependencies to execute arbitrary code within the app's context (e.g., through code injection), escalate privileges, or manipulate app behavior, resulting in compromised user accounts, abuse of backend services, or persistent access to protected resources. +- **Legal and Regulatory Non-Compliance**: Shipping dependencies with publicly known CVEs can violate regulatory requirements (e.g., GDPR, HIPAA, PCI-DSS) or platform security policies (e.g., Google Play or App Store guidelines), resulting in app rejection, fines, or mandatory disclosures for the app owner. ## Mitigations diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0007.md b/weaknesses/MASVS-CRYPTO/MASWE-0007.md index 2f19acb..8186140 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0007.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0007.md @@ -10,7 +10,7 @@ mappings: masvs-v2: [MASVS-CRYPTO-2] cwe: [331, 337, 338, 522] android-risks: - - https://developer.android.com/privacy-and-security/risks/weak-prng + - https://developer.android.com/privacy-and-security/risks/weak-prng maswe-beta: [MASWE-0009, MASWE-0017] refs: - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf @@ -25,25 +25,32 @@ status: new ## Overview -In cryptography, the security strength is heavily influenced by the methods used to generate cryptographic keys. One critical aspect is the key size, also known as the key length, which is measured in bits and must comply with the latest security best practices. Encryption algorithms that use insufficient key sizes are vulnerable to attack, while longer keys typically result in more complex encryption. +This weakness occurs when cryptographic keys are generated with insufficient length, insufficient entropy, or otherwise flawed generation processes, weakening every protection built on top of them. -However, even with a sufficiently large key size, the security of the encryption can be compromised if the key generation process is flawed. Failing to use strong, cryptographically secure pseudorandom number generators (CSPRNGs) with sufficient entropy can generate predictable keys that are easier for attackers to guess or reproduce and that are susceptible to repetitive patterns. +In cryptography, security strength is heavily influenced by how keys are generated. One critical aspect is the key size (key length), measured in bits, which must comply with current security best practices: algorithms used with insufficient key sizes are vulnerable to attack. Even with a sufficiently large key size, security can be compromised if the generation process is flawed. Failing to use strong, cryptographically secure pseudorandom number generators (CSPRNGs) with sufficient entropy can produce predictable keys that are easier for attackers to guess or reproduce. + +## Modes of Introduction + +- **Insufficient Entropy**: Generating keys from a source of randomness with insufficient entropy or from predictable seeds. +- **Insufficient Key Length**: Generating keys shorter than the lengths recommended by current standards for the chosen algorithm. +- **Risky or Broken Algorithms**: Generating keys using deprecated, risky, or inherently broken cryptographic algorithms, which often only support weak key lengths. +- **Insecure Key Export**: Exporting a key in plaintext when it must leave the secure environment in which it was created (for example, to be backed up or shared with another device), instead of "wrapping" it (encrypting it with another key) as specified in [NIST.SP.800-175Br1 5.3.5](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-175Br1.pdf), even when the key is sent over a secure channel. ## Impact -- **Risk of Brute-Force Attacks**: Improper key generation, whether due to shorter key length or predictable random number generator (PRNG) inputs, increases the risk of brute-force attacks. Attackers can more easily guess or systematically try possible keys until they find the correct one. -- **Loss of Confidentiality**: Encryption relies on strong keys to maintain the confidentiality of sensitive data. Seed values with insufficient entropy can allow attackers to decrypt and access confidential information, leading to unauthorized disclosure and potential data breaches. -- **Loss of Integrity**: Improper key generation can compromise data integrity, allowing attackers to exploit vulnerabilities and potentially alter or tamper with the information without detection. +Attackers can predict or reproduce improperly generated cryptographic keys by: -## Modes of Introduction +- Brute-forcing cryptographic material generated with insufficient length. +- Predicting or reproducing values generated with insufficient entropy. +- Intercepting cryptographic keys exported in plaintext. + +This can lead to: -- **Insufficient Entropy**: Using a source of randomness with insufficient entropy can lead to predictable cryptographic keys. -- **Insufficient Key Length**: Cryptographic keys that are too short provide inadequate security. For example, keys shorter than recommended lengths for modern algorithms may be vulnerable to brute force attacks, making them easier for attackers to break. -- **Using Risky or Broken Algorithms**: Relying on deprecated, risky or inherently broken cryptographic algorithms can result in the generation of weaker keys. As these algorithms often have vulnerabilities or support shorter key lengths, they are more susceptible to modern attacks, compromising the overall security of the app. -- **Insecure Key Export**: When a generated key must leave the secure environment in which it was created (for example, to be backed up or shared with another device), exporting it in plaintext exposes it to compromise. Keys should be "wrapped" (encrypted with another key) before export, as specified in [NIST.SP.800-175Br1 5.3.5](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-175Br1.pdf), even when the key is sent over a secure channel. +- **Compromise of Sensitive Data**: Attackers can decrypt protected information or forge encrypted data, resulting in unauthorized disclosure or modification of sensitive data. +- **Authentication or Authorization Bypass**: Attackers can create valid cryptographic values or impersonate trusted parties, resulting in unauthorized access to protected accounts, data, or functionality. ## Mitigations -- Always use modern, well-established cryptographic libraries and APIs that follow best practices for entropy generation and key management. -- When keys must be exported, protect them with key wrapping (e.g. AES Key Wrap or an equivalent authenticated scheme) so they are never exposed in plaintext outside a secure environment. -- Ensure that key lengths meet or exceed current standards for cryptographic security, such as 256-bit for AES encryption and 2048-bit for RSA (considering quantum computing attacks). See ["NIST Special Publication 800-57: Recommendation for Key Management: Part 1 – General"](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf) and ["NIST Special Publication 800-131A: Transitioning the Use of Cryptographic Algorithms and Key Lengths"](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf) and ["BlueKrypt's Cryptographic Key Length Recommendation"](https://www.keylength.com/) for more information on cryptographic key sizes. +- **Use Established Cryptographic Libraries**: Always use modern, well-established cryptographic libraries and APIs that follow best practices for entropy generation and key management. +- **Wrap Keys Before Export**: When keys must be exported, protect them with key wrapping (e.g. AES Key Wrap or an equivalent authenticated scheme) so they are never exposed in plaintext outside a secure environment. +- **Use Sufficient Key Lengths**: Ensure that key lengths meet or exceed current standards for cryptographic security, such as 256-bit for AES encryption and 2048-bit for RSA (considering quantum computing attacks). See ["NIST Special Publication 800-57: Recommendation for Key Management: Part 1 – General"](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf), ["NIST Special Publication 800-131A: Transitioning the Use of Cryptographic Algorithms and Key Lengths"](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf), and ["BlueKrypt's Cryptographic Key Length Recommendation"](https://www.keylength.com/) for more information on cryptographic key sizes. diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0011.md b/weaknesses/MASVS-CRYPTO/MASWE-0011.md index 4650bc5..d9b6867 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0011.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0011.md @@ -21,33 +21,43 @@ refs: - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Br2.pdf - https://www.usenix.org/legacy/event/woot10/tech/full_papers/Rizzo.pdf status: new - --- ## Overview -Improper encryption refers to cryptographic systems or implementations that are vulnerable to attack, allowing unauthorized individuals to decrypt secured data. +This weakness occurs when encryption is implemented with broken algorithms, insecure modes or parameters, or non-cryptographic techniques, leaving the protected data recoverable or forgeable without the key. + +Encryption is only as strong as its weakest component: the algorithm, the mode of operation, the padding scheme, the initialization vectors (IVs) or nonces, and the way keys are used all contribute to the actual security of the ciphertext. + +## Modes of Introduction + +- **Broken Algorithms**: Relying on broken encryption algorithms (i.e., that are deprecated or disallowed by NIST or other standards) such as RC4. +- **Predictable or Reused Initialization Vectors (IVs)**: Using IVs that are hardcoded, null, predictable, or reused in modes like AES-CBC or AES-CTR, or reusing nonces or using authentication tags of insufficient length in AEAD modes like AES-GCM. +- **Risky Padding**: Using a padding scheme susceptible to padding oracle attacks (e.g. PKCS#7 with unauthenticated AES-CBC, or PKCS#1 v1.5 for RSA) in combination with observable padding-error signals. +- **Broken Modes of Operation**: Using modes that are considered broken. For example, AES-ECB is broken due to practical known-plaintext attacks and is disallowed by NIST. +- **Insufficient Key Length**: Using key sizes below current recommendations for the chosen algorithm. +- **Insecure or Wrong Key Usage**: Reusing a single key for multiple purposes (e.g. encryption and signing) or with an unauthorized algorithm, violating key-separation principles. Per [NIST.SP.800-57pt1r5](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf), a single key should be used for only one purpose. +- **Non-Cryptographic Operations**: Relying on techniques such as XOR, Base64 encoding, or simple obfuscation methods for security purposes. These methods provide no actual encryption. ## Impact -- **Loss of Confidentiality**: Improper encryption may enable attackers to decipher and obtain sensitive information, resulting in unauthorized exposure and possible data breaches. -- **Loss of Integrity**: Improper encryption can compromise the integrity of data, allowing adversaries to alter or manipulate the information without detection. +Attackers can decrypt or forge improperly encrypted data by: -## Mode of Introduction +- Performing cryptanalysis of broken algorithms, modes, or parameters. +- Exploiting predictable or reused IVs or nonces to detect patterns or recover plaintext. +- Exploiting padding oracles exposed through observable error signals or timing differences. +- Brute-forcing cryptographic material generated with insufficient length. -- **Broken Algorithms**: Relying on broken encryption algorithms (i.e., that are deprecated or disallowed by NIST or other standards) such as RC4. -- **Predictable or Reused Initialization Vectors (IVs)**: Using IVs that are hardcoded, null, predictable, or reused in modes like AES-CBC or AES-CTR breaks semantic security, allowing attackers to detect patterns or recover plaintext differences. In AEAD modes like AES-GCM, reusing nonces or using authentication tags of insufficient length compromises both confidentiality and integrity. On Android, use `GCMParameterSpec` (not the legacy `IvParameterSpec`) for GCM. -- **Risky Padding**: Using a padding scheme susceptible to padding oracle attacks (e.g. PKCS#7 with unauthenticated AES-CBC, or PKCS#1 v1.5 for RSA) in combination with observable padding-error signals allows attackers to decrypt or forge ciphertext without the key. See @MASWE-0015 for signature verification and prefer authenticated encryption. -- **Broken Modes of Operation**: Using modes that are considered broken. For example, AES-ECB is broken due to practical known-plaintext attacks and it's disallowed by NIST. -- **Insufficient Key Length**: The use of insufficient key sizes (e.g., 128-bit keys in AES) can compromise encryption strength making the encryption susceptible to brute-force attacks. -- **Insecure or Wrong Key Usage**: Reusing a single key for multiple purposes (e.g. encryption and signing) or with an unauthorized algorithm violates key-separation principles. Per [NIST.SP.800-57pt1r5](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf), a single key should be used for only one purpose. -- **Non-Cryptographic Operations**: Relying on techniques such as XOR, Base64 encoding, or simple obfuscation methods for security purposes. These methods provide no actual encryption and can be easily reversed or decoded, exposing sensitive data. +This can lead to: + +- **Compromise of Sensitive Data**: Attackers can decipher protected information or alter it without detection, resulting in unauthorized disclosure or manipulation of sensitive data. +- **Authentication or Authorization Bypass**: Attackers can forge ciphertexts, tokens, or signatures accepted by the app or its backend, resulting in unauthorized access to protected accounts, data, or functionality. ## Mitigations - **Use Secure Encryption Modes**: Choose secure, authenticated modes (e.g. approved by NIST) such as `AES/GCM/NoPadding`. If AES-CBC must be used, apply Encrypt-then-MAC (e.g. append HMAC) and, for RSA, prefer OAEP over PKCS#1 v1.5. -- **Ensure Proper Initialization Vector Management**: Generate IVs using cryptographically secure random number generators (with sufficient entropy) and ensure they are unique for every operation; never hardcode, null, or reuse them. +- **Ensure Proper Initialization Vector Management**: Generate IVs using cryptographically secure random number generators (with sufficient entropy) and ensure they are unique for every operation; never hardcode, null, or reuse them. On Android, use `GCMParameterSpec` (not the legacy `IvParameterSpec`) for GCM. - **Use Sufficiently Long Keys**: Enforce sufficiently long keys such as those approved by NIST, e.g., a minimum of 256 bits for AES. - **Use Each Key for a Single Purpose**: Derive or generate separate keys for encryption, authentication, and signing, and only use each key with its authorized algorithm. - **Do Not Expose Cryptographic Errors**: Avoid leaking detailed padding or decryption error messages or timing differences that could serve as an oracle. -- **Rely on Proper Cryptographic Primitives**: Rely on well-vetted cryptographic primitives that have undergone rigorous peer review and formal validation. +- **Rely on Proper Cryptographic Primitives**: Rely on well-vetted cryptographic primitives that have undergone rigorous peer review and formal validation. See @MASWE-0015 for signature verification. diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0016.md b/weaknesses/MASVS-CRYPTO/MASWE-0016.md index fbe332c..525e261 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0016.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0016.md @@ -3,8 +3,8 @@ title: Improper Random Number Generation id: MASWE-0016 alias: improper-random-number-generation requirement: "The app properly generates random numbers." -platform: ["android", "ios"] -profiles: ["L1", "L2"] +platform: [android, ios] +profiles: [L1, L2] mappings: masvs-v1: [MSTG-CRYPTO-6] masvs-v2: [MASVS-CRYPTO-1] @@ -14,30 +14,42 @@ mappings: maswe-beta: [MASWE-0027] observed_examples: - https://nvd.nist.gov/vuln/detail/CVE-2013-6386 -- https://nvd.nist.gov/vuln/detail/CVE-2013-6386 - https://nvd.nist.gov/vuln/detail/CVE-2006-3419 - https://nvd.nist.gov/vuln/detail/CVE-2008-4102 - https://www.zellic.io/blog/proton-dart-flutter-csprng-prng/ +refs: +- https://www.ietf.org/rfc/rfc1750.txt +- https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html#secure-random-number-generation status: new --- ## Overview -A [pseudorandom number generator (PRNG)](https://en.wikipedia.org/wiki/Pseudorandom_number_generator) algorithm generates sequences based on a seed with insufficient entropy that may be predictable. Common implementations are not cryptographically secure. For example, they typically use a linear congruential formula, allowing an attacker to predict future outputs, given enough observed outputs. Therefore, it is not suitable for security-critical applications or protecting sensitive data. - -## Impact +This weakness occurs when random values used in a security context are produced by a non-cryptographic pseudorandom number generator (PRNG) or derived from predictable seeds. -- **Bypass Protection Mechanism**: Using a non-cryptographically secure PRNG in a security context, such as authentication, poses significant risks. An attacker could potentially guess the generated numbers and gain access to privileged data or functionality. Predicting or regenerating random numbers can lead to encryption breaches, compromise sensitive user information, or enable user impersonation. +A [PRNG](https://en.wikipedia.org/wiki/Pseudorandom_number_generator) generates sequences deterministically from a seed. Common implementations are not cryptographically secure; for example, they typically use a linear congruential formula whose future outputs can be predicted after observing enough previous outputs. Such generators are not suitable for security-critical purposes like generating session tokens, one-time passwords, or cryptographic key material. ## Modes of Introduction -- **Risky Random APIs**: The app may use many existing APIs to generate random numbers with insufficient entropy. -- **Non-random Sources**: The app may use custom methods to create "supposedly random" values, using non-random sources such as the current time. +- **Risky Random APIs**: Using general-purpose random APIs, which do not provide cryptographically secure output, in security-relevant contexts. +- **Non-Random Sources**: Using custom methods to create "supposedly random" values from non-random sources such as the current time. +- **Hardcoded or Predictable Seeds**: Seeding a generator deterministically, e.g. with a hardcoded seed value shipped in the app. -## Mitigations +## Impact -For security-relevant contexts, use cryptographically secure random numbers. +Attackers can predict or reproduce random values used in security contexts by: -In general, it is strongly recommended not to use any random function in a deterministic way, even if it's a secure one, especially those involving hardcoded seed values (which are vulnerable to exposure by decompilation). +- Observing enough outputs to recover the internal state of a non-cryptographic PRNG. +- Predicting or reproducing values generated with insufficient entropy. +- Obtaining the app package and reverse engineering it. + +This can lead to: + +- **Authentication or Authorization Bypass**: Attackers can predict session tokens, one-time passwords, or password-reset codes, resulting in unauthorized access to user accounts or privileged functionality. +- **Compromise of Sensitive Data**: Attackers can reproduce cryptographic material derived from predictable values and decrypt protected information, resulting in unauthorized disclosure of sensitive data. + +## Mitigations -Refer to the [RFC 1750 - Randomness Recommendations for Security](https://www.ietf.org/rfc/rfc1750.txt) and the [OWASP Cryptographic Storage Cheat Sheet - Secure Random Number Generation](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html#secure-random-number-generation) for more information and recommendations on random number generation. +- **Use Cryptographically Secure RNGs**: For security-relevant contexts, always generate random values with a cryptographically secure random number generator provided by the platform. +- **Avoid Deterministic Seeding**: Do not use any random function in a deterministic way, even a secure one, and especially avoid hardcoded seed values, which can be recovered by decompiling the app. +- **Follow Established Guidance**: Refer to [RFC 1750 - Randomness Recommendations for Security](https://www.ietf.org/rfc/rfc1750.txt) and the [OWASP Cryptographic Storage Cheat Sheet - Secure Random Number Generation](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html#secure-random-number-generation) for recommendations on random number generation. diff --git a/weaknesses/MASVS-NETWORK/MASWE-0025.md b/weaknesses/MASVS-NETWORK/MASWE-0025.md index 635326e..c1500d1 100644 --- a/weaknesses/MASVS-NETWORK/MASWE-0025.md +++ b/weaknesses/MASVS-NETWORK/MASWE-0025.md @@ -10,8 +10,8 @@ mappings: masvs-v2: [MASVS-NETWORK-1] cwe: [311, 319] android-risks: - - https://developer.android.com/privacy-and-security/risks/cleartext-communications - - https://developer.android.com/privacy-and-security/risks/insecure-machine-to-machine + - https://developer.android.com/privacy-and-security/risks/cleartext-communications + - https://developer.android.com/privacy-and-security/risks/insecure-machine-to-machine android-core-app-quality: [SC-9, SC-N1, SC-N2] maswe-beta: [MASWE-0050, MASWE-0037, MASWE-0048] refs: @@ -36,38 +36,44 @@ status: new ## Overview -When data is sent in cleartext (i.e. without encryption) it becomes accessible to attackers who can monitor network channels. Attackers can perform passive eavesdropping to intercept data or employ active [Machine-in-the-Middle (MITM)](../../Document/0x04f-Testing-Network-Communication.md#intercepting-network-traffic-through-mitm) attacks to manipulate data, potentially altering app behavior or injecting malicious content. +This weakness occurs when an app transmits data over the network in cleartext, i.e. without encryption, making it accessible to anyone able to monitor the network channel. -This weakness is especially concerning when sensitive information is transmitted without encryption, putting user privacy and security at direct risk. Even when sensitive data isn't being transmitted, using cleartext communication remains a vulnerability. Network attacks like ARP poisoning and DNS spoofing can allow attackers to intercept or redirect traffic, potentially disrupting app functionality or deceiving users by redirecting them to malicious sites that impersonate legitimate services. +This is especially concerning when sensitive information is transmitted, putting user privacy and security at direct risk. However, even when no sensitive data is being transmitted, cleartext communication remains a weakness: attackers who can intercept or redirect traffic may disrupt app functionality or deceive users by redirecting them to malicious sites that impersonate legitimate services. -If the connections were secured using encryption and proper authentication mechanisms, these attacks would be much harder to perform because the attacker would need to bypass encryption and certificate validation. Secure network protocols not only provide confidentiality but also ensure data integrity and authenticity through encryption and certificate validation, preventing attackers from altering data. +Secure network protocols not only provide confidentiality but also ensure data integrity and authenticity through encryption and certificate validation. When connections are properly secured, interception and manipulation attacks become much harder to perform because the attacker would need to bypass encryption and certificate validation. + +## Modes of Introduction + +- **Cleartext Traffic Allowed in Platform-Provided Settings**: Configuring platform-provided settings (e.g. Network Security Configuration on Android or App Transport Security on iOS) to explicitly allow cleartext traffic (globally or per-domain), making it the default behavior for all network connections managed by those settings. +- **Usage of HTTP**: Using HTTP instead of HTTPS for communication, which does not encrypt data in transit. +- **Usage of Non-HTTP Insecure Protocols**: Using insecure protocols such as FTP, SMTP without TLS, TCP sockets, or custom protocols which do not encrypt data in transit. +- **Unencrypted Non-IP Interfaces**: Transferring data over local/proximity interfaces such as Bluetooth/BLE, NFC, USB, or Wi-Fi Direct without encryption. These machine-to-machine channels are often overlooked. +- **Authentication Material over Insecure Channels**: Sending session IDs, tokens, passwords, or API keys over any of the above unencrypted channels. +- **Usage of Low-Level Network APIs**: Using low-level network APIs that do not enforce encryption and do not honor the platform's network security settings, such as `Socket` on Android or `NSURLConnection` on iOS. +- **Cross-Platform Framework Misconfiguration**: Configuring cross-platform frameworks improperly so that cleartext traffic is allowed for both Android and iOS versions of an app. +- **Third-Party Libraries**: Using third-party libraries or SDKs that default to insecure communication methods or are improperly configured. ## Impact -- **Data Interception**: Attackers can capture and read sensitive information transmitted over the network. -- **Data Manipulation**: Attackers might alter data in transit, causing corruption or injecting malicious content. -- **Unauthorized Access**: Attackers may intercept session tokens or credentials sent over cleartext channels, enabling them to impersonate users and gain unauthorized access to user accounts or systems. -- **Privacy Breach**: Personal and confidential user information could be exposed, violating privacy regulations. -- **Regulatory Compliance Violations**: Exposing sensitive data may lead to non-compliance with laws like GDPR or HIPAA, resulting in legal penalties. -- **Reputation Damage**: Security breaches can erode user trust and harm the organization's reputation. +Attackers can intercept or modify cleartext network traffic by: -## Modes of Introduction +- Monitoring network traffic on the same network (e.g., public Wi-Fi or a compromised router). +- Performing a Machine-in-the-Middle (MITM) attack, e.g., via ARP poisoning, DNS spoofing, or a rogue access point. +- Monitoring local or proximity interfaces such as Bluetooth, NFC, or USB. -- **Cleartext Traffic Allowed in Platform-provided Settings:** Configuring platform-provided settings (e.g. Network Security Configuration on Android or App Transport Security on iOS) to explicitly allow cleartext traffic (globally or per-domain), making it the default behavior for all network connections managed by those settings. -- **Usage of HTTP:** Using HTTP instead of HTTPS for communication, which does not encrypt data in transit. -- **Usage of Non-HTTP Insecure Protocols:** Using insecure protocols such as FTP, SMTP without TLS, TCP sockets or custom protocols which do not encrypt data in transit. -- **Unencrypted Non-IP Interfaces:** Transferring data over local/proximity interfaces such as Bluetooth/BLE, NFC, USB, or Wi-Fi Direct without encryption. These machine-to-machine channels are often overlooked but can expose sensitive data or enable remote device takeover if the payloads are not encrypted and authenticated. -- **Authentication Material over Insecure Channels:** Sending session IDs, tokens, passwords, or API keys over any of the above unencrypted channels. -- **Usage of Low-Level Network APIs:** Use of low-level network APIs that do not enforce encryption and do not honor the platform's network security settings, such as `Socket` on Android or `NSURLConnection` on iOS. -- **Cross-Platform Framework Misconfiguration:** Improper settings in cross-platform frameworks may allow cleartext traffic for both Android and iOS versions of an app. -- **Third-Party Libraries**: Using third-party libraries or SDKs that default to insecure communication methods or are improperly configured. +This can lead to: + +- **Compromise of Sensitive Data**: Attackers can capture, read, or alter sensitive information transmitted over the network, resulting in unauthorized disclosure or manipulation of user data. +- **Authentication or Authorization Bypass**: Attackers can capture session tokens or credentials sent over cleartext channels, resulting in user impersonation and unauthorized access to accounts or backend systems. +- **Compromise of System Integrity and Business Operations**: Attackers can inject malicious content or redirect users to impersonated services, resulting in altered app behavior, phishing, and reputational damage for the app owner. +- **Legal and Regulatory Non-Compliance**: Exposing personal data in transit can violate laws such as GDPR or HIPAA, resulting in legal penalties and mandatory disclosures for the app owner. ## Mitigations -- **Use Secure Protocols:** Always use secure protocols like HTTPS (which employs TLS for encryption), FTPS, SFTP or SMTPS for all communication channels. Ensure these protocols are used consistently throughout the app. -- **Explicitly Disable Cleartext Traffic:** Never allow cleartext traffic globally in the app configuration. Ensure that cleartext traffic is explicitly disabled using security settings like the Network Security Configuration on Android and App Transport Security (ATS) on iOS. Prefer per-domain exceptions over global settings but use them carefully and only when there is no other option. -- **Use Per-Domain Exceptions Sparingly:** If cleartext traffic is absolutely necessary for specific domains, ensure these domains are trusted and essential for the app's functionality, and conduct a thorough risk assessment before including them. +- **Use Secure Protocols**: Always use secure protocols like HTTPS (which employs TLS for encryption), FTPS, SFTP, or SMTPS for all communication channels. Ensure these protocols are used consistently throughout the app. +- **Explicitly Disable Cleartext Traffic**: Never allow cleartext traffic globally in the app configuration. Ensure that cleartext traffic is explicitly disabled using security settings like the Network Security Configuration on Android and App Transport Security (ATS) on iOS. +- **Use Per-Domain Exceptions Sparingly**: If cleartext traffic is absolutely necessary for specific domains, ensure these domains are trusted and essential for the app's functionality, and conduct a thorough risk assessment before including them. - **Prefer Server Fixes**: Whenever possible, work with the server team to enable secure communication. Instead of adding network security exceptions to the mobile app, such as allowing cleartext traffic or lowering the minimum TLS version, update server configurations to support HTTPS with valid certificates and modern TLS protocols. -- **Use High-Level Network APIs:** Use high-level network APIs that automatically handle encryption, certificate validation, and errors, such as [`HttpsURLConnection`](https://developer.android.com/reference/javax/net/ssl/HttpsURLConnection) on Android or [`URLSession`](https://developer.apple.com/documentation/foundation/urlsession) on iOS. Avoid using low-level network APIs or custom network stacks that bypass the platform-provided network security features. -- **Use Secure Cross-Platform Frameworks:** Ensure that cross-platform frameworks—such as React Native, Flutter, or Xamarin—are configured to enforce secure communication by default and do not allow cleartext traffic. Review the framework's documentation and adjust network security settings to align with best practices. +- **Use High-Level Network APIs**: Use high-level network APIs that automatically handle encryption, certificate validation, and errors, such as [`HttpsURLConnection`](https://developer.android.com/reference/javax/net/ssl/HttpsURLConnection) on Android or [`URLSession`](https://developer.apple.com/documentation/foundation/urlsession) on iOS. Avoid using low-level network APIs or custom network stacks that bypass the platform-provided network security features. +- **Use Secure Cross-Platform Frameworks**: Ensure that cross-platform frameworks are configured to enforce secure communication by default and do not allow cleartext traffic. Review the framework's documentation and adjust network security settings to align with best practices. - **Use Secure Third-Party Components**: Verify that any third-party libraries and SDKs used in the app enforce secure communication protocols, especially if they handle sensitive data or use low-level networking APIs. Ensure that these components are regularly updated to address any vulnerabilities. diff --git a/weaknesses/MASVS-NETWORK/MASWE-0026.md b/weaknesses/MASVS-NETWORK/MASWE-0026.md index cf8e241..7bf6902 100644 --- a/weaknesses/MASVS-NETWORK/MASWE-0026.md +++ b/weaknesses/MASVS-NETWORK/MASWE-0026.md @@ -14,41 +14,47 @@ mappings: - https://developer.android.com/privacy-and-security/risks/unsafe-hostname maswe-beta: [MASWE-0052] refs: - - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf#page=17 - - https://developer.android.com/privacy-and-security/security-ssl#tls-1.3-enabled-by-default - - https://support.google.com/faqs/answer/7071387?hl=en - - https://developer.android.com/reference/android/webkit/WebViewClient.html?sjid=15211564825735678155-EU#onReceivedSslError(android.webkit.WebView,%20android.webkit.SslErrorHandler,%20android.net.http.SslError) - - https://developer.android.com/privacy-and-security/security-ssl#WarningsSslSocket - - https://wiki.sei.cmu.edu/confluence/display/java/MSC00-J.+Use+SSLSocket+rather+than+Socket+for+secure+data+exchange - - https://developer.apple.com/forums/thread/67493 - - https://developer.apple.com/forums/thread/707320 - - https://support.apple.com/en-us/102390 - - https://developer.apple.com/documentation/foundation/performing-manual-server-trust-authentication +- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf#page=17 +- https://developer.android.com/privacy-and-security/security-ssl#tls-1.3-enabled-by-default +- https://support.google.com/faqs/answer/7071387?hl=en +- https://developer.android.com/reference/android/webkit/WebViewClient.html?sjid=15211564825735678155-EU#onReceivedSslError(android.webkit.WebView,%20android.webkit.SslErrorHandler,%20android.net.http.SslError) +- https://developer.android.com/privacy-and-security/security-ssl#WarningsSslSocket +- https://wiki.sei.cmu.edu/confluence/display/java/MSC00-J.+Use+SSLSocket+rather+than+Socket+for+secure+data+exchange +- https://developer.apple.com/forums/thread/67493 +- https://developer.apple.com/forums/thread/707320 +- https://support.apple.com/en-us/102390 +- https://developer.apple.com/documentation/foundation/performing-manual-server-trust-authentication status: new --- ## Overview -Apps that do not properly validate TLS certificates during secure communication are susceptible to [Machine-in-the-Middle (MITM)](../../Document/0x04f-Testing-Network-Communication.md#intercepting-network-traffic-through-mitm) attacks and other security threats. This weakness occurs when an app accepts invalid, expired, self-signed, or untrusted certificates without appropriate verification, compromising the integrity and confidentiality of data in transit. +This weakness occurs when an app does not properly validate TLS certificates during secure communication, accepting invalid, expired, self-signed, or untrusted certificates without appropriate verification. -## Impact - -- **Data Interception**: Attackers can capture and read sensitive information transmitted over the network. -- **Data Manipulation**: Attackers might alter data in transit, causing corruption or injecting malicious content. -- **Data Exposure**: Sensitive information can be compromised. -- **Unauthorized Access**: Attackers may gain unauthorized access to user accounts or systems by intercepting authentication tokens or credentials. -- **Impersonation of Services**: Users may be deceived into interacting with malicious servers impersonating legitimate services. -- **Data Integrity Loss**: Altered or corrupted data may be accepted by the application, leading to unreliable or malicious outcomes. +Certificate validation is the mechanism through which a TLS client establishes that it is talking to the intended server and not to an intermediary. When it is disabled, weakened, or implemented incorrectly, the confidentiality and integrity guarantees of TLS no longer hold, even though the connection itself is encrypted. ## Modes of Introduction -- **Disabling Certificate Validation**: Developers disable or bypass certificate validation checks to simplify development or troubleshoot connectivity issues. -- **Accepting Self-Signed Certificates**: Applications accept self-signed or untrusted certificates without proper validation against trusted Certificate Authorities (CAs). -- **Ignoring Hostname Verification**: Failing to verify that the certificate's hostname matches the server's hostname allows attackers to present valid certificates for other domains. +- **Disabling Certificate Validation**: Disabling or bypassing certificate validation checks to simplify development or troubleshoot connectivity issues, and shipping that configuration to production. +- **Accepting Self-Signed Certificates**: Accepting self-signed or untrusted certificates without proper validation against trusted Certificate Authorities (CAs). +- **Ignoring Hostname Verification**: Failing to verify that the certificate's hostname matches the server's hostname. - **Using Insecure Custom Trust Managers**: Implementing custom certificate validation logic that is incomplete, incorrect, or insecure. - **Incorrect Error Handling**: Proceeding with connections even when certificate validation errors occur, without alerting the user or terminating the connection. - **Trusting All Certificates**: Configuring the application to trust all certificates by default, without any validation. +## Impact + +Attackers can intercept or modify TLS-protected network traffic by: + +- Performing a Machine-in-the-Middle (MITM) attack, e.g., via ARP poisoning, DNS spoofing, or a rogue access point. +- Presenting a fraudulent or otherwise invalid certificate that the app accepts. + +This can lead to: + +- **Compromise of Sensitive Data**: Attackers can capture, read, or alter sensitive information transmitted over the network, resulting in unauthorized disclosure or manipulation of user data. +- **Authentication or Authorization Bypass**: Attackers can capture credentials or session tokens in transit, resulting in user impersonation and unauthorized access to accounts or backend systems. +- **Compromise of System Integrity and Business Operations**: Attackers can impersonate legitimate servers and feed altered or malicious data to the app, resulting in unreliable or malicious app behavior and reputational damage for the app owner. + ## Mitigations - **Enforce Strict Certificate Validation**: Always validate TLS certificates against a trusted set of Certificate Authorities (CAs) provided by the operating system or a trusted third party. diff --git a/weaknesses/MASVS-NETWORK/MASWE-0027.md b/weaknesses/MASVS-NETWORK/MASWE-0027.md index 45226de..8502c9d 100644 --- a/weaknesses/MASVS-NETWORK/MASWE-0027.md +++ b/weaknesses/MASVS-NETWORK/MASWE-0027.md @@ -10,42 +10,48 @@ mappings: masvs-v2: [MASVS-NETWORK-2] cwe: [295] maswe-beta: [MASWE-0047] +refs: +- https://developer.android.com/privacy-and-security/security-config#CertificatePinning +- https://developer.apple.com/news/?id=g9ejcf8y +- https://cheatsheetseries.owasp.org/cheatsheets/Pinning_Cheat_Sheet.html status: new --- ## Overview -[Identity pinning (aka. certificate pinning, public key pinning or TLS pinning)](../../Document/0x04f-Testing-Network-Communication.md/#restricting-trust-identity-pinning) refers to associating a mobile app with a specific cryptographic identity, such as a certificate or public key to ensure that the app only communicates with trusted servers. +This weakness occurs when identity pinning (also known as certificate pinning, public key pinning, or TLS pinning) is not implemented, or is implemented incorrectly, so the app cannot guarantee that it only communicates with servers presenting a specific, pre-determined cryptographic identity. -When a mobile app does not implement certificate pinning, or if it is implemented incorrectly, the app remains vulnerable to [Machine-in-the-Middle (MITM)](../../Document/0x04f-Testing-Network-Communication.md#intercepting-network-traffic-through-mitm) attacks which enable attackers to intercept and modify the communication between the app and the intended server. This occurs because when the app is presented a fraudulent certificate that the app may unknowingly trust, thereby gaining access to sensitive data or injecting malicious content into the data stream. +Identity pinning associates a mobile app with a specific certificate or public key, adding a layer of trust verification on top of standard certificate validation. This reduces the risk of unauthorized interception even if a trusted Certificate Authority (CA) is compromised. Without it, the app trusts any certificate that chains to any CA in the trust store, so a single compromised or coerced CA is enough to intercept its traffic. -**Limitations**: Certificate pinning adds a layer of trust verification by ensuring that the app only accepts connections to servers with specific, pre-determined certificates or public keys. This reduces the risk of unauthorized interception, even if a trusted Certificate Authority (CA) is compromised. However, it is not foolproof: +Pinning is not foolproof: attackers who can reverse-engineer the app may remove or modify the pre-defined pins or the pinning logic, and attackers using runtime hooking and dynamic instrumentation may bypass the pinning checks on a device they control. This highlights the importance of implementing pinning **alongside other security measures** to enhance the app's resistance to advanced threats. -- Attackers who can reverse-engineer the app may analyze and remove or modify the pre-defined pins or the certificate pinning logic to permanently bypass the checks. -- Attackers who can perform @MASTG-TECH-0051 techniques to manipulate the app and bypass pinning checks. +## Modes of Introduction -This highlights the importance of implementing certificate pinning **alongside other security measures** to enhance the app's resistance to advanced threats. +- **Improper Configuration of Pinning Libraries**: Misconfiguring libraries like TrustKit, OkHttp's `CertificatePinner`, Volley, or AFNetworking's `SSLPinningMode`, leading to ineffective pinning. +- **Dynamic Pinning without Security**: Retrieving pins dynamically over insecure channels without proper validation. +- **Improper Validation Logic**: Implementing custom pinning logic that does not correctly validate the certificate chain or public key. For example, accepting any certificate that chains to a trusted root CA instead of a specific certificate or public key. +- **Lack of Backup Pins**: Not including backup pins, so the app cannot establish connections if the primary pin is no longer valid. ## Impact -- **Data Interception**: Attackers can capture and read sensitive information transmitted over the network. -- **Data Manipulation**: Attackers might alter data in transit, causing corruption or injecting malicious content. -- **Data Exposure**: Sensitive information can be compromised. -- **Denial of Service**: Incorrect pinning may cause legitimate connections to fail, leading to service disruptions for users. For example, if a pinned certificate expires and is not updated, the app may be unable to establish secure connections. +Attackers can intercept or modify TLS-protected traffic even when standard certificate validation succeeds by: -## Modes of Introduction +- Performing a Machine-in-the-Middle (MITM) attack, e.g., via ARP poisoning, DNS spoofing, or a rogue access point. +- Obtaining a valid certificate for the target domain from a compromised, coerced, or rogue Certificate Authority (CA). +- Installing an attacker-controlled CA certificate on a device they control to inspect the app's traffic. -- **Improper Configuration of Pinning Libraries**: Misconfiguring libraries like TrustKit, OkHttp's `CertificatePinner`, Volley, or AFNetworking's `SSLPinningMode`, leading to ineffective pinning. -- **Dynamic Pinning without Security**: Retrieving pins dynamically over insecure channels without proper validation, making it easy for attackers to supply malicious pins. -- **Improper Validation Logic**: Custom pinning implementations that do not correctly validate the certificate chain or public key. For example, accepting any certificate that chains to a trusted root CA instead of a specific certificate or public key. -- **Lack of Backup Pins**: Not including backup pins to prevent connectivity issues if the primary pin is no longer valid. +This can lead to: + +- **Compromise of Sensitive Data**: Attackers can capture, read, or alter sensitive information transmitted over the network, resulting in unauthorized disclosure or manipulation of user data. +- **Authentication or Authorization Bypass**: Attackers can capture credentials or session tokens in transit, resulting in user impersonation and unauthorized access to accounts or backend systems. +- **Compromise of System Integrity and Business Operations**: Attackers can inspect and reverse engineer the app's API traffic to abuse backend services, resulting in fraud, scraping, or service abuse against the app owner. ## Mitigations -- **Prefer Platform-provided Solutions**: Use platform-provided mechanisms like Android's Network Security Configuration (NSC) or iOS's App Transport Security (ATS) to enforce pinning. +- **Prefer Platform-Provided Solutions**: Use platform-provided mechanisms like Android's Network Security Configuration (NSC) or iOS's App Transport Security (ATS) to enforce pinning. - **Use Trusted Pinning Libraries**: Refrain from writing custom pinning logic; instead, rely on established and well-maintained libraries and frameworks (e.g., TrustKit, OkHttp's `CertificatePinner`) and ensure they are correctly configured according to best practices. - **Secure Dynamic Pinning**: If dynamic pinning is necessary, retrieve pins over secure channels and validate them thoroughly before use. - **Pin to Public Keys Instead of Certificates**: Pin to the certificate's public key rather than the whole certificate to avoid issues regarding expiration and renewals. -- **Consistent Enforcement**: Apply pinning uniformly for all connections to servers that you control. +- **Enforce Pinning Consistently**: Apply pinning uniformly for all connections to servers that you control. - **Regularly Update Pins**: Keep the pinned certificates or public keys up to date with the server's current configuration and have a process for updating the app when changes occur. - **Implement Backup Pins**: Include backup pins (hashes of additional trusted public keys) to prevent connectivity issues if the primary key changes. diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0030.md b/weaknesses/MASVS-PLATFORM/MASWE-0030.md index 68ba916..e9fbdc8 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0030.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0030.md @@ -13,32 +13,32 @@ mappings: refs: - https://developer.android.com/about/versions/14/features/screenshot-detection status: new - --- ## Overview -Mobile platforms allow users and third-party tools to capture screenshots or record screens. This can expose sensitive data and increase the risk of data leakage. +This weakness occurs when sensitive data displayed by the app can be captured in screenshots or screen recordings, or persists in system-generated snapshots, without the app preventing or redacting it. + +Mobile platforms allow users, other apps, and external tools to capture screenshots or record the screen. In addition, when an app enters the background, the system may capture a snapshot of the app's current view to display in the app switcher, and store it on the file system. Any sensitive content visible on screen at that moment can end up in these images. -There are several ways an attacker may obtain this sensitive data: +## Modes of Introduction -- **Third-party apps with permission to capture or record the screen**: Third-party apps may record the screen while sensitive content is displayed. -- **Third-party apps with permission to access the screenshot and recording files**: Third-party apps may access screenshots or recordings saved in storage after they are taken by the user or a tool. -- **External tools may record the screen**: Tools such as @MASTG-TOOL-0024 and @MASTG-TOOL-0126 can record the device's screen via a USB connection. -- **Automatic Screenshots when Backgrounding**: When an app enters the background state, the system may capture a screenshot of the app's current view to display in the app switcher. These screenshots are stored on the file system and could potentially be accessed or stolen by malicious actors. +- **Screenshots and Screen Recordings Not Prevented**: Not implementing measures (such as setting secure window flags) to prevent the operating system or other apps from capturing screenshots or screen recordings of sensitive views. +- **Unredacted Sensitive On-Screen Content**: Displaying sensitive information directly on the screen without masking or redacting it, including in the view snapshot the system takes when the app moves to the background. ## Impact -- **Loss of Confidentiality**: Under certain conditions, an attacker could access sensitive data previously displayed on the screen, potentially compromising confidentiality and enabling further attacks, such as identity theft or account takeover. +Attackers can access sensitive data displayed on the screen by: -## Modes of Introduction +- Capturing or recording the screen from another app or an external tool. +- Accessing shared or external storage from any app holding the corresponding permissions. +- Accessing screenshots automatically taken by the system, e.g., when the app moves to the background. -This can typically occur in two ways: +This can lead to: -- **Screenshots and Screen Recordings Not Prevented:** The app does not implement measures (such as setting secure window flags) to prevent the operating system or other apps from capturing screenshots or screen recordings. -- **Unredacted Sensitive On-Screen Content:** The app displays sensitive information directly on the screen without masking or redacting it, allowing confidential data to be visible if a screenshot or screen recording is taken. +- **Compromise of Sensitive Data**: Attackers can obtain sensitive data previously displayed on the screen, such as account details, personal information, or one-time codes, resulting in unauthorized disclosure and enabling further attacks such as identity theft or account takeover. ## Mitigations -- Prevent screenshots and screen recording. -- Redact sensitive on-screen content so that, if a screenshot is taken, no confidential data is visible. +- **Prevent Screenshots and Screen Recording**: Mark views containing sensitive data as secure so the system blocks screenshots and screen recordings of them. +- **Redact Sensitive On-Screen Content**: Mask or redact sensitive content in the UI and replace or obscure the view before the system captures the background snapshot, so no confidential data is visible in captured images. diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0065.md b/weaknesses/MASVS-PRIVACY/MASWE-0065.md index 7bea17d..319cfff 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0065.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0065.md @@ -3,10 +3,9 @@ title: Lack of Anonymization or Pseudonymisation Measures id: MASWE-0065 alias: anonymization-pseudonymization-measures requirement: "The app uses anonymization or pseudonymisation measures." -platform: ["android", "ios"] -profiles: ["P"] +platform: [android, ios] +profiles: [P] mappings: - masvs-v1: [] masvs-v2: [MASVS-PRIVACY-2] cwe: [359] maswe-beta: [MASWE-0109] @@ -22,19 +21,26 @@ status: new ## Overview -The absence of unlinkability techniques like data abstraction, anonymization, and pseudonymization can enable the identification and tracking of users across different services and over time. Anonymization, through methods like randomization or generalization, irreversibly de-identifies individuals by removing or altering data, such as obfuscating location or scrambling sensitive attributes. In contrast, pseudonymization replaces identifiable data with tokens or hashed values, making it more secure but still technically reversible under certain conditions. +This weakness occurs when an app processes or shares user data without applying unlinkability techniques such as data abstraction, anonymization, or pseudonymization, allowing individuals to be identified and tracked across different services and over time. -This lack of privacy safeguards can result in unauthorized profiling, targeted advertising without consent, and potential legal liabilities due to non-compliance with privacy regulations. +Anonymization, through methods like randomization or generalization, irreversibly de-identifies individuals by removing or altering data, such as obfuscating location or scrambling sensitive attributes. In contrast, pseudonymization replaces identifiable data with tokens or hashed values, making it more secure but still technically reversible under certain conditions. ## Modes of Introduction -- **Lack of Anonymization or Pseudonymization Measures**: Failure to remove direct identifiers, such as user ID or name, from data before server-side collection, or to manipulate the data to prevent linkage to real-world identities. This also includes not implementing protocols like Private Information Retrieval or Oblivious HTTP (OHTTP) to enhance privacy. -- **Sensitive Data Not Redacted Before Passing to AI**: Sending unredacted sensitive or personal data to AI/ML services (on-device or cloud) without first removing or masking identifiers. Beyond the immediate disclosure, the data may be retained and used to train models, making the exposure difficult to reverse. +- **Direct Identifiers Not Removed**: Failing to remove or transform direct identifiers, such as user ID or name, before server-side collection, or to manipulate the data to prevent linkage to real-world identities. This also includes not implementing protocols like Private Information Retrieval or Oblivious HTTP (OHTTP) to enhance privacy. +- **Sensitive Data Not Redacted Before Passing to AI**: Sending unredacted sensitive or personal data to AI/ML services (on-device or cloud) without first removing or masking identifiers, where it may also be retained and used to train models. ## Impact -- **Violation of User Privacy**: Users may not be aware that their personal information is being collected for tracking purposes, leading to privacy infringement. -- **Compliance and Legal Risks**: Breach of data protection laws and regulations (like GDPR), resulting in legal consequences and fines. +Apps and embedded third-party components, as well as any party that later obtains the collected data, can identify and track users by: + +- Linking directly identifiable data to real-world identities. +- Collecting and correlating identifiers and usage data across apps, devices, and services. + +This can lead to: + +- **Violation of User Privacy**: Third parties can profile users and target them with advertising without consent, resulting in the loss of users' control over their personal information and its unforeseen use, e.g. to train AI models. +- **Legal and Regulatory Non-Compliance**: Processing personal data without de-identification safeguards can violate data protection laws and regulations (like GDPR), resulting in legal consequences and fines for the app owner. ## Mitigations diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0066.md b/weaknesses/MASVS-PRIVACY/MASWE-0066.md index fc1a7c0..4e85168 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0066.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0066.md @@ -3,10 +3,9 @@ title: Incorrect Use of Identifiers for User Tracking id: MASWE-0066 alias: unique-identifiers-user-tracking requirement: "The app does not use persistent or unique identifiers in a way that enables user tracking." -platform: ["android", "ios"] -profiles: ["P"] +platform: [android, ios] +profiles: [P] mappings: - masvs-v1: [] masvs-v2: [MASVS-PRIVACY-2] cwe: [359] maswe-beta: [MASWE-0110] @@ -30,30 +29,37 @@ status: new ## Overview -User tracking in mobile applications involves collecting and analyzing data to monitor user behavior, preferences, and movements. This enables companies to recognize and follow users over time and across different apps, devices, and services. Such tracking often occurs without the user's explicit knowledge or consent, leading to significant privacy concerns. +This weakness occurs when an app uses persistent or unique identifiers in a way that enables users to be recognized and followed over time and across different apps, devices, and services, often without their knowledge or consent. -Mobile apps commonly include embedded utilities or third-party SDKs from companies like Google, Meta (formerly Facebook), X (formerly Twitter), and others. Examples of these utilities include analytics tools, ad networks, and social media integration components. These components can collect data not directly related to the app's functionality, potentially accessing sensitive information like contact lists or location history, depending on the permissions granted. Pre-installed apps by device manufacturers can further complicate the issue, as they may engage in invasive data collection without users' knowledge. +Mobile apps commonly include embedded utilities or third-party SDKs, such as analytics tools, ad networks, and social media integration components, from companies like Google or Meta. These components can collect data not directly related to the app's functionality, potentially accessing sensitive information like contact lists or location history, depending on the permissions granted. Pre-installed apps by device manufacturers can further complicate the issue, as they may engage in invasive data collection without users' knowledge. -One common method of tracking is through the use of unique identifiers, especially those that cannot be reset. When combined with data from multiple apps, these identifiers can be used to create detailed profiles of individuals—estimating interests, health status, sexual orientation, and other personal attributes. This information can be utilized for targeted advertising, personalized content delivery, or even to influence political opinions. +Unique identifiers, especially those that cannot be reset, are a key enabler of this tracking. When combined with data from multiple apps, they can be used to create detailed profiles of individuals, estimating interests, health status, sexual orientation, and other personal attributes, which can then be used for targeted advertising, personalized content delivery, or even to influence political opinions. ## Modes of Introduction -- **Use of Non-Resettable Identifiers**: Utilizing identifiers that cannot be reset by the user, such as device IDs, hardware serial numbers, or MAC addresses, can lead to persistent tracking without user consent. For example, the [ANDROID_ID](https://developer.android.com/reference/android/provider/Settings.Secure#ANDROID_ID) before Android 8.0 (API level 26) was a non-resettable identifier randomly generated at first boot, while in recent versions it's unique to each combination of app-signing key, user, and device. -- **Misuse of Resettable Identifiers**: Using [resettable identifiers](https://developer.android.com/privacy-and-security/about#resettable-identifiers) like the [Advertising ID](https://developer.android.com/identity/user-data-ids#advertising-ids) on Android or [Advertising Identifier (aka. Identifier for Advertiseers or IDFA)](https://developer.apple.com/documentation/adsupport/asidentifiermanager/advertisingidentifier) on iOS without respecting user preferences or obtaining proper consent can lead to unauthorized tracking. -- **Linking Identifiers Across Services**: Linking identifiers across different services or apps to create a unified profile of a user, even after a reset or reinstall. This can be done by combining identifiers from different sources, such as device IDs, advertising IDs, or other unique identifiers as well as behavioral data. +- **Use of Non-Resettable Identifiers**: Utilizing identifiers that cannot be reset by the user, such as device IDs, hardware serial numbers, or MAC addresses. For example, the [ANDROID_ID](https://developer.android.com/reference/android/provider/Settings.Secure#ANDROID_ID) before Android 8.0 (API level 26) was a non-resettable identifier randomly generated at first boot, while in recent versions it's unique to each combination of app-signing key, user, and device. +- **Misuse of Resettable Identifiers**: Using [resettable identifiers](https://developer.android.com/privacy-and-security/about#resettable-identifiers) like the [Advertising ID](https://developer.android.com/identity/user-data-ids#advertising-ids) on Android or the [Advertising Identifier (aka. Identifier for Advertisers or IDFA)](https://developer.apple.com/documentation/adsupport/asidentifiermanager/advertisingidentifier) on iOS without respecting user preferences or obtaining proper consent. +- **Linking Identifiers Across Services**: Combining identifiers from different sources, such as device IDs, advertising IDs, or other unique identifiers as well as behavioral data, to create a unified profile of a user, even after a reset or reinstall. - **Tracking Without User Consent**: Tracking users across services or apps without their explicit consent or without providing the ability to opt out or reset identifiers. For instance, on iOS, access to the IDFA requires explicit user consent under the [App Tracking Transparency (ATT) framework](https://developer.apple.com/documentation/AppTrackingTransparency). The IDFV can track users across apps by the same vendor without explicit consent but resets when all of the vendor's apps are removed from the device. ## Impact -- **Loss of User Trust**: Users are likely to lose trust in an app that lacks transparency in how unique identifiers are used for tracking, which may lead to negative reviews, decreased engagement, and reduced retention rates. -- **Violation of User Privacy**: Users may not be fully aware of the implications when accepting tracking, such as the collection of unique identifiers or usage patterns. In some cases, tracking may be mandatory to use an app, leaving users without a real choice. This can lead to privacy violations, unauthorized use of their information, and an erosion of user control over their data. -- **Compliance and Legal Risks**: Violation of data protection laws and regulations (like GDPR), resulting in legal consequences, fines, and potential non-compliance with platform guidelines, which may lead to app store removal. +Apps and embedded third-party components can track users across apps, devices, and services by: + +- Collecting non-resettable identifiers or misusing resettable ones. +- Collecting and correlating identifiers and usage data across apps, devices, and services. + +This can lead to: + +- **Violation of User Privacy**: Third parties can build detailed profiles of individuals, estimating interests, health status, sexual orientation, and other personal attributes, resulting in users losing control over their personal information and being subject to unwanted targeting or profiling. +- **Loss of User Trust**: Users can discover undisclosed tracking, resulting in negative reviews, decreased engagement, and reduced retention for the app owner. +- **Legal and Regulatory Non-Compliance**: Tracking users without valid consent can violate data protection laws (like GDPR) and platform guidelines, resulting in fines, legal action, or app store removal for the app owner. ## Mitigations -- **Use Resettable Identifiers**: Prefer [resettable identifiers](https://developer.android.com/privacy-and-security/about#resettable-identifiers) like the [Advertising ID](https://developer.android.com/identity/user-data-ids#advertising-ids) on Android or [Advertising Identifier (aka. Identifier for Advertiseers or IDFA)](https://developer.apple.com/documentation/adsupport/asidentifiermanager/advertisingidentifier) on iOS, for purposes like analytics or personalized advertising. Always respect user preferences and consent regarding tracking and data collection. Avoid using hardware-based identifiers like device IDs or MAC addresses. -- **Use App-Scoped Identifiers**: Use app-scoped identifiers to maintain user privacy and prevent cross-service tracking. Examples include [**ANDROID_ID** (on Android 8.0 (API level 26) and higher)](https://developer.android.com/about/versions/oreo/android-8.0-changes#privacy-all), **Firebase Installation IDs (FIDs)**, or privately stored Globally Unique IDs (GUIDs). On iOS, consider using **Identifier for Vendors (IDFV)** to track users across apps by the same vendor and resets when all the vendor's apps are uninstalled. +- **Use Resettable Identifiers**: Prefer [resettable identifiers](https://developer.android.com/privacy-and-security/about#resettable-identifiers) like the [Advertising ID](https://developer.android.com/identity/user-data-ids#advertising-ids) on Android or the [Advertising Identifier (aka. Identifier for Advertisers or IDFA)](https://developer.apple.com/documentation/adsupport/asidentifiermanager/advertisingidentifier) on iOS, for purposes like analytics or personalized advertising. Always respect user preferences and consent regarding tracking and data collection. Avoid using hardware-based identifiers like device IDs or MAC addresses. +- **Use App-Scoped Identifiers**: Use app-scoped identifiers to maintain user privacy and prevent cross-service tracking. Examples include [**ANDROID_ID** (on Android 8.0 (API level 26) and higher)](https://developer.android.com/about/versions/oreo/android-8.0-changes#privacy-all), **Firebase Installation IDs (FIDs)**, or privately stored Globally Unique IDs (GUIDs). On iOS, consider using the **Identifier for Vendors (IDFV)**, which tracks users only across apps by the same vendor and resets when all the vendor's apps are uninstalled. - **Use Advertising ID Appropriately**: Restrict advertising ID usage to ad-serving and user profiling contexts, respecting user preferences on ad tracking. Avoid linking identifiers after a reset without explicit user consent, ensuring a fresh start. On Android, [use the **Advertising ID** appropriately](https://support.google.com/googleplay/android-developer/answer/9857753#ad-id), and on iOS, comply with **App Tracking Transparency (ATT)** by [requesting user permission](https://developer.apple.com/documentation/apptrackingtransparency/attrackingmanager/requesttrackingauthorization(completionhandler:)) before accessing the **Identifier for Advertisers (IDFA)** and avoid storing it; access [`advertisingIdentifier`](https://developer.apple.com/documentation/adsupport/asidentifiermanager/advertisingidentifier) instead. -- **Use Appropriate APIs**: Use privacy-preserving APIs instead of relying on identifiers. For example, for device verification on Android use **Play Integrity**, and on iOS use **DeviceCheck** (e.g., to identify devices that have taken advantage of a promotional offer or to flag fraudulent devices). For privacy-friendly ad attribution, use [Attribution Reporting API](https://developers.google.com/privacy-sandbox/private-advertising/attribution-reporting/android) on Android, and consider using **AdAttributionKit** or **SKAdNetwork** on iOS. +- **Use Appropriate APIs**: Use privacy-preserving APIs instead of relying on identifiers. For example, for device verification on Android use **Play Integrity**, and on iOS use **DeviceCheck** (e.g., to identify devices that have taken advantage of a promotional offer or to flag fraudulent devices). For privacy-friendly ad attribution, use the [Attribution Reporting API](https://developers.google.com/privacy-sandbox/private-advertising/attribution-reporting/android) on Android, and consider using **AdAttributionKit** or **SKAdNetwork** on iOS. - **Treat Third-Party SDKs as Your Own Code**: Be aware of any privacy or security policies associated with third-party SDKs integrated into your app, particularly those related to the use of unique identifiers. Ensure third-party SDKs comply with platform guidelines for data collection and user consent, such as Apple's App Tracking Transparency (ATT) and Google's Play Data Safety policies, to avoid misuse of identifiers and ensure transparency. - **Provide Clear Privacy Information**: Inform users about the collection and use of unique identifiers in your privacy policy, app store listing, and within the app itself. Clearly explain the purpose of tracking and how it benefits the user experience. Provide users with the ability to opt out of tracking or reset identifiers if possible. diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0067.md b/weaknesses/MASVS-PRIVACY/MASWE-0067.md index bea9bfe..b93ab2d 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0067.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0067.md @@ -3,10 +3,10 @@ title: Inadequate Privacy Policy id: MASWE-0067 alias: privacy-policy requirement: "The app provides an adequate privacy policy." -platform: ["android", "ios"] -profiles: ["P"] +platform: [android, ios] +profiles: [P] mappings: - masvs-v1: [MASVS-STORAGE-12] + masvs-v1: [MSTG-STORAGE-12] masvs-v2: [MASVS-PRIVACY-3] cwe: [359] maswe-beta: [MASWE-0111] @@ -19,23 +19,30 @@ status: new ## Overview -Mobile apps must provide users with a clear and comprehensive statement regarding how their data is collected, processed, shared, and protected. Privacy policies should be easily accessible, tailored specifically to the app in question, and written in a way that users can easily understand. Without a robust privacy policy, users are unable to make informed decisions about their data, and may be unaware of how their information is being used or shared. +This weakness occurs when an app does not provide users with a clear, accessible, and accurate statement of how their data is collected, processed, shared, and protected. -A privacy policy that is incomplete, vague, or does not match the app's behavior can mislead users and lead to a lack of transparency, resulting in potential privacy violations and legal repercussions for developers. +Privacy policies should be easily accessible, tailored specifically to the app in question, and written in a way that users can easily understand. Without a robust privacy policy, users are unable to make informed decisions about their data, and may be unaware of how their information is being used or shared. A privacy policy that is incomplete, vague, or does not match the app's behavior can mislead users and undermine transparency. ## Modes of Introduction - **Unclear or Absent Privacy Policy**: Not providing a privacy policy, or having one that is not easily accessible or clear to the user, or that doesn't specifically address the data practices of that particular app, instead being a generic document that covers multiple services. -- **Discrepancies in Policy vs Behavior**: Differences between the privacy policy and the app's actual behavior. +- **Discrepancies in Policy vs Behavior**: Collecting, processing, or sharing data in ways that differ from what the privacy policy states. ## Impact -- **Violation of User Privacy**: Users may unknowingly provide data without understanding how it will be used, exposing them to privacy risks, such as data sharing with third parties, profiling, or targeted advertising without explicit consent. -- **Loss of User Trust**: Users are more likely to lose trust in an app that lacks transparency, which may lead to negative reviews, decreased user engagement, and reduced retention rates. -- **Legal and Compliance Issues**: Failure to provide an adequate privacy policy can result in non-compliance with privacy laws and regulations, such as GDPR or CCPA, potentially leading to fines, legal action, or removal from app stores. +Apps and embedded third-party components can collect, process, or share personal data in ways users cannot anticipate by: + +- Operating without a privacy policy or under a vague, generic, or inaccessible one. +- Deviating from the practices stated in the published privacy policy. + +This can lead to: + +- **Violation of User Privacy**: Users can unknowingly provide data that is shared with third parties, used for profiling, or used for targeted advertising without explicit consent, resulting in the loss of control over their personal information. +- **Loss of User Trust**: Users can perceive the app as non-transparent, resulting in negative reviews, decreased user engagement, and reduced retention for the app owner. +- **Legal and Regulatory Non-Compliance**: Failing to provide an adequate privacy policy can violate privacy laws and regulations, such as GDPR or CCPA, resulting in fines, legal action, or removal from app stores for the app owner. ## Mitigations - **Provide a Clear Privacy Policy**: Make sure a comprehensive and understandable privacy policy is readily accessible to users. Tailor it to the specific data practices of your app and write it in clear, understandable language as stated in Article 12 of the GDPR. -- **Ensure Consistency in Privacy vs Behavior**: Keep your data collection practices documented and up to date in privacy policies, privacy labels, and app store listings. Ensure that these documents match the app's actual behavior to avoid discrepancies that could mislead users or violate platform policies. +- **Ensure Consistency in Policy vs Behavior**: Keep your data collection practices documented and up to date in privacy policies, privacy labels, and app store listings. Ensure that these documents match the app's actual behavior to avoid discrepancies that could mislead users or violate platform policies. - **Regularly Review and Update Privacy Policy**: Regularly review and update the privacy policy to reflect any changes in data collection practices, new features, or modifications to existing features that may impact how user data is handled. diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0068.md b/weaknesses/MASVS-PRIVACY/MASWE-0068.md index 759f702..2b8b465 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0068.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0068.md @@ -3,8 +3,8 @@ title: Inadequate Data Collection Declarations id: MASWE-0068 alias: data-collection-declarations requirement: "The app adequately declares all user collected data." -platform: ["android", "ios"] -profiles: ["P"] +platform: [android, ios] +profiles: [P] mappings: masvs-v1: [MSTG-STORAGE-12, MSTG-NETWORK-1] masvs-v2: [MASVS-PRIVACY-3, MASVS-PRIVACY-1] @@ -25,23 +25,30 @@ status: new ## Overview -When a mobile app's stated data collection practices, such as those documented in Apple's [App Privacy Report](https://support.apple.com/en-us/102188) and [Privacy Nutrition Labels](https://support.apple.com/kb/HT211970), or Google's [Data Safety section](https://support.google.com/googleplay/android-developer/answer/10787469?hl=en), are incomplete or inconsistent with the app's actual behavior, users are prevented from making informed decisions about their privacy, including understanding whether data will be linked to their identity, used for tracking, or shared with third parties. +This weakness occurs when an app's stated data collection practices, such as those documented in Apple's [App Privacy Report](https://support.apple.com/en-us/102188) and [Privacy Nutrition Labels](https://support.apple.com/kb/HT211970), or Google's [Data Safety section](https://support.google.com/googleplay/android-developer/answer/10787469?hl=en), are incomplete or inconsistent with the app's actual behavior. -These declarations must clearly outline what data is collected, how it is used, whether it is linked to the user's identity, and whether it is shared with third parties in accordance with the platform's policies. +These declarations must clearly outline what data is collected, how it is used, whether it is linked to the user's identity, and whether it is shared with third parties in accordance with the platform's policies. When they are inaccurate, users are prevented from making informed decisions about their privacy, including understanding whether data will be linked to their identity, used for tracking, or shared with third parties. **Note about third-party libraries (SDKs)**: Developers, as data controllers, are legally responsible for ensuring that third-party components process sensitive data lawfully, fairly, and transparently, as highlighted in the [ENISA study on GDPR compliance](https://www.enisa.europa.eu/sites/default/files/publications/WP2017%20O-2-2-4%20GDPR%20Mobile.pdf) (Section 2.2.7, _"Data transfers and processing by third parties"_). However, in some cases, it may be challenging for mobile app developers to be fully aware of what data these third-party SDKs actually collect. ## Modes of Introduction -- **Undeclared Data Collection and Purpose**: Failing to declare what data is being collected (e.g., location, contacts, identifiers) and for what purposes (e.g., analytics, personalization), leaving users unaware of how their information is used. -- **Discrepancies in Declarations vs Behavior**: Differences between privacy label declarations (such as Apple's Privacy Nutrition Labels or Google's Data Safety Section) and the app's actual behavior, including undeclared data collection, sharing with third parties not mentioned in privacy labels, or using data for purposes not disclosed, which are against both Apple and Google guidelines. -- **Undeclared Data Sent in Network Traffic**: Data actually transmitted over the network, even over HTTPS, that goes beyond what is declared, such as over-collection beyond functional needs, sending detailed location/behavior analytics, unnecessary identifiers (e.g. IMEI, email, phone number), or sharing with third-party analytics/advertising services not reflected in the declarations. +- **Undeclared Data Collection and Purpose**: Failing to declare what data is being collected (e.g., location, contacts, identifiers) and for what purposes (e.g., analytics, personalization). +- **Discrepancies in Declarations vs Behavior**: Publishing privacy label declarations (such as Apple's Privacy Nutrition Labels or Google's Data Safety Section) that differ from the app's actual behavior, including undeclared data collection, sharing with third parties not mentioned in privacy labels, or using data for purposes not disclosed, which are against both Apple and Google guidelines. +- **Undeclared Data Sent in Network Traffic**: Transmitting data over the network, even over HTTPS, that goes beyond what is declared, such as over-collection beyond functional needs, detailed location/behavior analytics, unnecessary identifiers (e.g. IMEI, email, phone number), or sharing with third-party analytics/advertising services not reflected in the declarations. ## Impact -- **Violation of User Privacy**: Users may unknowingly share data without fully understanding its purpose, which can lead to unauthorized sharing, profiling, or targeted advertising. -- **Loss of User Trust**: Inconsistent declarations can result in users losing trust in the app, leading to negative reviews, lower user engagement, and reduced retention. -- **Legal and Compliance Issues**: Inaccurate or inconsistent data declarations may lead to non-compliance with regulations like GDPR or CCPA, resulting in potential fines, legal action, or removal from app stores. +Apps and embedded third-party components can collect or share more data than users were led to expect by: + +- Collecting or sharing data categories that are not declared in the platform's privacy labels. +- Transmitting undeclared identifiers or analytics data to first- or third-party services over the network. + +This can lead to: + +- **Violation of User Privacy**: Users can unknowingly share data whose purpose they do not understand, resulting in unauthorized sharing, profiling, or targeted advertising. +- **Loss of User Trust**: Users can discover the inconsistent declarations, resulting in negative reviews, lower user engagement, and reduced retention for the app owner. +- **Legal and Regulatory Non-Compliance**: Inaccurate or inconsistent data declarations can violate regulations like GDPR or CCPA and platform policies, resulting in fines, legal action, or removal from app stores for the app owner. ## Mitigations diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0069.md b/weaknesses/MASVS-PRIVACY/MASWE-0069.md index f251b8b..f8b975f 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0069.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0069.md @@ -3,10 +3,9 @@ title: Lack of Proper Data Management Controls id: MASWE-0069 alias: data-management-controls requirement: "The app provides adequate controls to manage user data." -platform: ["android", "ios"] -profiles: ["P"] +platform: [android, ios] +profiles: [P] mappings: - masvs-v1: [] masvs-v2: [MASVS-PRIVACY-4] cwe: [359] maswe-beta: [MASWE-0113] @@ -17,22 +16,28 @@ status: new ## Overview -When mobile apps do not provide users with mechanisms specifically designed to manage their personal data, users are left without adequate options to manage their information. This limits users' rights over their own data, leading to privacy concerns, increased severity of potential data breaches, and potential non-compliance with privacy regulations. +This weakness occurs when an app does not provide users with mechanisms specifically designed to manage their personal data, leaving them without adequate options to exercise their rights over their own information. These mechanisms typically include the ability for users to delete, export, modify, or opt out of data collection directly within the app interface. For example, some apps provide data management features within the settings menu, while others provide a link to an external website where users can manage their data. ## Modes of Introduction -- **Lack of Proper Data Management Settings**: Failing to provide users with the ability to delete, export, modify, or opt out of data collection, resulting in users having limited or no control over their personal data. +- **Lack of Proper Data Management Settings**: Failing to provide users with the ability to delete, export, modify, or opt out of data collection. ## Impact -- **Violation of User Rights**: Users may be unable to exercise their rights to manage their personal data, such as deleting or exporting their information, leading to a lack of control and increased privacy risks. -- **Non-Compliance with Privacy Regulations**: Non-compliance with regulations like GDPR and CCPA, which require providing users with data management capabilities, can result in fines, legal action, and other consequences. -- **Loss of User Trust**: Users may lose trust in an app that does not allow them to manage their personal data, which can lead to negative reviews, decreased user engagement, and reduced retention. +Apps and their backend services can retain and process personal data beyond the user's control by: + +- Providing no way for users to delete, export, modify, or opt out of the collection of their data. + +This can lead to: + +- **Violation of User Privacy**: Users cannot exercise their rights to manage their personal data, such as deleting or exporting their information, resulting in the loss of control over their data and an increased amount of exposed data if a breach occurs. +- **Loss of User Trust**: Users can perceive that they have no control over their personal data, resulting in negative reviews, decreased user engagement, and reduced retention for the app owner. +- **Legal and Regulatory Non-Compliance**: Failing to provide data management capabilities required by regulations like GDPR and CCPA can result in fines, legal action, and other consequences for the app owner. ## Mitigations - **Implement Data Management Mechanisms**: Ensure that mechanisms are in place for users to delete, export, or modify their data. Provide granular controls for specific aspects of data collection and sharing (e.g., location services, contacts, media access). - **Regularly Update Data Management Features**: Regularly review and update data management features to ensure compliance with evolving regulations and user expectations. This helps maintain transparency and user trust. -- **User-Friendly Data Management Interface**: Create a user-friendly interface for data management controls, ensuring that users can easily navigate and exercise their rights over their personal data without friction. +- **Provide a User-Friendly Data Management Interface**: Create a user-friendly interface for data management controls, ensuring that users can easily navigate and exercise their rights over their personal data without friction. diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0070.md b/weaknesses/MASVS-PRIVACY/MASWE-0070.md index af4ede8..dbdb6d0 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0070.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0070.md @@ -3,10 +3,9 @@ title: Inadequate Data Visibility Controls id: MASWE-0070 alias: data-visibility-control requirement: "The app provides adequate controls over the visibility of user data." -platform: ["android", "ios"] -profiles: ["P"] +platform: [android, ios] +profiles: [P] mappings: - masvs-v1: [] masvs-v2: [MASVS-PRIVACY-4] cwe: [359] maswe-beta: [MASWE-0114] @@ -18,23 +17,30 @@ status: new ## Overview -If mobile apps do not give users sufficient control over how their personal information is shared with other users or the broader environment, users may inadvertently disclose sensitive data, leading to privacy concerns and unwanted attention from other users or third parties. Examples of such information include last connection status, read receipts, birthday, email address, or discoverability settings. +This weakness occurs when an app does not give users sufficient control over how their personal information is shared with other users or the broader environment. -Ensuring that users have clear and granular options, typically in the form of app settings, to control data visibility is critical to maintaining their privacy and building trust in the app. +Examples of such information include last connection status, read receipts, birthday, email address, or discoverability settings. Ensuring that users have clear and granular options, typically in the form of app settings, to control data visibility is critical to maintaining their privacy and building trust in the app. ## Modes of Introduction -- **Lack of Granular Privacy Settings**: Failing to provide privacy settings with sufficient granularity to allow users to control specific aspects of data collection and sharing, such as differentiating between location services, contacts, or media access. This lack of control results in users being unable to decide which types of information are shared and with whom. -- **Oversharing by Default**: Sharing flows that expose more than the user intends because privacy-reducing options are off by default or hard to find. For example, forwarding a message or picture that reveals the original sender's name unless the user explicitly enables an option such as "Hide Sender Name". +- **Lack of Granular Privacy Settings**: Failing to provide privacy settings with sufficient granularity to allow users to control specific aspects of data collection and sharing, such as differentiating between location services, contacts, or media access, or to decide which types of information are shared and with whom. +- **Oversharing by Default**: Designing sharing flows that expose more than the user intends because privacy-reducing options are off by default or hard to find. For example, forwarding a message or picture that reveals the original sender's name unless the user explicitly enables an option such as "Hide Sender Name". ## Impact -- **Exposure of Personal Data**: Users may unintentionally expose personal information, such as their email address, birthday, or online status, to others without their consent, increasing the risk of harassment or identity theft. -- **Non-Compliance with Privacy Regulations**: Apps that do not offer sufficient privacy controls may face non-compliance issues with regulations like GDPR or CCPA, which require user control over data visibility and sharing. -- **Loss of User Trust**: Users may lose trust in the app if they feel they have inadequate control over what information is shared and with whom, leading to negative reviews and decreased app engagement. +Apps and their users' counterparts can expose personal information beyond the user's intent by: + +- Making profile details, activity status, or discoverability visible to other users or third parties by default. +- Exporting or sharing data through flows whose privacy consequences are not evident to the user. + +This can lead to: + +- **Violation of User Privacy**: Users can unintentionally expose personal information, such as their email address, birthday, or online status, to others without their consent, resulting in an increased risk of harassment, stalking, or identity theft. +- **Loss of User Trust**: Users can feel they have inadequate control over what information is shared and with whom, resulting in negative reviews and decreased app engagement for the app owner. +- **Legal and Regulatory Non-Compliance**: Failing to offer sufficient privacy controls can violate regulations like GDPR or CCPA, which require user control over data visibility and sharing, resulting in fines or legal action for the app owner. ## Mitigations - **Offer Granular Privacy Settings**: Provide privacy settings with sufficient granularity, allowing users to control individual data collection categories (e.g., location, contacts) and manage their sharing preferences. Allow users to choose what information is visible to others, such as connection status or discoverability. -- **User Education on Privacy Options**: Clearly inform users about available privacy settings and how to use them effectively to manage data visibility. This can be done through tutorials, help sections, or contextual tips within the app. -- **Default Privacy-Friendly Settings**: Set default privacy settings to the most restrictive options, allowing users to opt-in to sharing specific information rather than having to opt-out, which helps to ensure user privacy by default. +- **Educate Users on Privacy Options**: Clearly inform users about available privacy settings and how to use them effectively to manage data visibility. This can be done through tutorials, help sections, or contextual tips within the app. +- **Default to Privacy-Friendly Settings**: Set default privacy settings to the most restrictive options, allowing users to opt in to sharing specific information rather than having to opt out, which helps to ensure user privacy by default. diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0071.md b/weaknesses/MASVS-PRIVACY/MASWE-0071.md index 672829d..e61bbcd 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0071.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0071.md @@ -3,10 +3,9 @@ title: Inadequate or Ambiguous User Consent Mechanisms id: MASWE-0071 alias: ambiguous-consent-mechanisms requirement: "The app requests user consent prior to any data processing." -platform: ["android", "ios"] -profiles: ["P"] +platform: [android, ios] +profiles: [P] mappings: - masvs-v1: [] masvs-v2: [MASVS-PRIVACY-4] cwe: [200, 285, 358, 359] maswe-beta: [MASWE-0115, MASWE-0060] @@ -19,23 +18,31 @@ status: new ## Overview -According to various international privacy regulations, such as the [EU's GDPR](https://gdpr-info.eu/art-7-gdpr/), [California's CCPA](https://cppa.ca.gov/regulations/pdf/cppa_act.pdf), [Brazil's LGPD](https://lgpd-brazil.info/chapter_02/article_08), and [Canada's PIPEDA](https://www.priv.gc.ca/en/privacy-topics/privacy-laws-in-canada/the-personal-information-protection-and-electronic-documents-act-pipeda/p_principle/principles/p_consent/), user consent must be explicit, informed, and obtained prior to any data processing. Users must be made fully aware of the purposes of the data collection, as well as the potential consequences of providing consent. In addition, consent should be an active choice, specific to the data being processed, and not bundled with other service agreements or presented in a vague or coercive manner. +This weakness occurs when an app processes personal data without obtaining consent that is explicit, informed, and given prior to the processing, or when the consent request is vague, bundled, or coercive. -Mobile apps that fail to follow these principles often result in users unknowingly consenting to data collection or processing that could pose significant risks to their fundamental rights and freedoms. For example, apps may use vague or non-negotiable consent requests, pressuring users to provide consent without fully understanding the implications. +According to various international privacy regulations, such as the [EU's GDPR](https://gdpr-info.eu/art-7-gdpr/), [California's CCPA](https://cppa.ca.gov/regulations/pdf/cppa_act.pdf), [Brazil's LGPD](https://lgpd-brazil.info/chapter_02/article_08), and [Canada's PIPEDA](https://www.priv.gc.ca/en/privacy-topics/privacy-laws-in-canada/the-personal-information-protection-and-electronic-documents-act-pipeda/p_principle/principles/p_consent/), users must be made fully aware of the purposes of the data collection, as well as the potential consequences of providing consent. Consent should be an active choice, specific to the data being processed, and not bundled with other service agreements or presented in a vague or coercive manner. In addition, users must be able to easily withdraw their consent at any time and should be clearly informed of how to do so, including the potential impact on the functionality of the app. Developers must maintain a record of user consent and ensure that consent requests are clear, separate from other terms, and legally valid, and avoid practices that obscure the full scope of data processing. ## Modes of Introduction - **Failure to Prompt for Consent Changes**: Failing to prompt the user for consent when data collection practices change or when additional data is collected beyond what was originally specified. -- **Ambiguous Consent Mechanisms**: Consent is bundled with terms of service, often covering future use cases without notifying the user again. In some cases, consent is implied if the user doesn't explicitly deny access, leading to data collection without clear approval. -- **Lack of User Awareness When Exporting Data**: Sharing or exporting flows that do not make the user aware of the privacy consequences of their action. Users are generally free to share whatever they want, but they should be made aware of the risks. For example, when a user "Saves" a picture, warning them that the data will be exported to public/shared storage, or when using the iOS share sheet (`UIActivity`), being explicit about which items are shared and excluding activity types that would leak data to untrusted apps. +- **Ambiguous Consent Mechanisms**: Bundling consent with terms of service, often covering future use cases without notifying the user again, or implying consent when the user doesn't explicitly deny access. +- **Lack of User Awareness When Exporting Data**: Designing sharing or exporting flows that do not make the user aware of the privacy consequences of their action. For example, when a user "Saves" a picture, not warning them that the data will be exported to public/shared storage, or when using the share sheet, not being explicit about which items are shared. ## Impact -- **Violation of User Privacy**: When ambiguous consent mechanisms are used, user privacy is severely compromised as users may unknowingly give up control over their data. This exposes them to the risk of their information being used without clear or informed consent for purposes they may find objectionable or harmful, such as targeted advertising, profiling, discrimination or even identity theft. -- **Loss of User Trust**: Users may lose trust in the app and abandon it, share negative reviews, or discourage others from using it, leading to reputational damage and potential loss of business. -- **Legal and Compliance Issues**: Non-compliance with laws and platform requirements can result in legal consequences, fines, or removal from app stores. +Apps and embedded third-party components can process personal data without valid user consent by: + +- Collecting data under consent that is bundled, implied, or otherwise not freely and specifically given. +- Continuing to collect data under an outdated consent after practices have changed. +- Exporting or sharing data through flows whose privacy consequences are not evident to the user. + +This can lead to: + +- **Violation of User Privacy**: Users can unknowingly give up control over their data, resulting in its use for purposes they may find objectionable or harmful, such as targeted advertising, profiling, discrimination, or even identity theft. +- **Loss of User Trust**: Users can lose trust in the app and abandon it, share negative reviews, or discourage others from using it, resulting in reputational damage and potential loss of business for the app owner. +- **Legal and Regulatory Non-Compliance**: Processing data without valid consent can violate laws and platform requirements, resulting in legal consequences, fines, or removal from app stores for the app owner. ## Mitigations diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0072.md b/weaknesses/MASVS-PRIVACY/MASWE-0072.md index 8822656..dd48336 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0072.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0072.md @@ -3,10 +3,9 @@ title: Inadequate Permission Management id: MASWE-0072 alias: inadequate-permission-management requirement: "The app adequately manages permissions." -platform: ["android", "ios"] -profiles: ["P"] +platform: [android, ios] +profiles: [P] mappings: - masvs-v1: [] masvs-v2: [MASVS-PRIVACY-1] cwe: [250] maswe-beta: [MASWE-0117] @@ -26,41 +25,39 @@ status: new ## Overview -Permissions control access to sensitive device features such as the camera, microphone, location, and storage, making them a crucial aspect of mobile app privacy. Proper permission management is essential to protect user privacy and comply with regulations, as permissions serve as the gateway for data collection and processing. +This weakness occurs when an app requests more permissions than it needs, keeps permissions it no longer needs, or fails to explain why permissions are required. -### First-party Apps +Permissions control access to sensitive device features such as the camera, microphone, location, and storage, making them a crucial aspect of mobile app privacy. They serve as the gateway for data collection and processing, so proper permission management is essential to protect user privacy and comply with regulations. -First-party apps may request more permissions than necessary, sometimes overlooking privacy-friendly alternatives due to a lack of awareness, technical constraints, or business needs. Developers face the challenge of balancing functionality with privacy: while some permissions are essential for core features (e.g., a camera app requiring camera access), excessive permissions can lead to unnecessary data collection and potential privacy violations. +Developers face the challenge of balancing functionality with privacy: while some permissions are essential for core features (e.g., a camera app requiring camera access), excessive permissions enable unnecessary data collection. From the user's perspective, privacy concerns may lead to reluctance in granting permissions, forcing them to choose between privacy and app functionality, while other users may grant permissions without fully understanding the implications. Pre-installed apps aggravate the problem, as they frequently come with excessive permissions that are granted by default and that users cannot control or revoke. -From the user's perspective, privacy concerns may lead to reluctance in granting permissions, forcing them to choose between privacy and app functionality as in some cases, refusing to grant permissions could render the app unusable. Conversely, users may grant permissions without fully understanding the implications, resulting in unintended data exposure. - -### Pre-installed Apps - -Pre-installed apps frequently come with excessive permissions that users cannot control or revoke, as they are often granted by default without explicit consent. This lack of control can result in continuous data collection and persistent privacy risks. - -### Third-party Libraries (SDKs) - -**Third-party libraries (SDKs)** further complicate permission management by inheriting app permissions and introducing privacy and security risks that are difficult to audit and control. Mobile permission models often fail to distinguish between permissions granted to an app and those assigned to third-party components, a challenge highlighted in the [IEEE research paper "Engineering Privacy in Smartphone Apps"](https://ieeexplore.ieee.org/document/9001128) (Section IV, _"Third-party content"_). Furthermore, third-party services behind these SDKs may continue accessing data collected over the network even after permissions are revoked or the app is deleted, creating long-term risks for user privacy. +Third-party libraries (SDKs) further complicate permission management by inheriting app permissions and introducing privacy and security risks that are difficult to audit and control. Mobile permission models often fail to distinguish between permissions granted to an app and those assigned to third-party components, a challenge highlighted in the [IEEE research paper "Engineering Privacy in Smartphone Apps"](https://ieeexplore.ieee.org/document/9001128) (Section IV, _"Third-party content"_). Furthermore, third-party services behind these SDKs may continue accessing data collected over the network even after permissions are revoked or the app is deleted. ## Modes of Introduction -- **Requesting Excessive Permissions**: Apps requesting more permissions than necessary for their core functionality. -- **Lack of Use of Privacy-Friendly Alternatives**: Failing to use privacy-friendly alternatives to permissions that are less intrusive and provide users with more control over their data. For example, using coarse location instead of fine location, or using an image picker instead of requesting access to the camera and photo gallery. -- **Lack of Proactive Permission Revocation**: Not automatically revoking app permissions that are no longer necessary, resulting in unnecessary data access over time. +- **Requesting Excessive Permissions**: Requesting more permissions than necessary for the app's core functionality. +- **Lack of Use of Privacy-Friendly Alternatives**: Failing to use privacy-friendly alternatives that are less intrusive than permissions. For example, using coarse location instead of fine location, or using an image picker instead of requesting access to the camera and photo gallery. +- **Lack of Proactive Permission Revocation**: Not relinquishing or revoking permissions that are no longer necessary, resulting in unnecessary data access over time. - **Inadequate Permission Explanations**: Failing to provide clear explanations for why each permission is required. ## Impact -- **Violation of User Privacy**: Users may have their personal data unnecessarily accessed by mobile apps, leading to potential misuse, identity theft, or surveillance. -- **Loss of User Trust**: Users may lose trust in an app if it requests unnecessary permissions or does not allow them to revoke permissions that are no longer relevant. This can lead to negative reviews, lower user engagement, and reduced retention. -- **Legal and Compliance Issues**: Apps that improperly manage permissions may face non-compliance with privacy regulations like GDPR or CCPA, which require data minimization and appropriate user control over data access, resulting in potential fines, legal action, or removal from app stores. -- **Malicious Abuse:** Harmful apps can misuse permissions from privileged apps to record, track, or steal data without user consent. -- **Data Breaches:** Once sensitive data leaves the app, its security can no longer be guaranteed, increasing the risk of large-scale data exposure via data breaches. +Apps and embedded third-party components can access more sensitive device resources and data than needed by: + +- Holding excessive or no-longer-needed permissions granted to the app. +- Inheriting the app's permissions in third-party SDKs, whose data collection is difficult to audit and control. + +This can lead to: + +- **Violation of User Privacy**: Apps and embedded components can unnecessarily access personal data such as location, contacts, or media, resulting in misuse, surveillance, or profiling of the user. +- **Compromise of Sensitive Data**: Third-party services can collect and retain data obtained through inherited permissions; once that data leaves the app its security can no longer be guaranteed, resulting in an increased risk of large-scale exposure via data breaches. +- **Loss of User Trust**: Users can perceive permission requests as unjustified, resulting in refused permissions, negative reviews, lower user engagement, and reduced retention for the app owner. +- **Legal and Regulatory Non-Compliance**: Requesting or retaining unnecessary permissions can violate data minimization requirements in regulations like GDPR or CCPA, resulting in fines, legal action, or removal from app stores for the app owner. ## Mitigations -- **Enable Proactive Permission Revocation**: Automatically revoke permissions that are no longer necessary to minimize unnecessary data access over time. Ensure that users can manually revoke permissions at any time through a clear and accessible interface. +- **Limit Permissions to Essential Needs**: Ensure the app only requests permissions necessary for core functionality, avoiding the collection of unnecessary data and adhering to the principle of data minimization. - **Prefer Privacy-Friendly Alternatives**: Use privacy-friendly alternatives to permissions that are less intrusive and provide users with more control over their data. For example, use coarse location instead of fine location, or use an image picker instead of requesting access to the camera and photo gallery. -- **Limit Permissions to Essential Needs**: Ensure apps only request permissions necessary for core functionality, avoiding the collection of unnecessary data and adhering to the principle of data minimization. +- **Enable Proactive Permission Revocation**: Automatically relinquish permissions that are no longer necessary to minimize unnecessary data access over time, and ensure that users can manually revoke permissions at any time through a clear and accessible interface. - **Implement Just-in-Time Permission Requests**: Request permissions only when they are needed, providing clear explanations for why each permission is required. This approach helps build user trust and ensures users understand the implications of granting access to their data. -- **User Education on Permissions**: Educate users about why specific permissions are needed and how they can manage these permissions. Providing transparency builds user trust and ensures users understand the importance and relevance of each permission. +- **Educate Users on Permissions**: Explain why specific permissions are needed and how users can manage them. Providing transparency builds user trust and ensures users understand the importance and relevance of each permission. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0050.md b/weaknesses/MASVS-RESILIENCE/MASWE-0050.md index 18919da..a4c641f 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0050.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0050.md @@ -8,9 +8,9 @@ profiles: [R] mappings: masvs-v1: [MSTG-RESILIENCE-2] masvs-v2: [MASVS-RESILIENCE-4, MASVS-PLATFORM-2] + cwe: [489] android-risks: - https://developer.android.com/privacy-and-security/risks/android-debuggable - cwe: [489] maswe-beta: [MASWE-0067, MASWE-0074] refs: - https://developer.android.com/guide/topics/manifest/application-element @@ -21,23 +21,32 @@ status: new ## Overview -Mobile apps typically include configuration flags and mechanisms that enable debugging. While these are essential during development, leaving them enabled in production can introduce serious security risks. A debuggable app allows attackers to attach debuggers, inspect memory, manipulate execution flow, and bypass client-side controls, even on non-rooted or non-jailbroken devices. It may also expose sensitive information through verbose logging or developer tools that would otherwise be inaccessible. +This weakness occurs when debug mechanisms, such as the platform's debuggable flag or WebView content debugging, remain enabled in production builds. + +Mobile apps typically include configuration flags and mechanisms that enable debugging. While these are essential during development, leaving them enabled in production makes the app inspectable and manipulable, even on non-rooted or non-jailbroken devices, and may expose sensitive information through verbose logging or developer tools that would otherwise be inaccessible. Beyond the application-level debuggable flag, this weakness also covers WebView content debugging, which lets a remote inspector attach to the app's web content (e.g. Android's `WebView.setWebContentsDebuggingEnabled(true)` or iOS's `WKWebView.isInspectable`). Like the debuggable flag, this must be disabled in production builds. +## Modes of Introduction + +- **Misconfigured Build Settings**: Accidentally leaving the app in a debuggable state through improper selection of build variants, errors in CI/CD configurations, or mistakenly applying debug settings to production environments. +- **WebView Content Debugging Left Enabled**: Leaving WebView content debugging enabled in production (e.g. `setWebContentsDebuggingEnabled(true)` on Android or `isInspectable = true` on iOS). + ## Impact -- **Read and Modify Memory**: Attackers can read and modify the app's memory space, which can lead to the exposure of sensitive information, such as encryption keys, API keys, user credentials, or tokens that otherwise would be inaccessible since they aren't present in the app's code or stored to disk. -- **Bypassing Security Controls**: Attackers can bypass security controls, such as authentication and authorization mechanisms, by manipulating the app's execution flow. -- **Execute Unauthorized Code**: Attackers can inject and execute arbitrary code within the app's context, leading to further exploitation of the device or the app's data. For example, attackers can inject reverse engineering tools like Frida into the app even on non-rooted or non-jailbroken devices. -- **Access to Sensitive Logs**: Attackers can access logs that may contain sensitive information, such as user credentials, API keys, or other sensitive data that would otherwise be inaccessible. This can lead to further exploitation of the app or the device. +Attackers can inspect and manipulate a debuggable app at runtime, even on non-rooted or non-jailbroken devices, by: + +- Debugging the app at runtime. +- Attaching a remote inspector to the app's debuggable web content. +- Using dynamic instrumentation. -## Mode of Introduction +This can lead to: -- **Misconfigured Build Settings**: Misconfigured build settings can accidentally leave an app in a state that is debuggable, exposing it to security vulnerabilities. This can result from improper selection of build variants, errors in CI/CD configurations, or mistakenly applying debug settings to production environments. -- **WebView Content Debugging Left Enabled**: Leaving WebView content debugging enabled in production (e.g. `setWebContentsDebuggingEnabled(true)` on Android or `isInspectable = true` on iOS), allowing an attacker to inspect and manipulate the app's web content. +- **Compromise of Sensitive Data**: Attackers can read the app's memory and logs to obtain encryption keys, API keys, user credentials, or tokens that are never written to the app's code or disk, resulting in unauthorized disclosure of secrets and user data. +- **Authentication or Authorization Bypass**: Attackers can manipulate the app's execution flow to skip authentication and authorization checks, resulting in unauthorized access to protected functionality. +- **Execution of Unauthorized Code**: Attackers can inject and execute arbitrary code within the app's context, e.g. by injecting reverse engineering tools like Frida, resulting in further exploitation of the app or the device. ## Mitigations -- Ensure that the debuggable flag in the app's configuration file is not enabled for production builds. For example, by using build variants or flavours to separate debug and release configurations, ensure that the debuggable flag is enabled only for debug builds. -- Disable WebView content debugging in production builds (do not call `setWebContentsDebuggingEnabled(true)` on Android; keep `WKWebView.isInspectable` set to `false` on iOS). +- **Disable the Debuggable Flag in Release Builds**: Ensure that the debuggable flag in the app's configuration file is not enabled for production builds, e.g. by using build variants or flavors to separate debug and release configurations so the flag is enabled only for debug builds. +- **Disable WebView Content Debugging in Release Builds**: Do not call `setWebContentsDebuggingEnabled(true)` on Android and keep `WKWebView.isInspectable` set to `false` on iOS in production builds. diff --git a/weaknesses/MASVS-STORAGE/MASWE-0001.md b/weaknesses/MASVS-STORAGE/MASWE-0001.md index bf230bd..2e888e5 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0001.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0001.md @@ -3,8 +3,8 @@ title: Insertion of Sensitive Data into Logs id: MASWE-0001 alias: data-in-logs requirement: "The app excludes sensitive data from application logs." -platform: ["android", "ios"] -profiles: ["L1", "L2", "P"] +platform: [android, ios] +profiles: [L1, L2, P] mappings: masvs-v1: [MSTG-STORAGE-7] masvs-v2: [MASVS-STORAGE-2, MASVS-PRIVACY-1] @@ -13,38 +13,39 @@ mappings: - https://developer.android.com/privacy-and-security/risks/log-info-disclosure maswe-beta: [MASWE-0001] refs: - - https://stackoverflow.com/questions/45270547/is-read-logs-a-normal-or-dangerous-android-permission +- https://developer.android.com/privacy-and-security/risks/log-info-disclosure +- https://developer.apple.com/documentation/os/logging/generating_log_messages_from_your_code status: new --- ## Overview -Mobile apps may write [sensitive data](../../Document/0x04b-Mobile-App-Security-Testing.md#identifying-sensitive-data "Sensitive Data") to logs. This may include sensitive user data, such as passwords, credit card numbers, or other personally identifiable information (PII), as well as sensitive system data, such as cryptographic keys, session tokens, or other sensitive information. +This weakness occurs when an app writes sensitive data to system or application logs. This may include sensitive user data, such as passwords, credit card numbers, or other personally identifiable information (PII), as well as sensitive system data, such as cryptographic keys or session tokens. -Logging all possible information is very useful at development time, especially for debugging the app. However, in production it might not always be necessary and should be prevented whenever possible to avoid any accidentally exposure to potential attackers. +Logging all possible information is very useful at development time, especially for debugging the app. However, in production it might not always be necessary and should be prevented whenever possible to avoid any accidental exposure to potential attackers. ## Modes of Introduction -This can typically occur in two ways: - -- **System Logs**: The application may log sensitive data to the system log, which can be accessed by other applications on the device (in old OS versions or compromised devices or if they hold the appropriate permissions). -- **App Logs**: The application may log sensitive data to a file in the application's data directory, which can be accessed by any application on the device if the device is rooted. +- **Sensitive Data in System Logs**: Writing sensitive data to the system log via platform logging APIs, often as leftover debugging statements. +- **Sensitive Data in App Log Files**: Writing sensitive data to custom log files in the app's data directory, e.g. via third-party logging frameworks. +- **Verbose Logging in Production**: Shipping release builds with debug or verbose log levels still enabled, so diagnostic details containing sensitive data end up in production logs. ## Impact -Loss of confidentiality: Sensitive data within logs is at risk of being exposed to an attacker with access to the device who may be able to extract it. This may lead to further attacks, such as identity theft, or compromise of the application's backend. +Attackers can access sensitive data written to logs by: -## Mitigations +- Accessing the system logs on a compromised device or from an app holding log-access permissions. +- Accessing the device storage on a compromised device. -The following are generic recommendations to avoid logging sensitive data in production releases: +This can lead to: -- Avoid logging sensitive data at all. -- Redact sensitive data in logs. -- Remove logging statements unless deemed necessary to the application or explicitly identified as safe, e.g. as a result of a security audit. -- Use log levels properly to ensure that sensitive data is not logged in production releases. -- Use flags to disable logging in production releases. +- **Compromise of Sensitive Data**: Attackers can read passwords, credit card numbers, or PII from log output, resulting in unauthorized disclosure of user data and enabling further attacks such as identity theft. +- **Authentication or Authorization Bypass**: Attackers can reuse leaked credentials or session tokens, resulting in unauthorized access to the user's account and the app's backend services. -The documentation for each platform provides best practices for developers: +## Mitigations -- [Android mitigations to avoid log disclosure](https://developer.android.com/privacy-and-security/risks/log-info-disclosure#mitigations) -- [iOS mitigations to avoid log disclosure](https://developer.apple.com/documentation/os/logging/generating_log_messages_from_your_code#3665948) +- **Avoid Logging Sensitive Data**: Do not log sensitive data at all; treat any user or system secret as unloggable by default. +- **Redact Sensitive Data**: Where log statements are needed around sensitive values, redact or mask those values before writing them. +- **Remove Unnecessary Logging**: Strip logging statements from release builds unless they are deemed necessary to the app and explicitly identified as safe, e.g. as a result of a security audit. +- **Use Log Levels Properly**: Assign debug-only details to debug or verbose levels and ensure those levels are disabled in production releases. +- **Disable Logging in Production**: Use build flags or configuration to disable logging in production releases, following the platform guidance for [Android](https://developer.android.com/privacy-and-security/risks/log-info-disclosure#mitigations) and [iOS](https://developer.apple.com/documentation/os/logging/generating_log_messages_from_your_code#3665948). diff --git a/weaknesses/MASVS-STORAGE/MASWE-0002.md b/weaknesses/MASVS-STORAGE/MASWE-0002.md index 1c38422..40355c9 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0002.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0002.md @@ -17,27 +17,36 @@ refs: - https://developer.android.com/guide/topics/data/autobackup#include-exclude-android-12 - https://developer.android.com/guide/topics/data/autobackup#define-device-conditions status: new - --- ## Overview -iOS and Android automatically back up app data to cloud services, and users can also create local backups on physical machines, or backups are automatically created during data transfers when switching between phones. When developers fail to properly configure how their app handles backups and neglect to exclude sensitive files, the backups may contain sensitive user and app data. Under certain conditions, the backups may not be adequately secured by the cloud provider, or a malicious actor could tamper with the backed up files, potentially altering the app's behavior or extracting confidential information. +This weakness occurs when an app fails to exclude sensitive data from device backups, so that user and app secrets end up in cloud or local backup archives. + +iOS and Android automatically back up app data to cloud services, users can create local backups on physical machines, and backups are also created during data transfers when switching between phones. When developers do not properly configure how their app handles backups and neglect to exclude sensitive files, the backups may contain sensitive user and app data. Under certain conditions, the backups may not be adequately secured by the cloud provider, or a malicious actor could tamper with the backed-up files. + +## Modes of Introduction + +- **Automatic System Backups**: Relying on the platform's default cloud backup behavior, which includes app data once the user consents during the initial device setup, without defining backup exclusion rules for sensitive files. +- **Local Backups**: Allowing sensitive data to be included in backups that users create on local systems (e.g., laptops), where it may be stored unencrypted. +- **Device-To-Device Transfer**: Allowing sensitive data to be included in device-to-device migrations (e.g., via iCloud or Google's migration tools) without restricting transfer conditions. +- **Sensitive Data Unencrypted in Backups**: Storing sensitive data in backed-up locations without additional encryption, so it is readable by anyone who obtains the backup. ## Impact -- **Modification of App's Behavior**: An attacker can tamper with data inside the backup, altering the app's logic. For example, they could modify a database that tracks the state of premium features and then restore the modified backup to the device. Another common scenario is backing up the device before redeeming a one-time coupon and restoring the backup afterward, which would allow the malicious actor to reuse the same coupon multiple times. -- **Loss of Confidentiality**: Sensitive data stored in backups (e.g., personal information, photos, documents or audio files) may be extracted by attackers, leading to privacy breaches. -- **Leakage of Authentication Material**: An attacker can extract passwords, cryptographic keys, and session tokens to facilitate additional attacks, such as identity theft, account takeover, or unauthorized access. +Attackers can extract or tamper with sensitive data included in backups by: -## Modes of Introduction +- Extracting local or cloud backups of the device. +- Tampering with backup contents and restoring the modified backup to a device. + +This can lead to: -- **Automatic System Backups**: By default, iOS and Android back up app data to the cloud once the user consents during the initial setup. -- **Local Backups**: Users can back up their devices to local systems (e.g., laptops). If local backups are stored unencrypted or not securely handled, attackers could tamper with this data. -- **Device-To-Device Transfer**: Transferring data between devices (e.g., via iCloud or Google's device-to-device migration tools) enables an attacker to perform similar attacks. +- **Compromise of Sensitive Data**: Attackers can extract personal information, photos, documents, or audio files from backups, resulting in unauthorized disclosure of user data. +- **Authentication or Authorization Bypass**: Attackers can extract passwords, cryptographic keys, and session tokens from backups, resulting in identity theft, account takeover, or unauthorized access to backend services. +- **Bypass of Protection Mechanisms**: Attackers can modify backed-up app state, e.g. a database tracking premium features, or restore a pre-redemption backup to reuse one-time coupons, resulting in circumvention of business logic and revenue loss for the app owner. ## Mitigations -- Exclude sensitive information, files, and key material from backups. -- If you have to include sensitive data in backups, ensure it is encrypted with an algorithm strong enough to protect the data for its entire required lifetime, even if the backup is later compromised. -- On Android, constrain when backups are allowed by declaring the appropriate [device conditions](https://developer.android.com/guide/topics/data/autobackup#define-device-conditions), such as requiring client-side encryption (`requireFlags="clientSideEncryption"`) and disabling device-to-device transfer (`deviceToDeviceTransfer`) for sensitive datasets, so that unencrypted copies are never produced. +- **Exclude Sensitive Data from Backups**: Declare backup rules that exclude sensitive information, files, and key material from all backup mechanisms. +- **Encrypt Data That Must Be Backed Up**: If sensitive data has to be included in backups, encrypt it with an algorithm strong enough to protect the data for its entire required lifetime, even if the backup is later compromised. +- **Constrain Backup Conditions**: On Android, declare the appropriate [device conditions](https://developer.android.com/guide/topics/data/autobackup#define-device-conditions), such as requiring client-side encryption (`requireFlags="clientSideEncryption"`) and disabling device-to-device transfer (`deviceToDeviceTransfer`) for sensitive datasets, so that unencrypted copies are never produced. diff --git a/weaknesses/MASVS-STORAGE/MASWE-0003.md b/weaknesses/MASVS-STORAGE/MASWE-0003.md index e2bd4b9..56dc5bb 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0003.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0003.md @@ -14,39 +14,48 @@ mappings: - https://developer.android.com/privacy-and-security/risks/file-providers maswe-beta: [MASWE-0006, MASWE-0002, MASWE-0118] refs: - - https://developer.apple.com/documentation/uikit/protecting_the_user_s_privacy/encrypting_your_app_s_files - - https://developer.android.com/about/versions/nougat/android-7.0-changes#permfilesys - - https://developer.android.com/privacy-and-security/security-tips#internal-storage +- https://developer.apple.com/documentation/uikit/protecting_the_user_s_privacy/encrypting_your_app_s_files +- https://developer.android.com/about/versions/nougat/android-7.0-changes#permfilesys +- https://developer.android.com/privacy-and-security/security-tips#internal-storage status: new --- ## Overview -Mobile apps may need to store sensitive data locally within private storage locations such as the application sandbox and this data is at risk of exposure via, for example, incorrect file permissions, an app vulnerability, device vulnerability or data backup mechanisms. +This weakness occurs when an app stores sensitive data unencrypted in private storage locations, such as the application sandbox, where it can be exposed via incorrect file permissions, an app or device vulnerability, or data backup mechanisms. -[Sensitive data](../../Document/0x04b-Mobile-App-Security-Testing.md#identifying-sensitive-data "Sensitive Data") may include personally identifiable information (PII), passwords, cryptographic keys or session tokens. +Sensitive data may include personally identifiable information (PII), passwords, cryptographic keys, or session tokens. + +## Modes of Introduction + +- **Data Stored Unencrypted**: Writing sensitive data to the app's private data directory (sandbox) unencrypted. +- **Hardcoded Encryption Key**: Encrypting sensitive data with a key that is hardcoded inside the application. +- **Encryption Key Stored on Filesystem**: Encrypting sensitive data but storing the key alongside it or in another easily accessible location. +- **Insufficient Encryption**: Encrypting sensitive data with an algorithm or configuration that is not considered strong. +- **Insufficient Access Restrictions**: Exposing private files to other apps through incorrect file permissions (e.g. the deprecated `MODE_WORLD_READABLE`/`MODE_WORLD_WRITEABLE` modes on Android), a misconfigured `FileProvider`, or Keychain items protected with weak accessibility attributes on iOS (e.g. `kSecAttrAccessibleAlways`). +- **Data Not Removed After Use**: Retaining sensitive data in private storage (including caches, temporary files, WebView state, and network caches) longer than needed. ## Impact -- **Loss of Confidentiality**: Under the right conditions an attacker could extract sensitive data stored internally within the application sandbox leading to loss of confidentiality and enable further attacks such as identity theft or account takeover. +Attackers can access sensitive data stored unencrypted in private storage by: -## Modes of Introduction +- Accessing the device storage on a compromised device. +- Accessing files exposed through incorrect file permissions or misconfigured content providers. +- Extracting local or cloud backups of the device. + +This can lead to: -- **Data Stored Unencrypted**: Sensitive data is written to the app's private data directory (sandbox) unencrypted. -- **Hardcoded Encryption Key**: Sensitive data is encrypted but the key is hardcoded inside the application. -- **Encryption Key Stored on Filesystem**: Sensitive data is encrypted but the key is stored alongside it or in another easily accessible location. -- **Encryption Used is Insufficient**: Sensitive data is encrypted but the encryption is not considered to be strong. -- **Insufficient Access Restrictions**: Even within private storage, sensitive files may be exposed to other apps through incorrect file permissions (e.g. the deprecated `MODE_WORLD_READABLE`/`MODE_WORLD_WRITEABLE` modes on Android), a misconfigured `FileProvider`, or Keychain items protected with weak accessibility attributes on iOS (e.g. `kSecAttrAccessibleAlways`). -- **Data Not Removed After Use**: Sensitive data written to private storage (including caches, temporary files, WebView state, and network caches) is retained longer than needed, widening the window of exposure. +- **Compromise of Sensitive Data**: Attackers can extract PII and other user data from the application sandbox, resulting in unauthorized disclosure and enabling further attacks such as identity theft. +- **Authentication or Authorization Bypass**: Attackers can extract passwords, cryptographic keys, or session tokens, resulting in account takeover or unauthorized access to protected functionality. ## Mitigations -- Avoid storing sensitive data locally if not required for application functionality to reduce the likelihood and impact of this weakness. For example keeping PII server-side, rendering it at time of use, and removing any cached data on logout. -- Restrict access to private files: never use `MODE_WORLD_READABLE`/`MODE_WORLD_WRITEABLE`, share data through a properly configured `ContentProvider`/`FileProvider` with per-grant permissions instead, and on iOS store Keychain items with the strictest viable accessibility attribute (e.g. `kSecAttrAccessibleWhenUnlockedThisDeviceOnly`). -- Apply data minimization: clear sensitive data, caches, and temporary files as soon as they are no longer needed (e.g. on logout or when leaving a sensitive flow) to limit the window during which it can be exposed. -- Store cryptographic keys exclusively using the platform's hardware-backed keystore solution, such as the Android Keystore or the iOS Keychain. -- For storing other files and preferences, use platform-provided features for encrypting data at rest or other techniques implementing envelope encryption with Data Encryption Keys (DEK) and Key Encryption Keys (KEK) or equivalent methods. For example, on Android, use [`EncryptedFile`](https://developer.android.com/reference/androidx/security/crypto/EncryptedFile) or [`EncryptedSharedPreferences`](https://developer.android.com/reference/androidx/security/crypto/EncryptedSharedPreferences); on iOS, use [iOS Data Protection](https://developer.apple.com/documentation/uikit/protecting_the_user_s_privacy/encrypting_your_app_s_files). +- **Minimize Local Storage of Sensitive Data**: Avoid storing sensitive data locally if it is not required for app functionality, e.g. keep PII server-side, render it at time of use, and remove any cached data on logout. +- **Restrict File Access**: Never use `MODE_WORLD_READABLE`/`MODE_WORLD_WRITEABLE`; share data through a properly configured `ContentProvider`/`FileProvider` with per-grant permissions instead, and on iOS store Keychain items with the strictest viable accessibility attribute (e.g. `kSecAttrAccessibleWhenUnlockedThisDeviceOnly`). +- **Remove Data When No Longer Needed**: Clear sensitive data, caches, and temporary files as soon as they are no longer needed (e.g. on logout or when leaving a sensitive flow) to limit the window during which they can be exposed. +- **Use Platform Keystores**: Store cryptographic keys exclusively using the platform's hardware-backed keystore solution, such as the Android Keystore or the iOS Keychain. +- **Encrypt Data at Rest**: For other files and preferences, use platform-provided features for encrypting data at rest or techniques implementing envelope encryption with Data Encryption Keys (DEK) and Key Encryption Keys (KEK) or equivalent methods. For example, on Android, use [`EncryptedFile`](https://developer.android.com/reference/androidx/security/crypto/EncryptedFile) or [`EncryptedSharedPreferences`](https://developer.android.com/reference/androidx/security/crypto/EncryptedSharedPreferences); on iOS, use [iOS Data Protection](https://developer.apple.com/documentation/uikit/protecting_the_user_s_privacy/encrypting_your_app_s_files). !!! Warning - The **Jetpack security crypto library**, including the `EncryptedFile` and `EncryptedSharedPreferences` classes, has been [deprecated](https://developer.android.com/privacy-and-security/cryptography#jetpack_security_crypto_library). However, since an official replacement has not yet been released, we recommend using these classes until one is available. + The **Jetpack security crypto library**, including the `EncryptedFile` and `EncryptedSharedPreferences` classes, has been [deprecated](https://developer.android.com/privacy-and-security/cryptography#jetpack_security_crypto_library). However, since an official replacement has not yet been released, we recommend using these classes until one is available. diff --git a/weaknesses/MASVS-STORAGE/MASWE-0004.md b/weaknesses/MASVS-STORAGE/MASWE-0004.md index 87a585c..5488b42 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0004.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0004.md @@ -13,41 +13,48 @@ mappings: android-risks: - https://developer.android.com/privacy-and-security/risks/sensitive-data-external-storage maswe-beta: [MASWE-0007, MASWE-0002] +refs: +- https://developer.android.com/training/data-storage +- https://developer.android.com/privacy-and-security/security-tips#external-storage status: new --- ## Overview -Apps frequently opt to store data in the external storage due to its larger capacity. However, this convenience comes with a potential security drawback. Once a malicious app is granted the relevant permissions, it can access this data without user consent or interaction at any time. Additionally, external storage like SD cards can be physically removed and read by a malicious actor. Even if the external storage is emulated by the system, the risk arises from improper file permissions or the misuse of APIs for saving files. In such cases, the files become vulnerable to unauthorized access, modifications and deletions, posing a security threat to the application. +This weakness occurs when an app stores sensitive data unencrypted in shared or external storage, where other apps can access it without any user interaction. -Developers may consider switching to Private Storage or Shared Storage Requiring User Interaction if they need more privacy and security. However, if the external storage is the most suitable for the app, it's a good practise to encrypt data stored in the external storage. Below you can find potential security impacts and mitigations linked to the use of the external storage. +Apps frequently opt to store data in external storage due to its larger capacity. However, once another app is granted the relevant permissions, it can access this data at any time. External storage such as SD cards can also be physically removed and read. Even when external storage is emulated by the system, improper file permissions or misuse of file-saving APIs can leave files open to unauthorized access, modification, or deletion. -## Impact - -- **Loss of confidentiality**: An attacker can extract sensitive data stored externally, such as personal information and media like photos, documents, and audio files. +This weakness primarily concerns Android, which permits the use of shared and external storage. On iOS, apps cannot directly write to or read from arbitrary locations; the system enforces strict sandboxing so apps can only access their own sandboxed file directories. -- **Loss of secure material**: An attacker can extract passwords, cryptographic keys, and session tokens to facilitate additional attacks, such as identity theft or account takeover. +## Modes of Introduction -- **Modification of app's behaviour**: An attacker can tamper with data used by the app, altering the app's logic. For example, they could modify a database describing the state of premium features or inject a malicious payload to enable further attacks such as SQL injection and Path Traversal. +- **Data Stored Unencrypted**: Writing sensitive data to shared or external storage unencrypted. +- **Hardcoded Encryption Key**: Encrypting sensitive data stored in external storage with a key that is hardcoded inside the application. +- **Encryption Key Stored on Filesystem**: Encrypting sensitive data stored in external storage but storing the key alongside it or in another easily accessible location. +- **Insufficient Encryption**: Encrypting sensitive data with an algorithm or configuration that is not considered strong. +- **Reuse of Encryption Key**: Sharing the encryption key between two devices owned by a single user, enabling data cloning between those devices via external storage. -- **Modification of downloaded code**: An app can download new functionality from the Internet and store the executable code in external storage before loading it into the process. An attacker can modify this code before it is used by the app. +## Impact -## Modes of Introduction +Attackers can access or tamper with sensitive data stored in shared or external storage by: -This threat is primarily a concern for Android devices since they permit the use of external storage. Even if a device lacks physical external storage, Android emulates it to provide access to the external storage API. +- Accessing shared or external storage from any app holding the corresponding permissions. +- Physically removing and reading external storage media such as SD cards. -- **Data Stored Unencrypted**: Sensitive data is stored in the external storage unencrypted. -- **Hardcoded Encryption Key**: Sensitive data is encrypted and stored in the external storage but the key is hardcoded inside the application. -- **Encryption Key Stored on Filesystem**: Sensitive data is encrypted and stored in the external storage but the key is stored alongside it or in another easily accessible location. -- **Encryption Used is Insufficient**: Sensitive data is encrypted but the encryption is not considered to be strong. -- **Reuse of encryption key**: The encryption key is shared between two devices owned by a single user, enabling the process of data cloning between these devices in the external storage. +This can lead to: -On iOS, apps cannot directly write to or read from the arbitrary locations, as compared to desktop operating system or Android. iOS maintains strict sandboxing rules, meaning apps can only access their own sandboxed file directories. +- **Compromise of Sensitive Data**: Attackers can extract personal information and media such as photos, documents, and audio files, resulting in unauthorized disclosure of user data. +- **Authentication or Authorization Bypass**: Attackers can extract passwords, cryptographic keys, and session tokens, resulting in identity theft or account takeover. +- **Bypass of Protection Mechanisms**: Attackers can tamper with data used by the app, e.g. a database describing the state of premium features, resulting in circumvention of business logic and revenue loss for the app owner. +- **Execution of Unauthorized Code**: Attackers can modify executable code or inject malicious payloads (e.g. enabling SQL injection or path traversal) into files that the app loads or processes from external storage, resulting in code execution or further compromise within the app's context. ## Mitigations -Sensitive data stored in the external storage should be encrypted, and any keys used for data encryption should be protected by the device's hardware-backed keystore, where available. It is highly discouraged to include cryptographic keys hardcoded inside the application. You can also consider storing your files in the [private app sandbox or internal storage](https://developer.android.com/training/data-storage/app-specific#internal) and using [Android's EncryptedFile API wrapper for file encryption](https://developer.android.com/reference/androidx/security/crypto/EncryptedFile). +- **Prefer Private Storage**: Store files in the [private app sandbox or internal storage](https://developer.android.com/training/data-storage/app-specific#internal) whenever possible, or use shared storage mechanisms that require user interaction for access. +- **Encrypt Data Before Writing**: Encrypt any sensitive data stored in shared or external storage, e.g. using [Android's `EncryptedFile` API](https://developer.android.com/reference/androidx/security/crypto/EncryptedFile). +- **Protect Encryption Keys**: Protect any keys used for data encryption with the device's hardware-backed keystore where available, and never hardcode them inside the application. !!! Warning - The **Jetpack security crypto library**, including the `EncryptedFile` and `EncryptedSharedPreferences` classes, has been [deprecated](https://developer.android.com/privacy-and-security/cryptography#jetpack_security_crypto_library). However, since an official replacement has not yet been released, we recommend using these classes until one is available. + The **Jetpack security crypto library**, including the `EncryptedFile` and `EncryptedSharedPreferences` classes, has been [deprecated](https://developer.android.com/privacy-and-security/cryptography#jetpack_security_crypto_library). However, since an official replacement has not yet been released, we recommend using these classes until one is available. diff --git a/weaknesses/MASVS-STORAGE/MASWE-0005.md b/weaknesses/MASVS-STORAGE/MASWE-0005.md index d5d73ef..e1159dc 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0005.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0005.md @@ -22,25 +22,32 @@ status: new ## Overview -Cryptographic keys are essential for securing sensitive data in mobile applications. However, if these keys are not properly protected at rest, they can be easily compromised. This weakness involves storing cryptographic keys in insecure locations, such as unencrypted SharedPreferences, unprotected files, hardcoding them within the application code, or including them in source control and versioning systems which may end in the final application package in production. +This weakness occurs when cryptographic keys are stored outside the platform-provided secure keystore, in locations such as unencrypted preferences, unprotected files, or the application code itself. -Attackers can decompile or reverse-engineer the app to extract hardcoded keys. +Cryptographic keys are essential for securing sensitive data in mobile applications. Keys that are hardcoded in the app, included in source control and shipped in the final package, or written to insecure storage locations lack the access control and hardware-backed protection that platform keystores, such as the [Android Keystore](https://developer.android.com/training/articles/keystore) and the [iOS Keychain](https://developer.apple.com/documentation/security/keychain_services), are designed to provide. + +## Modes of Introduction + +- **Insecure Storage Locations**: Storing cryptographic keys in locations that are not designed for secure storage, such as regular configuration or user preferences files, application data directories, or other areas lacking encryption and access control mechanisms. +- **Hardcoded Cryptographic Keys**: Including cryptographic keys directly in the application code or in resources shipped with the app package. +- **Insecure Imported Keys**: Importing cryptographic keys from untrusted sources or without validating their integrity. ## Impact -- **Unauthorized Access**: If cryptographic keys are not properly protected, attackers may gain unauthorized access to sensitive data and potential identity theft. -- **Loss of Integrity**: Compromised keys can allow attackers to tamper with encrypted data. -- **Loss of Confidentiality**: Sensitive information can be exposed, resulting in a loss of confidentiality. Once keys are exposed, all data encrypted with those keys is at risk. +Attackers can extract cryptographic keys stored outside the platform keystore by: -## Modes of Introduction +- Obtaining the app package and reverse engineering it. +- Accessing the device storage on a compromised device. +- Extracting local or cloud backups of the device. -- **Insecure Storage Locations**: Storing cryptographic keys in locations that are not designed for secure storage, such as regular configuration or user preferences files, application data directories, or other areas lacking encryption and access control mechanisms. -- **Hardcoded Cryptographic Keys**: Including cryptographic keys directly in the application code, making them susceptible to extraction through decompilation and reverse-engineering. -- **Insecure Imported Keys**: Importing cryptographic keys from untrusted sources or without validating their integrity, which can lead to the introduction of malicious or compromised keys into the application environment. +This can lead to: + +- **Compromise of Sensitive Data**: Attackers can decrypt protected information or forge encrypted data, resulting in unauthorized disclosure or modification of sensitive data. +- **Authentication or Authorization Bypass**: Attackers can create valid cryptographic values or impersonate trusted parties, resulting in unauthorized access to protected accounts, data, or functionality. ## Mitigations -- **Use Platform Keystores**: Where possible, generate cryptographic keys dynamically on the device, rather than using predefined keys, and ensure that they are securely stored after creation. For this you can use the platform-specific keystores, such as the [Android KeyStore](https://developer.android.com/training/articles/keystore) or [iOS KeyChain](https://developer.apple.com/documentation/security/keychain_services). +- **Use Platform Keystores**: Where possible, generate cryptographic keys dynamically on the device, rather than using predefined keys, and ensure that they are securely stored after creation. For this you can use the platform-specific keystores, such as the [Android Keystore](https://developer.android.com/training/articles/keystore) or the [iOS Keychain](https://developer.apple.com/documentation/security/keychain_services). - **Implement Strongest Hardware Security Solutions**: For the most critical cases and whenever [available and compatible](https://developer.android.com/privacy-and-security/keystore#HardwareSecurityModule) for the use case at hand, leverage the strongest hardware-backed security options such as [Android StrongBox](https://source.android.com/docs/security/features/keystore/strongbox) or iOS's Secure Enclave [`kSecAttrTokenIDSecureEnclave`](https://developer.apple.com/documentation/security/ksecattrtokenidsecureenclave) option to ensure the highest protection including physical and side-channel attacks. - **Use Cryptographic Key Management Systems**: Securely retrieve keys from server-side services that provide secure storage, access control, and auditing for sensitive data. For example, AWS Secrets Manager, Azure Key Vault, or Google Cloud Secret Manager are some popular managed secrets storage solutions. The app can securely retrieve the necessary secrets at runtime through secure, authenticated API calls. - **Encrypt and Wrap Keys**: Whenever storing keys in platform keystores is not suitable for the use case or keys need to be exported, use envelope encryption (DEK+KEK) and key wrapping techniques as specified in [NIST.SP.800-175Br1 5.3.5](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-175Br1.pdf) to protect cryptographic keys before storing them. diff --git a/weaknesses/MASVS-STORAGE/MASWE-0006.md b/weaknesses/MASVS-STORAGE/MASWE-0006.md index 81583ff..26a1e7c 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0006.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0006.md @@ -21,39 +21,38 @@ status: new ## Overview -Mobile apps frequently ship sensitive data inside the app package (APK/IPA) itself. Because the package can be freely downloaded and reverse-engineered, any secret embedded in the source code, compiled binaries, resources, or bundled configuration files can be extracted with little effort. +This weakness occurs when sensitive data is embedded in the app package (APK/IPA) and shipped with the app, where anyone who downloads the package can recover it. -This weakness covers any sensitive data that is hardcoded and shipped with the app, including: - -- **API keys and secrets** for first- or third-party services. -- **Credentials** such as passwords, session tokens, or other authentication material. -- **Cryptographic material** such as symmetric keys or private keys embedded directly in the package (as opposed to being generated and stored in a platform keystore, see @MASWE-0005). -- **Developer leftover artifacts**, such as staging or integration URLs, developer emails and usernames, and source code files left in the package (e.g. `.swift`, `.cpp`, map files, or other build artifacts) that leak internal information. +The hardcoded sensitive data may include API keys and secrets for first- or third-party services, credentials such as passwords or session tokens, and cryptographic material such as symmetric or private keys embedded directly in the package (as opposed to being generated and stored in a platform keystore, see @MASWE-0005). It also includes developer leftover artifacts, such as staging or integration URLs, developer emails and usernames, and source code files left in the package (e.g. `.swift`, `.cpp`, map files, or other build artifacts) that leak internal information. Note that developer _debug_ artifacts (verbose logging, backdoors, testing utilities, hidden switches) are covered separately under resilience in @MASWE-0054. The focus here is on hardcoded sensitive data that leaks confidentiality regardless of any anti-tampering considerations. +## Modes of Introduction + +- **App Source Code**: Embedding secrets directly in the code that is compiled into the app. +- **App Assets and Resources**: Including secrets in configuration files, manifests, property lists, string resources, and other bundled files. +- **Libraries**: Including secrets in the configuration files or source code of first-party, third-party, or transitive dependencies. +- **Build and Developer Leftovers**: Inadvertently packaging staging/integration endpoints, developer identities, and source files with the app. + ## Impact -- **Loss of Confidentiality**: Hardcoded secrets, credentials, and internal information can be extracted by anyone able to obtain the app package. -- **Financial Loss**: Attackers can abuse compromised API keys to make unauthorized, billed API calls (e.g., AI/ML services), resulting in unexpected charges to the app owner. -- **Compromise of System Integrity and Business Operations**: Extracted keys and credentials can grant unauthorized access to sensitive resources and backend services, potentially leading to service disruption, policy-violation suspensions, or Denial of Service. -- **Bypass of Protection Mechanisms**: Hardcoded keys can make it easier to unlock paid features, access restricted content, or otherwise circumvent app protections. +Attackers can extract hardcoded secrets, credentials, and internal information by: -## Modes of Introduction +- Obtaining the app package and reverse engineering it. -Sensitive data can be hardcoded in several places that end up in the final package: +This can lead to: -- **App Source Code**: secrets embedded directly in the compiled code. -- **App Assets and Resources**: configuration files, manifests, property lists, string resources, and other bundled files. -- **Libraries**: configuration files or source code of first-party, third-party, or transitive dependencies. -- **Build and Developer Leftovers**: staging/integration endpoints, developer identities, and source files inadvertently packaged with the app. +- **Financial Loss**: Attackers can abuse compromised API keys to make unauthorized billed API calls (e.g., AI/ML services), resulting in unexpected charges to the app owner. +- **Compromise of System Integrity and Business Operations**: Attackers can use extracted credentials to access backend services, resulting in service disruption, policy-violation suspensions, or denial of service. +- **Compromise of Sensitive Data**: Attackers can use extracted cryptographic material to decrypt protected data, resulting in unauthorized disclosure of user or app data. +- **Bypass of Protection Mechanisms**: Attackers can use hardcoded keys to unlock paid features or access restricted content, resulting in circumvention of app protections and revenue loss for the app owner. ## Mitigations -- Use a stateful API service that provides secure authentication, client validation, and session controls. Implement dynamic tokens that expire after a reasonably short time (e.g., 1 hour) to reduce the impact of key exposure, and ensure proper error handling and logging to detect unauthorized access attempts. Consider OAuth 2.0 and libraries such as AppAuth to simplify secure OAuth flows. -- If a stateful API service is not viable, use a stateless API service fronted by a middleware solution (API proxy or gateway) that proxies requests between the app and the API endpoint, keeping the static secret server-side rather than in the client. Use JSON Web Tokens (JWT) and JSON Web Signature (JWS) as appropriate. -- If secrets must be hardcoded, configure them with the minimum required permissions and restrictions to reduce the impact in case of exposure. -- Consider using a [Key Management Service](https://cloud.google.com/kms/docs/key-management-service) to retrieve secrets at runtime after validating app integrity. -- Store cryptographic keys and authentication material using the platform's hardware-backed keystore (Android Keystore, iOS Keychain) instead of embedding them in the package. See @MASWE-0005. -- Regularly audit the codebase and dependencies for hardcoded sensitive data and developer leftovers (e.g. using tools such as [gitleaks](https://github.com/gitleaks/gitleaks)) and strip build artifacts and source files from release packages. -- As a **last resort** when no other secure option is available, white-box cryptography, code/resource obfuscation, and RASP can raise the effort required to extract secrets, ensuring keys are only assembled in memory when needed. These techniques deter but do not prevent extraction and must not replace the mitigations above. +- **Use Stateful API Services**: Prefer API services that provide secure authentication, client validation, and session controls. Implement dynamic tokens that expire after a reasonably short time (e.g., 1 hour) to reduce the impact of key exposure, and ensure proper error handling and logging to detect unauthorized access attempts. Consider OAuth 2.0 and libraries such as AppAuth to simplify secure OAuth flows. +- **Proxy Static Secrets Through a Middleware**: If a stateful API service is not viable, front the stateless API with a middleware solution (API proxy or gateway) that proxies requests between the app and the API endpoint, keeping the static secret server-side rather than in the client. Use JSON Web Tokens (JWT) and JSON Web Signature (JWS) as appropriate. +- **Restrict Unavoidable Hardcoded Secrets**: If secrets must be hardcoded, configure them with the minimum required permissions and restrictions to reduce the impact in case of exposure. +- **Retrieve Secrets at Runtime**: Consider using a [Key Management Service](https://cloud.google.com/kms/docs/key-management-service) to retrieve secrets at runtime after validating app integrity. +- **Use Platform Keystores**: Store cryptographic keys and authentication material using the platform's hardware-backed keystore (Android Keystore, iOS Keychain) instead of embedding them in the package. See @MASWE-0005. +- **Audit for Leftover Secrets**: Regularly audit the codebase and dependencies for hardcoded sensitive data and developer leftovers (e.g. using tools such as [gitleaks](https://github.com/gitleaks/gitleaks)) and strip build artifacts and source files from release packages. +- **Harden Only as a Last Resort**: When no other secure option is available, use white-box cryptography, code/resource obfuscation, and RASP to raise the effort required to extract secrets, ensuring keys are only assembled in memory when needed. These techniques deter but do not prevent extraction and must not replace the mitigations above. From 741bb78a4613796e63bcd6980ac865dacfa221f9 Mon Sep 17 00:00:00 2001 From: Carlos Holguera Date: Mon, 20 Jul 2026 01:06:08 +0200 Subject: [PATCH 09/70] Finish all drafts --- .github/instructions/impact-attacks.yaml | 50 ++++++++++++++++ .github/instructions/impact-patterns.yaml | 13 ++++ weaknesses/MASVS-AUTH/MASWE-0017.md | 48 ++++++++++----- weaknesses/MASVS-AUTH/MASWE-0018.md | 50 ++++++++++------ weaknesses/MASVS-AUTH/MASWE-0019.md | 60 ++++++++++--------- weaknesses/MASVS-AUTH/MASWE-0020.md | 68 +++++++++++---------- weaknesses/MASVS-AUTH/MASWE-0021.md | 55 +++++++++++------ weaknesses/MASVS-AUTH/MASWE-0022.md | 46 ++++++++------ weaknesses/MASVS-AUTH/MASWE-0023.md | 52 +++++++++------- weaknesses/MASVS-AUTH/MASWE-0024.md | 58 +++++++++++------- weaknesses/MASVS-CODE/MASWE-0040.md | 44 +++++++++----- weaknesses/MASVS-CODE/MASWE-0042.md | 41 +++++++++---- weaknesses/MASVS-CODE/MASWE-0043.md | 46 +++++++++----- weaknesses/MASVS-CODE/MASWE-0044.md | 45 ++++++++++---- weaknesses/MASVS-CODE/MASWE-0045.md | 53 +++++++++------- weaknesses/MASVS-CODE/MASWE-0046.md | 44 +++++++++----- weaknesses/MASVS-CODE/MASWE-0047.md | 73 +++++++++++------------ weaknesses/MASVS-CODE/MASWE-0048.md | 68 +++++++++++---------- weaknesses/MASVS-CODE/MASWE-0075.md | 53 ++++++++++------ weaknesses/MASVS-CODE/MASWE-0077.md | 48 +++++++++------ weaknesses/MASVS-CRYPTO/MASWE-0008.md | 49 +++++++++------ weaknesses/MASVS-CRYPTO/MASWE-0009.md | 44 +++++++++----- weaknesses/MASVS-CRYPTO/MASWE-0010.md | 58 +++++++++++------- weaknesses/MASVS-CRYPTO/MASWE-0012.md | 43 ++++++++----- weaknesses/MASVS-CRYPTO/MASWE-0013.md | 61 ++++++++++++------- weaknesses/MASVS-CRYPTO/MASWE-0014.md | 48 ++++++++++----- weaknesses/MASVS-CRYPTO/MASWE-0015.md | 46 +++++++++----- weaknesses/MASVS-PLATFORM/MASWE-0028.md | 50 +++++++++++----- weaknesses/MASVS-PLATFORM/MASWE-0029.md | 44 ++++++++++---- weaknesses/MASVS-PLATFORM/MASWE-0031.md | 44 +++++++++----- weaknesses/MASVS-PLATFORM/MASWE-0032.md | 50 ++++++++++------ weaknesses/MASVS-PLATFORM/MASWE-0033.md | 50 ++++++++++------ weaknesses/MASVS-PLATFORM/MASWE-0034.md | 47 ++++++++++----- weaknesses/MASVS-PLATFORM/MASWE-0035.md | 50 +++++++++++----- weaknesses/MASVS-PLATFORM/MASWE-0036.md | 45 +++++++++----- weaknesses/MASVS-PLATFORM/MASWE-0037.md | 48 ++++++++++----- weaknesses/MASVS-PLATFORM/MASWE-0038.md | 51 ++++++++++------ weaknesses/MASVS-PLATFORM/MASWE-0039.md | 52 +++++++++------- weaknesses/MASVS-PRIVACY/MASWE-0069.md | 2 +- weaknesses/MASVS-PRIVACY/MASWE-0073.md | 55 ++++++++++------- weaknesses/MASVS-PRIVACY/MASWE-0074.md | 64 ++++++++++---------- weaknesses/MASVS-RESILIENCE/MASWE-0049.md | 44 +++++++++----- weaknesses/MASVS-RESILIENCE/MASWE-0051.md | 43 +++++++++---- weaknesses/MASVS-RESILIENCE/MASWE-0052.md | 45 +++++++++----- weaknesses/MASVS-RESILIENCE/MASWE-0053.md | 45 +++++++++----- weaknesses/MASVS-RESILIENCE/MASWE-0054.md | 57 ++++++++++-------- weaknesses/MASVS-RESILIENCE/MASWE-0055.md | 42 ++++++++----- weaknesses/MASVS-RESILIENCE/MASWE-0056.md | 41 ++++++++++--- weaknesses/MASVS-RESILIENCE/MASWE-0057.md | 46 +++++++++----- weaknesses/MASVS-RESILIENCE/MASWE-0058.md | 39 +++++++++--- weaknesses/MASVS-RESILIENCE/MASWE-0059.md | 57 +++++++++++------- weaknesses/MASVS-RESILIENCE/MASWE-0060.md | 43 +++++++++---- weaknesses/MASVS-RESILIENCE/MASWE-0061.md | 45 +++++++++----- weaknesses/MASVS-RESILIENCE/MASWE-0062.md | 55 ++++++++++------- weaknesses/MASVS-RESILIENCE/MASWE-0063.md | 46 +++++++++----- weaknesses/MASVS-RESILIENCE/MASWE-0064.md | 47 ++++++++++----- weaknesses/MASVS-RESILIENCE/MASWE-0076.md | 51 ++++++++++------ 57 files changed, 1805 insertions(+), 957 deletions(-) diff --git a/.github/instructions/impact-attacks.yaml b/.github/instructions/impact-attacks.yaml index d3395f7..1d4292b 100644 --- a/.github/instructions/impact-attacks.yaml +++ b/.github/instructions/impact-attacks.yaml @@ -22,10 +22,60 @@ - Exploiting predictable or reused IVs or nonces to detect patterns or recover plaintext. - Exploiting padding oracles exposed through observable error signals or timing differences. - Observing enough outputs to recover the internal state of a non-cryptographic PRNG. +- Performing offline brute-force or dictionary attacks against keys derived from low-entropy inputs. +- Precomputing derived keys when salts are missing, hardcoded, or reused. +- Applying a single compromised key to all current and historical data protected with it. +- Invoking keystore operations on a compromised or stolen device when key use does not require user authentication. +- Crafting collisions or second preimages for broken hash functions. +- Replaying previously captured valid messages or tags. +- Recovering private keys from predictable or reused signature nonces. +- Presenting data with invalid, stripped, or attacker-signed signatures that the app accepts. +- Using a victim's device with an active session (e.g., an unlocked or stolen device). +- Reusing stolen session tokens obtained through other attacks. +- Using a known, guessed, or shoulder-surfed device credential (PIN, pattern, or password). +- Enrolling additional biometrics on the device after obtaining the device credential. +- Displaying overlays or tampering with the UI to alter what the user sees while approving an action. +- Manipulating a compromised OS to alter or fabricate the confirmation flow. +- Invoking exported or unprotected app components from another app installed on the device. +- Connecting to open ports or local services exposed by the app. +- Patching or repackaging the app to remove or alter client-side checks. +- Reading sensitive data from the clipboard when users copy it between apps. +- Phishing credentials through lookalike apps or pages when users must type them manually. +- Observing the device screen while sensitive data is displayed or entered (shoulder surfing). +- Reading notification content shown on the lock screen without unlocking the device. +- Reading notification content from another app holding notification-access permissions. +- Registering the same custom URL scheme to intercept links intended for the app. +- Delivering crafted deep links or intents from a malicious app or web page. +- Capturing user input through a malicious custom keyboard or app extension. +- Registering intent filters to intercept implicit intents sent by the app. +- Modifying or replaying mutable PendingIntents obtained from the app. +- Injecting malicious JavaScript into WebView content (e.g., via MITM on insecure connections or a compromised website). +- Harvesting on-screen content through a malicious accessibility service the user was tricked into enabling. +- Exploiting known vulnerabilities in outdated app versions that users are still running. +- Exploiting platform vulnerabilities on outdated OS versions the app still supports. +- Leveraging legacy platform behaviors applied to apps targeting outdated platform versions. +- Substituting or modifying code that the app loads at runtime from writable or unverified locations. +- Exploiting memory-corruption vulnerabilities in the app's native code. +- Exploiting known weaknesses in deprecated APIs or components the app still uses. +- Exploiting flaws in custom or unproven security implementations. +- Supplying crafted input through any external interface (network, IPC, files, UI, or peripherals). +- Compromising a dependency, SDK, or build tool in the app's supply chain. +- Introducing malicious code through an insider or compromised developer account. +- Distributing tampered builds that cannot be distinguished from legitimate ones. +- Accessing a lost or stolen device that has no secure lock screen configured. +- Inspecting or modifying app traffic on a device they control after bypassing transport protections (e.g., pinning). +- Running the app on a rooted or jailbroken device they control. +- Running the app in an emulator or virtual device. +- Running the app inside an app-virtualization or cloning framework. +- Impersonating the app with scripts, bots, or tampered clients when interacting with the backend. +- Installing a repackaged version of the app on victim devices. +- Modifying the app's files or resources on a compromised device. - Capturing or recording the screen from another app or an external tool. - Accessing screenshots automatically taken by the system, e.g., when the app moves to the background. - Identifying vulnerable dependency versions in the app package and using public advisories or exploits. - Collecting and correlating identifiers and usage data across apps, devices, and services. +- Contacting undeclared tracking domains that platform enforcement cannot block. +- Handling credentials and browsing state inside the app instead of isolated system flows. - Collecting non-resettable identifiers or misusing resettable ones. - Linking directly identifiable data to real-world identities. - Operating without a privacy policy or under a vague, generic, or inaccessible one. diff --git a/.github/instructions/impact-patterns.yaml b/.github/instructions/impact-patterns.yaml index a8c87f7..c67ec94 100644 --- a/.github/instructions/impact-patterns.yaml +++ b/.github/instructions/impact-patterns.yaml @@ -7,4 +7,17 @@ - Attackers can decrypt or forge [...] by - Attackers can inspect and manipulate [...] by - Attackers can exploit [...] by +- Attackers can use [...] without authorization by +- Attackers can forge or replay [...] by +- Attackers can present [...] as authentic by +- Attackers can obtain [...] by +- Attackers can perform [...] by +- Attackers can bypass [...] by +- Attackers can capture [...] by +- Attackers can hijack [...] by +- Attackers can invoke [...] by +- Attackers can execute [...] by +- Attackers can conceal [...] by +- Attackers can analyze [...] by +- Attackers can target [...] by - Apps and embedded third-party components can [...] by diff --git a/weaknesses/MASVS-AUTH/MASWE-0017.md b/weaknesses/MASVS-AUTH/MASWE-0017.md index 36ae056..6e879c8 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0017.md +++ b/weaknesses/MASVS-AUTH/MASWE-0017.md @@ -16,21 +16,37 @@ refs: - https://tdcolvin.medium.com/is-firebase-auth-secure-dace0563d41b - https://github.com/WICG/trust-token-api - https://blog.cloudflare.com/eliminating-captchas-on-iphones-and-macs-using-new-standard/ -draft: - description: | - Step-up authentication requires the user to re-authenticate or provide an additional - authentication factor before performing a sensitive action, even within an already - authenticated session. An example is a user logged into their bank account (with or - without MFA) who requests a sensitive action such as transferring a large sum of money: - they should be required to re-confirm their identity (e.g. via MFA or biometrics) so - that only the legitimate user can complete the action. When step-up authentication is - missing, an attacker who gains access to an active session (e.g. an unlocked device) - can perform sensitive operations unchallenged. - topics: - - re-authentication before sensitive transactions or when displaying sensitive PII (ioXt UP107) - - additional factor / MFA prompt for high-risk actions - - binding the step-up challenge to the specific action -status: placeholder - +status: new --- +## Overview + +This weakness occurs when an app allows sensitive actions to be performed within an already authenticated session without requiring the user to re-confirm their identity. + +Step-up authentication requires the user to re-authenticate or provide an additional authentication factor before performing a sensitive action, even within an active session. For example, a user logged into their bank account who requests a large transfer should be required to re-confirm their identity (e.g. via biometrics or a second factor) so that only the legitimate user can complete the action. Without it, whoever holds the active session, not necessarily the legitimate user, can perform every operation the account allows. + +## Modes of Introduction + +- **No Re-Authentication for Sensitive Actions**: Allowing high-risk operations, such as payments, credential or profile changes, or the display of sensitive personal data, with only the assurance of the initial login. +- **Step-Up Not Bound to the Action**: Implementing a re-authentication challenge that is not tied to the specific transaction being approved, so a single approval can be reused for a different or modified action. +- **Uniform Assurance Level**: Designing all functionality behind a single login assurance level without classifying operations by risk. + +## Impact + +Attackers can perform sensitive actions in a victim's authenticated session by: + +- Using a victim's device with an active session (e.g., an unlocked or stolen device). +- Reusing stolen session tokens obtained through other attacks. + +This can lead to: + +- **Financial Loss**: Attackers can initiate transfers or purchases in the victim's session, resulting in direct financial harm to the user. +- **Compromise of Sensitive Data**: Attackers can view or export sensitive personal data available in the session, resulting in unauthorized disclosure of user information. +- **Authentication or Authorization Bypass**: Attackers can change the account's credentials or security settings without any additional challenge, resulting in persistent account takeover. + +## Mitigations + +- **Require Step-Up for Sensitive Actions**: Re-authenticate the user, e.g. with biometrics bound to a keystore-protected key or an additional factor, before executing high-risk operations or displaying highly sensitive data. +- **Bind the Challenge to the Action**: Tie the step-up challenge cryptographically to the specific transaction (e.g. transaction signing), so an approval cannot be replayed or applied to a different action. +- **Classify Actions by Risk**: Define which operations require step-up authentication and match the required assurance level to the sensitivity of each action. +- **Enforce Step-Up Server-Side**: Have the server require and verify step-up evidence before executing the action, rather than trusting a client-side check. diff --git a/weaknesses/MASVS-AUTH/MASWE-0018.md b/weaknesses/MASVS-AUTH/MASWE-0018.md index f3110c1..669e504 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0018.md +++ b/weaknesses/MASVS-AUTH/MASWE-0018.md @@ -12,22 +12,38 @@ mappings: refs: - https://developers.google.com/identity/sign-in/android/disconnect - https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html -draft: - description: | - When a session is terminated (explicit logout, timeout, or a contextual state change such - as the app moving to the background, a remarkable change in the user's location, or a - change to the user's profile), the app must invalidate the session and ensure that - sensitive data is no longer accessible. This weakness occurs when the app fails to - re-authenticate on such transitions or leaves sensitive data (session tokens, cached PII, - in-memory state, on-screen content) reachable after the session should have ended, letting - an attacker with access to the device resume access without authenticating. - topics: - - session invalidation on logout, timeout, and inactivity - - re-authentication when returning from background to foreground - - re-authentication on remarkable changes in the user's location or profile (IEEE) - - clearing sensitive data and tokens on session termination - - ASVS V3.3 Session Logout and Timeout Requirements; NIST 800-63 -status: placeholder - +status: new --- +## Overview + +This weakness occurs when sensitive data or an authenticated session remains accessible after the session should have ended, whether through explicit logout, a timeout, or a contextual state change. + +Session termination is not limited to the user tapping "log out": inactivity timeouts, the app moving to the background, or remarkable changes in the user's context (such as location or profile changes) can all require the session to end or the user to re-authenticate. When the app fails to invalidate the session and clear the associated sensitive data (session tokens, cached personal data, in-memory state, on-screen content), anyone who gains access to the device or the leftover tokens can resume access without authenticating. + +## Modes of Introduction + +- **Sessions Not Invalidated**: Terminating sessions only client-side, leaving session tokens valid on the server after logout or timeout. +- **No Re-Authentication on State Changes**: Resuming the app from the background or continuing after remarkable context changes (e.g. a significant change in the user's location or profile) without requiring re-authentication. +- **Cached Data Not Cleared**: Retaining session tokens, cached personal data, in-memory state, or on-screen content after the session ends. +- **Missing Inactivity Timeout**: Allowing sessions to remain valid indefinitely without inactivity or absolute expiration limits. + +## Impact + +Attackers can access sensitive data or resume a session after it should have ended by: + +- Using a victim's device with an active session (e.g., an unlocked or stolen device). +- Reusing stolen session tokens obtained through other attacks. +- Accessing the device storage on a compromised device. + +This can lead to: + +- **Authentication or Authorization Bypass**: Attackers can resume the victim's session and act as the user without authenticating, resulting in unauthorized access to the account and its functionality. +- **Compromise of Sensitive Data**: Attackers can read cached or leftover personal data from a terminated session, resulting in unauthorized disclosure of user information. + +## Mitigations + +- **Invalidate Sessions Fully**: Invalidate the session server-side on logout, timeout, and account state changes, following the [OWASP Session Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html). +- **Re-Authenticate on Context Changes**: Require re-authentication when the app returns to the foreground after a sensitive flow or when remarkable changes in the user's context (e.g. location or profile) are detected. +- **Clear Sensitive Data on Termination**: Remove session tokens, cached personal data, and in-memory or on-screen sensitive content when the session ends, including disconnecting linked accounts where applicable. +- **Enforce Timeouts**: Apply both inactivity and absolute session timeouts appropriate to the app's risk profile. diff --git a/weaknesses/MASVS-AUTH/MASWE-0019.md b/weaknesses/MASVS-AUTH/MASWE-0019.md index 4a8a2c6..44055af 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0019.md +++ b/weaknesses/MASVS-AUTH/MASWE-0019.md @@ -12,32 +12,38 @@ mappings: refs: - https://developer.android.com/training/articles/security-android-protected-confirmation - https://source.android.com/docs/security/features/protected-confirmation -draft: - description: | - Critical actions (e.g. confirming a payment or a high-value transaction) should be - non-repudiable: the user must be shown exactly what they are approving, through a - trusted, hardware-protected confirmation path, and the app should obtain - cryptographic evidence that this specific prompt was confirmed by the user. Without - such a path, a compromised OS, overlay attack, or tampered UI could get the user to - approve something different from what they saw, and the user could later plausibly - deny having authorized the action. - - On Android, the only known way to achieve this today is Android Protected Confirmation, - which displays a prompt via a Trusted UI and signs the confirmed message with a - hardware-backed key. Note that Android Protected Confirmation does not provide a secure - information channel, so it must not be used to display sensitive information that - wouldn't ordinarily be shown on the device. Equivalent trusted-confirmation paths on - iOS/GrapheneOS and other platforms need to be evaluated. The essential requirement is - that the confirmation goes through a Trusted UI / hardware-protected confirmation path. - - This weakness should also minimally cover the legal context of non-repudiation (e.g. - the evidentiary value of a signed, user-confirmed action). - topics: - - Android Protected Confirmation (Trusted UI + hardware-backed signature) - - hardware-protected confirmation paths on iOS / GrapheneOS and other platforms - - cryptographic evidence binding the confirmed message to the user's approval - - legal context of non-repudiation -status: placeholder - +status: new --- +## Overview + +This weakness occurs when critical actions, such as confirming a payment or a high-value transaction, can be approved without a trusted confirmation path that produces cryptographic evidence of what the user actually saw and approved. + +For a critical action to be non-repudiable, the user must be shown exactly what they are approving through a trusted, hardware-protected confirmation path, and the app should obtain cryptographic evidence that this specific prompt was confirmed by the user. On Android, this can be achieved with [Android Protected Confirmation](https://developer.android.com/training/articles/security-android-protected-confirmation), which displays the prompt via a Trusted UI and signs the confirmed message with a hardware-backed key. Note that it does not provide a secure information channel, so it must not be used to display sensitive information that wouldn't ordinarily be shown on the device. Equivalent trusted-confirmation paths on other platforms need to be evaluated case by case. + +Beyond the technical aspect, non-repudiation has a legal dimension: a signed, user-confirmed action carries evidentiary value that a plain in-app confirmation does not, which matters when transactions are later disputed. + +## Modes of Introduction + +- **No Trusted Confirmation Path**: Confirming critical actions through the regular app UI, which a compromised OS or a tampered app can render differently from what is actually executed. +- **No Cryptographic Evidence of Approval**: Completing critical actions without obtaining a hardware-backed signature that binds the displayed message to the user's approval, leaving the app owner unable to prove what was approved. +- **Sensitive Data in the Confirmation Prompt**: Displaying sensitive information through the trusted confirmation prompt, which protects the integrity of the confirmation but is not a secure display channel for secrets. + +## Impact + +Attackers can obtain user approval for actions different from what the user intended by: + +- Displaying overlays or tampering with the UI to alter what the user sees while approving an action. +- Manipulating a compromised OS to alter or fabricate the confirmation flow. + +This can lead to: + +- **Financial Loss**: Attackers can trick users into approving altered payments or transactions, resulting in funds being transferred to attacker-controlled destinations. +- **Compromise of System Integrity and Business Operations**: Users can plausibly repudiate transactions when the app owner holds no cryptographic proof of what was approved, resulting in disputes, chargebacks, and legal exposure for the app owner. + +## Mitigations + +- **Use a Hardware-Protected Confirmation Path**: Confirm critical actions through a Trusted UI mechanism such as Android Protected Confirmation, where the prompt is displayed and confirmed outside the reach of the main OS. +- **Bind Cryptographic Evidence to the Action**: Have the confirmation produce a hardware-backed signature over the exact message shown to the user, verify it server-side, and retain it as evidence of the approval. +- **Do Not Display Secrets in the Prompt**: Keep sensitive information out of the trusted confirmation message; it guarantees integrity of the confirmation, not confidentiality of its contents. +- **Use the Strongest Available Alternative**: Where no trusted-UI mechanism exists, bind transaction approval to a user-authenticated, hardware-backed signing key (e.g. biometric-bound transaction signing) as the closest available equivalent. diff --git a/weaknesses/MASVS-AUTH/MASWE-0020.md b/weaknesses/MASVS-AUTH/MASWE-0020.md index 19cce3b..e9eeb47 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0020.md +++ b/weaknesses/MASVS-AUTH/MASWE-0020.md @@ -24,34 +24,42 @@ refs: - https://developer.android.com/privacy-and-security/security-tips#binder-and-messenger-interfaces - https://developer.android.com/topic/security/risks/content-resolver - https://developer.android.com/topic/security/risks/file-providers -draft: - description: | - App components that expose functionality or data must enforce proper authentication and - authorization on their callers. This weakness covers any app component that is reachable - by other apps or processes without adequate access control, including Android services, - broadcast receivers, activities, and content providers, as well as a local web service or - open port exposed by the app (which is also considered an app component). - - Typical problems include components unintentionally exported, components exported with - unrestricted or missing permissions, exposed Binder/Messenger interfaces that don't verify - the caller (e.g. not calling `checkCallingPermission()`), sticky broadcasts, over-broad URI - permission grants (e.g. `FLAG_GRANT_PERSISTABLE_URI_PERMISSION` and other - `FLAG_GRANT_*_URI_PERMISSION` flags), content providers exposing data without proper - permission tags or protection levels, and locally bound network services (open ports) - accepting connections without authentication. It also covers auth-material handling on such - surfaces, such as authentication tokens not being validated and insecure authentication - handled inside WebViews. - topics: - - unintentionally exported services, broadcast receivers, activities, and content providers - - unrestricted or missing permissions and protection levels on exported components - - exposed Binder/Messenger interfaces not verifying the caller (checkCallingPermission) - - sticky broadcasts - - over-broad URI permission grants (FLAG_GRANT_READ/WRITE/PERSISTABLE_URI_PERMISSION) - - content providers (database- and file-based, FileProvider) exposing data without access control - - one-time vs. persistent data sharing with other apps - - local web service / unprotected open ports treated as an app component - - authentication tokens not validated (e.g. OAuth2/JWT client-side checks, none algorithm, PKCE) - - insecure authentication handled in WebViews (e.g. WebViewClient.onReceivedHttpAuthRequest) -status: placeholder - +status: new --- + +## Overview + +This weakness occurs when app components that expose functionality or data do not enforce proper authentication or authorization on their callers. + +It covers any component reachable by other apps or processes without adequate access control, including services, broadcast receivers, activities, and content providers, as well as local web services or open ports exposed by the app, which are also considered app components. It also covers the handling of authentication material on such surfaces, for example authentication tokens accepted without validation or authentication flows handled insecurely inside WebViews. + +## Modes of Introduction + +- **Unintentionally Exported Components**: Exporting services, broadcast receivers, activities, or content providers through defaults or misconfiguration when they are only meant for internal use. +- **Missing or Weak Permissions on Exported Components**: Exporting components without permission requirements, with weak protection levels, or with misconfigured custom permissions. +- **Caller Not Verified on IPC Interfaces**: Exposing Binder or Messenger interfaces that do not verify the caller's identity or permissions (e.g. not calling `checkCallingPermission()`). +- **Over-Broad Data Grants**: Using sticky broadcasts, over-broad or persistable URI permission grants, or persistent data sharing where one-time, scoped sharing would suffice. +- **Unprotected Local Network Services**: Binding a local web service or open port that accepts connections without authentication. +- **Authentication Material Not Validated**: Accepting authentication tokens without proper validation (e.g. missing signature or claim checks, no PKCE in OAuth flows) or handling authentication inside WebViews instead of secure system flows. + +## Impact + +Attackers can access sensitive data and functionality exposed by app components by: + +- Invoking exported or unprotected app components from another app installed on the device. +- Connecting to open ports or local services exposed by the app. + +This can lead to: + +- **Compromise of Sensitive Data**: Attackers can query unprotected content providers or receive broadcast data, resulting in unauthorized disclosure of user or app data to other apps on the device. +- **Authentication or Authorization Bypass**: Attackers can invoke privileged functionality, such as internal services or unvalidated token flows, without authenticating, resulting in actions being executed on behalf of the user. +- **Bypass of Protection Mechanisms**: Attackers can launch internal activities directly, resulting in the circumvention of intended flows such as authentication screens or paywalls. + +## Mitigations + +- **Do Not Export Components Unnecessarily**: Explicitly mark internal components as not exported and keep the exposed surface minimal. +- **Protect Exported Components with Permissions**: Guard intentionally exported components with permissions of an appropriate protection level (e.g. signature-level for same-developer apps) and define custom permissions correctly. +- **Verify Callers on IPC Interfaces**: Check the caller's identity or permissions on Binder and Messenger interfaces before performing sensitive operations or returning data. +- **Grant Minimal, Short-Lived Data Access**: Prefer one-time, narrowly scoped URI grants over persistable ones, avoid sticky broadcasts, and restrict content provider paths to exactly what must be shared. +- **Authenticate Local Services**: Avoid opening local ports where possible; if required, authenticate every connection and bind only to the local interface. +- **Validate Authentication Material**: Validate tokens server-side (signature, issuer, audience, expiry), use PKCE for OAuth flows, and use system-provided authentication sessions instead of handling credentials inside WebViews. diff --git a/weaknesses/MASVS-AUTH/MASWE-0021.md b/weaknesses/MASVS-AUTH/MASWE-0021.md index 8b2c690..9d273f4 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0021.md +++ b/weaknesses/MASVS-AUTH/MASWE-0021.md @@ -17,24 +17,41 @@ refs: - https://github.com/sensepost/objection/issues/136#issuecomment-419664574 - https://github.com/sensepost/objection/wiki/Understanding-the-iOS-Biometrics-Bypass - https://developer.apple.com/documentation/security/secaccesscontrolcreateflags/applicationpassword -draft: - description: | - Local authentication (biometrics, device credential, a custom app PIN/password, or - Confirm Credentials) is bypassable when it is only an event-bound UI check rather than - being cryptographically tied to a resource. Local authentication should gate access to a - key in the platform keystore and use a `CryptoObject`/keychain access control so that the - protected operation cannot proceed without a successful authentication that the OS/hardware - enforces. This weakness also covers authentication and authorization that is enforced only - locally instead of on the server-side (for connected apps), and custom PINs/passwords that - are not bound to the platform keystore, both of which allow an attacker to bypass the check - by tampering with the client. - topics: - - result-only (event-bound) biometric checks with no CryptoObject - - keychain items protected with weak access control flags (e.g. kSecAccessControlTouchIDAny) - - Confirm Credentials / device-credential fallback implemented insecurely - - authentication or authorization enforced only locally instead of on the server-side - - custom app PIN/password not bound to the platform keystore (e.g. applicationPassword) -status: placeholder - +status: new --- +## Overview + +This weakness occurs when local authentication, such as biometrics, device credentials, or a custom app PIN, can be bypassed because it is implemented as an event-bound check rather than being cryptographically tied to a protected resource. + +Local authentication is only as strong as what it unlocks. When the app merely reacts to a "success" callback, an attacker who controls the app's execution can invoke the protected logic directly, without ever passing the check. To be effective, local authentication must gate access to a key in the platform keystore, using a `CryptoObject` on Android or Keychain access control on iOS, so that the protected operation cannot proceed without an authentication that the OS and hardware enforce. For connected apps, authentication and authorization decisions that are enforced only locally, rather than on the server side, are similarly bypassable by tampering with the client. + +## Modes of Introduction + +- **Event-Bound Biometric Checks**: Acting on the biometric prompt's success result alone, without binding the protected operation to a keystore key that requires authentication (e.g. no `CryptoObject`). +- **Weak Keychain Access Control Flags**: Protecting Keychain items with flags that do not enforce the intended factor (e.g. `kSecAccessControlTouchIDAny` without additional constraints) or storing "protected" data retrievable without authentication. +- **Insecure Device-Credential Fallback**: Implementing Confirm Credentials or similar flows with long authentication validity durations or without binding them to keystore keys. +- **Local-Only Enforcement**: Enforcing authentication or authorization decisions solely in client code for apps that have a backend, instead of validating them server-side. +- **Custom Credentials Not Keystore-Bound**: Implementing a custom app PIN or password as a plain comparison in code instead of binding it to the platform keystore (e.g. via the Keychain's `applicationPassword` access control). + +## Impact + +Attackers can bypass local authentication and access protected data or functionality by: + +- Using dynamic instrumentation. +- Debugging the app at runtime. +- Patching or repackaging the app to remove or alter client-side checks. +- Invoking keystore operations on a compromised or stolen device when key use does not require user authentication. + +This can lead to: + +- **Authentication or Authorization Bypass**: Attackers can trigger the protected functionality without valid biometrics or credentials, resulting in unauthorized access to the user's account and sensitive operations. +- **Compromise of Sensitive Data**: Attackers can retrieve data that was supposed to be gated by local authentication, resulting in unauthorized disclosure of sensitive user information. + +## Mitigations + +- **Bind Authentication to Keystore Keys**: Gate protected operations on keys stored in the platform keystore that require user authentication, using `CryptoObject` on Android and Keychain access control (e.g. `.biometryCurrentSet`, `.userPresence`) on iOS, so success cannot be simulated in software. +- **Use Strict Access Control Flags**: Choose Keychain and keystore parameters that enforce the intended factor and invalidate on enrollment changes (see @MASWE-0023), avoiding weak flags and long authentication validity windows. +- **Enforce Authentication Server-Side**: For connected apps, gate server resources on server-verified evidence of authentication (e.g. a signed challenge produced with an authentication-bound key), never on a client-side boolean. +- **Bind Custom Credentials to the Keystore**: Implement custom PINs or passwords via keystore- or Keychain-backed mechanisms (e.g. `applicationPassword`) instead of comparing values in app code. +- **Require Explicit User Action**: For passive modalities such as face recognition, require explicit confirmation of the authentication prompt before proceeding with sensitive operations. diff --git a/weaknesses/MASVS-AUTH/MASWE-0022.md b/weaknesses/MASVS-AUTH/MASWE-0022.md index 916ef09..b5eac9d 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0022.md +++ b/weaknesses/MASVS-AUTH/MASWE-0022.md @@ -13,22 +13,34 @@ refs: - https://developer.android.com/training/sign-in/biometric-auth#allow-fallback - https://developer.apple.com/documentation/localauthentication/logging_a_user_into_your_app_with_face_id_or_touch_id#3148834 - https://developer.apple.com/documentation/localauthentication/lapolicy/deviceownerauthenticationwithbiometrics/ -draft: - description: | - For sensitive transactions, allowing authentication to silently fall back from biometrics to a - weaker device credential (PIN/pattern/password) can drop the assurance level below what the - operation requires. On Android this happens when `DEVICE_CREDENTIAL` is permitted as an - authenticator (e.g. via `BiometricPrompt.setAllowedAuthenticators`) for a high-value action; on - iOS when `LAPolicy.deviceOwnerAuthentication` is used instead of - `LAPolicy.deviceOwnerAuthenticationWithBiometrics`. Sensitive transactions should require - biometrics and be bound to a biometric-protected key rather than permitting a non-biometric - fallback. - topics: - - allowing DEVICE_CREDENTIAL fallback on Android (BiometricPrompt.setAllowedAuthenticators) - - using LAPolicy.deviceOwnerAuthentication instead of ...WithBiometrics on iOS - - not binding the sensitive operation to a biometric-only key - - matching the required assurance level to the transaction sensitivity -status: placeholder - +status: new --- +## Overview + +This weakness occurs when authentication for a sensitive transaction can silently fall back from biometrics to a weaker device credential such as a PIN, pattern, or password. + +Device credentials are typically short, reusable, and observable, so allowing them as a fallback drops the assurance level below what a high-value operation requires. On Android, this happens when `DEVICE_CREDENTIAL` is permitted as an authenticator (e.g. via `BiometricPrompt.setAllowedAuthenticators`) for a sensitive action; on iOS, when `LAPolicy.deviceOwnerAuthentication` is used instead of `LAPolicy.deviceOwnerAuthenticationWithBiometrics`. Sensitive transactions should require biometrics and be bound to a biometric-protected key rather than permitting a non-biometric fallback. + +## Modes of Introduction + +- **Device Credential Allowed for Sensitive Actions**: Permitting `DEVICE_CREDENTIAL` as an accepted authenticator for high-value operations on Android. +- **Generic Authentication Policy on iOS**: Using `LAPolicy.deviceOwnerAuthentication`, which allows passcode fallback, instead of `LAPolicy.deviceOwnerAuthenticationWithBiometrics` for sensitive operations. +- **Operation Not Bound to a Biometric-Only Key**: Protecting the sensitive operation with a UI-level prompt rather than a keystore key that only unlocks with strong biometric authentication. + +## Impact + +Attackers can authenticate sensitive transactions without the user's biometrics by: + +- Using a known, guessed, or shoulder-surfed device credential (PIN, pattern, or password). + +This can lead to: + +- **Authentication or Authorization Bypass**: Attackers can complete authentication challenges intended to require the user's biometrics, resulting in unauthorized approval of sensitive operations. +- **Financial Loss**: Attackers can authorize payments or transfers with a stolen device and its credential, resulting in direct financial harm to the user. + +## Mitigations + +- **Require Biometrics for Sensitive Transactions**: Configure the authentication prompt to accept only strong biometrics (e.g. `BIOMETRIC_STRONG` on Android, `LAPolicy.deviceOwnerAuthenticationWithBiometrics` on iOS) for high-value operations. +- **Bind Operations to Biometric-Only Keys**: Protect the operation with a keystore key that requires strong biometric authentication for use and is invalidated on new biometric enrollments (see @MASWE-0023). +- **Match Assurance to Sensitivity**: Allow device-credential fallback only for low-risk convenience features, never for the transactions that motivated biometric protection in the first place. diff --git a/weaknesses/MASVS-AUTH/MASWE-0023.md b/weaknesses/MASVS-AUTH/MASWE-0023.md index c69a3f6..bb4bda1 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0023.md +++ b/weaknesses/MASVS-AUTH/MASWE-0023.md @@ -9,25 +9,37 @@ mappings: masvs-v2: [MASVS-AUTH-2, MASVS-CRYPTO-2] cwe: [287, 522] maswe-beta: [MASWE-0046] -draft: - description: | - Cryptographic keys gated by biometric authentication should be invalidated when the set of - enrolled biometrics changes, so that an attacker who enrolls a new fingerprint or face cannot - unlock keys bound to the legitimate user's biometrics. On Android this invalidation is enabled by - default but can be turned off with `setInvalidatedByBiometricEnrollment(false)`; on iOS it must be - explicitly enabled by using `SecAccessControlCreateFlags.biometryCurrentSet` (formerly - `touchIDCurrentSet`) when creating the access control, which invalidates the keychain item when a - biometric is added or removed. This weakness occurs when the app leaves biometric-bound keys valid - across new enrollments. - topics: - - Enabled by default on Android but can be disabled by calling `setInvalidatedByBiometricEnrollment(false)` - - Disabled by default on iOS but can be enabled using `SecAccessControlCreateFlags.biometryCurrentSet` - (prev. `touchIDCurrentSet`) when setting access control (since iOS 9). This invalidates - keychain items when a fingerprint is added or removed. See kSecAccessControlTouchIDCurrentSet, - biometryCurrentSet. - - verifying invalidation-on-enrollment is not disabled on Android (setInvalidatedByBiometricEnrollment) - - responding safely when a key has been invalidated (e.g. requiring re-enrollment/re-auth) -status: placeholder - +refs: +- https://developer.android.com/reference/android/security/keystore/KeyGenParameterSpec.Builder#setInvalidatedByBiometricEnrollment(boolean) +- https://developer.apple.com/documentation/security/secaccesscontrolcreateflags/biometrycurrentset +status: new --- +## Overview + +This weakness occurs when cryptographic keys gated by biometric authentication remain valid after the set of enrolled biometrics changes. + +Biometric-bound keys are meant to be usable only by the person whose biometrics were enrolled when the key was created. If keys stay valid across enrollments, anyone who can add a new fingerprint or face to the device can unlock them. On Android, invalidation on new enrollment is enabled by default but can be disabled with `setInvalidatedByBiometricEnrollment(false)`; on iOS, it must be explicitly enabled by creating the access control with `SecAccessControlCreateFlags.biometryCurrentSet` (formerly `touchIDCurrentSet`), which invalidates the Keychain item when a biometric is added or removed. + +## Modes of Introduction + +- **Invalidation Disabled on Android**: Creating keys with `setInvalidatedByBiometricEnrollment(false)`, keeping them usable after new biometrics are enrolled. +- **Invalidation Not Enabled on iOS**: Protecting Keychain items without `biometryCurrentSet`, so items remain accessible with any enrolled biometric, including ones added later. +- **Unsafe Invalidation Recovery**: Silently re-creating an invalidated key or falling back to weaker authentication when invalidation occurs, instead of re-verifying the user's identity first. + +## Impact + +Attackers can use biometric-protected keys without the legitimate user's biometrics by: + +- Enrolling additional biometrics on the device after obtaining the device credential. + +This can lead to: + +- **Authentication or Authorization Bypass**: Attackers can pass biometric prompts with their own newly enrolled biometrics, resulting in unauthorized approval of operations bound to the victim's identity. +- **Compromise of Sensitive Data**: Attackers can unlock data protected by biometric-bound keys, resulting in unauthorized disclosure of sensitive user information. + +## Mitigations + +- **Keep Enrollment Invalidation Enabled on Android**: Do not call `setInvalidatedByBiometricEnrollment(false)` for keys protecting sensitive data or operations. +- **Enable Enrollment Invalidation on iOS**: Create Keychain access controls with `SecAccessControlCreateFlags.biometryCurrentSet` so items are invalidated when the enrolled biometric set changes. +- **Handle Invalidation Safely**: When a key has been invalidated, require full re-authentication of the user (e.g. account credentials or a server-verified flow) before re-creating the key, and never silently fall back to weaker protection. diff --git a/weaknesses/MASVS-AUTH/MASWE-0024.md b/weaknesses/MASVS-AUTH/MASWE-0024.md index b528f58..4aefb71 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0024.md +++ b/weaknesses/MASVS-AUTH/MASWE-0024.md @@ -15,27 +15,39 @@ refs: - https://developer.apple.com/documentation/authenticationservices/aswebauthenticationsession - https://developer.android.com/guide/topics/text/autofill - https://developer.apple.com/documentation/authenticationservices/public-private_key_authentication/supporting_passkeys -draft: - description: | - Apps should support the platform's auto-fill mechanisms for authenticators so that - credentials, one-time codes, and passkeys can be provided securely without the user - resorting to insecure workarounds such as copy/paste from other apps. Lacking auto-fill - support pushes users toward weaker practices and misses the platform's secure credential - flows. - - This consolidates several related best practices: credential and one-time-code auto-fill - (e.g. platform auto-fill from SMS) to avoid copy/paste; iOS Password AutoFill, which - streamlines logging into web services associated with the app's domain (and, for - third-party services, using `ASWebAuthenticationSession` instead of Password AutoFill); - passwordless authentication such as passkeys / multi-device FIDO credentials and - WebAuthn/`ASAuthorization`; and shared web credentials / website association so that - credentials can be shared securely between an app and its website counterpart. - topics: - - credential and one-time-code auto-fill to avoid copy/paste (e.g. platform auto-fill from SMS) - - iOS Password AutoFill for the app's associated domain - - ASWebAuthenticationSession for third-party services instead of Password AutoFill - - passwordless authentication (passkeys, multi-device FIDO, WebAuthn/ASAuthorization) - - shared web credentials and website association -status: placeholder - +status: new --- + +## Overview + +This weakness occurs when an app does not support the platform's auto-fill and credential-management mechanisms, pushing users toward insecure workarounds such as copying and pasting credentials between apps. + +Platforms provide secure flows for supplying credentials, one-time codes, and passkeys: credential and one-time-code auto-fill, Password AutoFill tied to the app's associated domain, system authentication sessions for third-party services, passwordless authentication with passkeys and WebAuthn, and shared web credentials between an app and its website counterpart. When an app ignores these mechanisms, users end up typing or copying secrets manually, weakening both their credentials and the trust boundary they cross. + +## Modes of Introduction + +- **No Auto-Fill Support in Credential Fields**: Building login fields that are not recognized by or are incompatible with the platform's auto-fill framework and password managers. +- **No One-Time-Code Auto-Fill**: Requiring users to manually read and copy one-time codes (e.g. from SMS) instead of supporting the platform's code auto-fill. +- **Missing Website Association**: Not associating the app with its domain, preventing secure credential sharing between the app and its website counterpart. +- **Embedded Third-Party Login Instead of System Flows**: Handling third-party authentication in embedded views instead of system-provided authentication sessions (e.g. `ASWebAuthenticationSession`). +- **No Support for Passwordless Authentication**: Not offering passkeys or other multi-device FIDO/WebAuthn credentials where they could replace passwords. + +## Impact + +Attackers can capture credentials that users handle manually by: + +- Reading sensitive data from the clipboard when users copy it between apps. +- Phishing credentials through lookalike apps or pages when users must type them manually. + +This can lead to: + +- **Authentication or Authorization Bypass**: Attackers can reuse captured credentials or one-time codes, resulting in account takeover and unauthorized access to the user's data and functionality. +- **Compromise of Sensitive Data**: Attackers can read credentials exposed through clipboard-based workarounds, resulting in disclosure of authentication material that protects sensitive information. + +## Mitigations + +- **Support Platform Auto-Fill**: Annotate credential fields so the platform's auto-fill framework and password managers can fill them securely (e.g. autofill hints on Android, `textContentType` on iOS). +- **Support One-Time-Code Auto-Fill**: Use the platform mechanisms that deliver one-time codes directly into the app, removing the need for manual copying. +- **Associate the App with Its Domain**: Configure website association (e.g. iOS Password AutoFill with associated domains, shared web credentials) so credentials flow securely between the app and its website. +- **Use System Authentication Sessions for Third-Party Logins**: Authenticate against third-party services with system flows such as `ASWebAuthenticationSession` instead of embedded views. +- **Adopt Passkeys**: Offer passkeys or other WebAuthn-based passwordless authentication to remove shared secrets from the login flow entirely. diff --git a/weaknesses/MASVS-CODE/MASWE-0040.md b/weaknesses/MASVS-CODE/MASWE-0040.md index 482cb58..6d650b0 100644 --- a/weaknesses/MASVS-CODE/MASWE-0040.md +++ b/weaknesses/MASVS-CODE/MASWE-0040.md @@ -15,20 +15,34 @@ refs: - https://developer.android.com/reference/com/google/android/play/core/appupdate/AppUpdateManager - https://medium.com/swlh/updating-users-to-the-latest-app-release-on-ios-ed96e4c76705 - https://gist.github.com/DineshKachhot/f63fcebceca6351fc982cafd38f6f05c -draft: - description: | - When a critical vulnerability is discovered in an app that is already in production, the developer - needs a way to force users onto a fixed version. This weakness occurs when the app has no - enforced-update mechanism (e.g. Android In-App Updates / `AppUpdateManager`, or an App Store - version check on iOS), or when the update requirement is enforced only on the client side and can - therefore be bypassed. Robust enforcement requires the backend to signal and enforce the minimum - acceptable version rather than relying solely on local checks. - topics: - - no in-app / enforced update mechanism at all (CWE-693) - - update enforcement only client-side without a server-side check (CWE-602) - - AppUpdateManager (Android In-App Updates) / App Store version check (iOS) - - server-driven minimum-supported-version enforcement -status: placeholder - +status: new --- +## Overview + +This weakness occurs when an app has no mechanism to force users onto a fixed version after a critical vulnerability is discovered, or when the update requirement is enforced only on the client side. + +When a critical vulnerability is found in a production app, the developer needs a way to move the installed base to a patched version quickly. Platforms provide building blocks for this, such as Android In-App Updates (`AppUpdateManager`) and store version checks on iOS, but robust enforcement requires the backend to signal and enforce the minimum acceptable version: a purely client-side check can be bypassed by the very attackers it is meant to stop. + +## Modes of Introduction + +- **No Enforced-Update Mechanism**: Shipping the app without any in-app or enforced update flow, so vulnerable versions keep working indefinitely. +- **Client-Side-Only Enforcement**: Enforcing the update requirement only in app code, without the backend rejecting requests from versions below the minimum supported one. + +## Impact + +Attackers can exploit vulnerabilities that remain reachable in outdated app versions by: + +- Exploiting known vulnerabilities in outdated app versions that users are still running. +- Patching or repackaging the app to remove or alter client-side checks. + +This can lead to: + +- **Compromise of Sensitive Data**: Attackers can exploit already-fixed vulnerabilities against users stuck on old versions, resulting in exposure of user data long after a patch was published. +- **Compromise of System Integrity and Business Operations**: The app owner cannot retire vulnerable versions from the installed base, resulting in a prolonged attack window, extended incident response, and continued abuse of backend services. + +## Mitigations + +- **Implement an Enforced Update Flow**: Use platform mechanisms such as Android In-App Updates or a version check against the app store on iOS to require updating when a critical fix ships. +- **Enforce the Minimum Version Server-Side**: Have the backend declare the minimum supported app version and reject requests from older clients, so bypassing the client-side prompt does not restore access. +- **Distinguish Flexible and Immediate Updates**: Reserve blocking (immediate) updates for security-critical releases and use flexible updates otherwise, so users accept the mechanism when it matters. diff --git a/weaknesses/MASVS-CODE/MASWE-0042.md b/weaknesses/MASVS-CODE/MASWE-0042.md index 719f728..8cf102a 100644 --- a/weaknesses/MASVS-CODE/MASWE-0042.md +++ b/weaknesses/MASVS-CODE/MASWE-0042.md @@ -14,18 +14,33 @@ mappings: maswe-beta: [MASWE-0077, MASWE-0057] refs: - https://developer.android.com/topic/security/risks/strandhogg -draft: - description: | - e.g. via minSdkVersion on Android and MinimumOSVersion on iOS. Ensuring a recent minimum - platform version guarantees the availability of security features and components - (MASVS-STORAGE-1), the NSC/ATS availability (Android > 7.0 / iOS > 9.0, MASVS-NETWORK-1), - and secure WebView configuration (MASVS-PLATFORM-2). Running on older versions also exposes - the app to platform-level vulnerabilities that were fixed in later releases, such as the - StrandHogg task-affinity/`allowTaskReparenting` attacks on older Android versions. - topics: - - The app sets a low minimum OS version to support older devices, but still relies, implicitly or explicitly, on security features (e.g., runtime permissions, hardware-backed keystore, network security policies) that may not exist on those versions (CWE-693 and CWE-1357). - - exposure to platform vulnerabilities fixed in later releases (e.g. StrandHogg v1/v2, task affinity / allowTaskReparenting on older Android) -status: placeholder - +status: new --- +## Overview + +This weakness occurs when an app does not ensure that it runs on a sufficiently recent platform version, e.g. via `minSdkVersion` on Android or `MinimumOSVersion` on iOS. + +Ensuring a recent minimum platform version guarantees the availability of security features and components the app relies on, such as hardware-backed key storage, runtime permissions, Network Security Configuration (Android 7.0+), and App Transport Security (iOS 9+), as well as secure WebView behavior. Supporting older versions also exposes users to platform-level vulnerabilities that were fixed in later releases, such as the StrandHogg task-affinity attacks on older Android versions, which the app cannot fix on its own. + +## Modes of Introduction + +- **Low Minimum Version with Modern Assumptions**: Setting a low minimum OS version to support older devices while implicitly or explicitly relying on security features (e.g. runtime permissions, hardware-backed keystore, network security policies) that do not exist on those versions. +- **Known-Vulnerable Platform Versions Supported**: Allowing the app to run on OS versions affected by relevant, unfixable platform vulnerabilities (e.g. StrandHogg v1/v2 task affinity and `allowTaskReparenting` abuse on older Android). + +## Impact + +Attackers can exploit platform-level weaknesses on the outdated OS versions the app supports by: + +- Exploiting platform vulnerabilities on outdated OS versions the app still supports. + +This can lead to: + +- **Compromise of Sensitive Data**: Attackers can leverage missing platform protections or unpatched OS vulnerabilities to reach the app's data, resulting in exposure of user data on outdated devices. +- **Authentication or Authorization Bypass**: Attackers can abuse platform flaws such as task hijacking to phish credentials from the app's users on affected versions, resulting in account takeover. + +## Mitigations + +- **Raise the Minimum Platform Version**: Set `minSdkVersion` / `MinimumOSVersion` high enough that every security feature the app depends on is guaranteed to be present. +- **Gate Sensitive Features by Version**: Where supporting older versions is a hard business requirement, detect the platform version at runtime and disable sensitive functionality, or warn and terminate, on versions that cannot provide the required protections. +- **Reassess the Minimum Regularly**: Revisit the supported version floor as platform vulnerabilities are published and usage of old versions declines. diff --git a/weaknesses/MASVS-CODE/MASWE-0043.md b/weaknesses/MASVS-CODE/MASWE-0043.md index 03e45de..a742591 100644 --- a/weaknesses/MASVS-CODE/MASWE-0043.md +++ b/weaknesses/MASVS-CODE/MASWE-0043.md @@ -9,21 +9,35 @@ mappings: masvs-v2: [MASVS-CODE-1] cwe: [693, 1357] maswe-beta: [MASWE-0078] -draft: - description: | - Targeting the latest platform version (via `targetSdkVersion` on Android or by building with a - recent Xcode/SDK on iOS) opts the app into the newest platform-enforced security protections and - behavior changes, such as scoped storage, stricter runtime-permission handling, permission - auto-reset, and modern TLS defaults. When an app targets an old version, the OS applies backward - compatibility behaviors and the app misses these protections (CWE-693, CWE-1357). This is distinct - from the minimum supported version (@MASWE-0042): here the concern is the - target/compiled version. - topics: - - targetSdkVersion on Android - - Xcode / SDK version used to build on iOS - - missing newer platform-enforced protections (scoped storage, permission auto-reset, TLS defaults) - - backward-compatibility behaviors applied to apps targeting old versions -status: placeholder - +refs: +- https://developer.android.com/google/play/requirements/target-sdk +- https://developer.apple.com/news/upcoming-requirements/ +status: new --- +## Overview + +This weakness occurs when an app does not target a recent platform version, missing the newest platform-enforced security protections and behavior changes. + +Targeting the latest platform version, via `targetSdkVersion` on Android or by building with a recent Xcode/SDK on iOS, opts the app into protections such as scoped storage, stricter runtime-permission handling, permission auto-reset, and modern TLS defaults. When an app targets an old version, the OS applies backward-compatibility behaviors and the app silently misses these protections. This is distinct from the minimum supported version (see @MASWE-0042): here the concern is the target/compiled version. + +## Modes of Introduction + +- **Outdated Target Version**: Keeping `targetSdkVersion` on Android, or the Xcode/SDK used to build on iOS, below current requirements, so newer platform-enforced protections never apply to the app. +- **Compatibility Behaviors Left in Place**: Relying on legacy behaviors (e.g. broad storage access or lenient permission handling) that only continue to work because the app targets an old version. + +## Impact + +Attackers can exploit the absence of modern platform protections by: + +- Leveraging legacy platform behaviors applied to apps targeting outdated platform versions. + +This can lead to: + +- **Compromise of Sensitive Data**: Attackers can take advantage of legacy behaviors, such as broader file-system or permission access, resulting in exposure of user data that current platform defaults would have protected. +- **Compromise of System Integrity and Business Operations**: The app can fall below app-store target-version requirements, resulting in blocked updates or removal from distribution for the app owner. + +## Mitigations + +- **Target the Latest Platform Version**: Update `targetSdkVersion` and build with a recent SDK promptly each platform cycle, following the store requirements for [Android](https://developer.android.com/google/play/requirements/target-sdk) and [iOS](https://developer.apple.com/news/upcoming-requirements/). +- **Adopt New Protections Deliberately**: Review each platform release's behavior changes and migrate off legacy behaviors instead of suppressing or postponing them. diff --git a/weaknesses/MASVS-CODE/MASWE-0044.md b/weaknesses/MASVS-CODE/MASWE-0044.md index cf0d195..4dc2964 100644 --- a/weaknesses/MASVS-CODE/MASWE-0044.md +++ b/weaknesses/MASVS-CODE/MASWE-0044.md @@ -12,18 +12,37 @@ mappings: - https://developer.android.com/privacy-and-security/risks/dynamic-code-loading - https://developer.android.com/privacy-and-security/risks/create-package-context maswe-beta: [MASWE-0085] -draft: - description: | - Loading and executing code that is fetched or resolved at runtime (e.g. via `dlopen`, - `DexClassLoader`/`PathClassLoader`, loading native libraries or DEX/JAR files from writable - or external locations, or downloading executable code) is dangerous when the source or - integrity of that code is not verified. An attacker who can modify or substitute the loaded - code can achieve arbitrary code execution within the app's context (CWE-494). - topics: - - dlopen / native library loading from untrusted paths - - DexClassLoader / PathClassLoader loading from writable or external storage - - downloading and executing code without integrity/authenticity verification -status: placeholder - +refs: +- https://developer.android.com/privacy-and-security/risks/dynamic-code-loading +status: new --- +## Overview + +This weakness occurs when an app loads and executes code resolved at runtime without verifying its source and integrity. + +Dynamic code loading includes loading native libraries via `dlopen`, loading DEX/JAR files through class loaders, and downloading executable code or scripts at runtime. When the loaded code comes from writable or external locations, or is fetched without integrity and authenticity verification, an attacker who can modify or substitute it gains arbitrary code execution within the app's context, with all the app's permissions and data access. + +## Modes of Introduction + +- **Loading from Writable or External Locations**: Loading native libraries or DEX/JAR files from writable, external, or world-accessible storage where other apps or actors can replace them. +- **Downloaded Code Without Verification**: Downloading and executing code, plugins, or scripts without verifying their integrity and authenticity (e.g. signature verification, see @MASWE-0015). +- **Code from Other Packages**: Executing code from other installed packages (e.g. via package contexts with code inclusion) whose identity and integrity are not verified. + +## Impact + +Attackers can execute arbitrary code within the app's context by: + +- Substituting or modifying code that the app loads at runtime from writable or unverified locations. +- Performing a Machine-in-the-Middle (MITM) attack, e.g., via ARP poisoning, DNS spoofing, or a rogue access point. + +This can lead to: + +- **Execution of Unauthorized Code**: Attackers can run attacker-controlled code with the app's identity, permissions, and data access, resulting in full compromise of the app's functionality on the device. +- **Compromise of Sensitive Data**: Attackers can use the injected code to read the app's private data and credentials, resulting in unauthorized disclosure of user and app data. + +## Mitigations + +- **Avoid Dynamic Code Loading**: Ship all executable code inside the signed app package whenever possible; app stores also restrict runtime code delivery. +- **Load Only from Protected Locations**: When loading is unavoidable, load code only from the app's protected, read-only installation directories, never from writable or external storage. +- **Verify Integrity and Authenticity**: Verify a cryptographic signature over any dynamically delivered code against a pinned trusted key before loading it, and deliver it only over secure channels. diff --git a/weaknesses/MASVS-CODE/MASWE-0045.md b/weaknesses/MASVS-CODE/MASWE-0045.md index 5b87a51..14fc093 100644 --- a/weaknesses/MASVS-CODE/MASWE-0045.md +++ b/weaknesses/MASVS-CODE/MASWE-0045.md @@ -11,29 +11,42 @@ mappings: android-risks: - https://developer.android.com/privacy-and-security/risks/use-of-native-code maswe-beta: [MASWE-0116] +observed_examples: +- https://nvd.nist.gov/vuln/detail/CVE-2019-3568 refs: -- https://cs.android.com/android/platform/superproject/main/+/main:bionic/linker/linker_main.cpp;l=397?q=linker_main&ss=android%2Fplatform%2Fsuperproject%2Fmain - https://partners.trellix.com/enterprise/en-us/assets/white-papers/wp-secure-coding-android-applications.pdf -- https://mas.owasp.org/MASTG/0x05i-Testing-Code-Quality-and-Build-Settings/#binary-protection-mechanisms -- https://mas.owasp.org/MASTG/0x06i-Testing-Code-Quality-and-Build-Settings/#binary-protection-mechanisms - https://sensepost.com/blog/2021/on-ios-binary-protections/ - https://www.sans.org/blog/stack-canaries-gingerly-sidestepping-the-cage/ -draft: - description: | - Compilers and toolchains provide exploit-mitigation features that make memory-corruption bugs - harder to exploit. This weakness occurs when the app's native code is built without them, such as - stack canaries, Address Space Layout Randomization (ASLR) / Position-Independent Executable (PIE), - non-executable memory (NX/DEP), and fortified (bounds-checked) libc functions. Missing these - mitigations lowers the effort required to exploit memory-corruption vulnerabilities (CWE-693). - topics: - - Position-Independent Executable (PIE) / PIC - - stack canaries (stack-smashing protection) - - non-executable memory (NX / DEP) - - fortify-source / bounds-checked libc functions - - Automatic Reference Counting / memory-safe language usage where applicable - note: PIC cannot be switched off in newer versions of Android, the NDK does not link against such libraries anymore [source](https://cs.android.com/android/platform/superproject/main/+/main:bionic/linker/linker_main.cpp;l=397?q=linker_main&ss=android%2Fplatform%2Fsuperproject%2Fmain). Alternative title could be Memory Anti-Exploitation Mechanisms Not Implemented. -status: placeholder -observed_examples: -- https://nvd.nist.gov/vuln/detail/CVE-2019-3568 +status: new --- +## Overview + +This weakness occurs when an app's native code is built without the exploit-mitigation features that compilers and toolchains provide. + +Mitigations such as stack canaries (stack-smashing protection), Address Space Layout Randomization via Position-Independent Executables (PIE/PIC), non-executable memory (NX/DEP), fortified (bounds-checked) libc functions, and Automatic Reference Counting on iOS do not remove memory-corruption bugs, but they substantially raise the effort required to exploit them. Binaries built without these features make any memory-corruption vulnerability, in the app's own code or its native dependencies, far easier to turn into code execution. + +## Modes of Introduction + +- **Missing Stack Protection**: Compiling native code without stack canaries, leaving stack-based buffer overflows directly exploitable. +- **Missing PIE/ASLR Support**: Building binaries that are not position-independent, defeating address-space layout randomization. Note that on current Android versions the linker no longer loads non-PIE binaries, but legacy toolchains and other platforms can still produce them. +- **Missing Fortified Functions**: Building without fortify-source style bounds-checked replacements for risky libc functions. +- **Unsafe Memory Management Choices**: Disabling Automatic Reference Counting on iOS or otherwise opting out of memory-safety features where safer defaults exist. + +## Impact + +Attackers can exploit memory-corruption bugs with substantially less effort by: + +- Exploiting memory-corruption vulnerabilities in the app's native code. +- Supplying crafted input through any external interface (network, IPC, files, UI, or peripherals). + +This can lead to: + +- **Execution of Unauthorized Code**: Attackers can convert memory-corruption bugs into reliable code execution in the app's context, resulting in full compromise of the app and its data. +- **Compromise of Sensitive Data**: Attackers can read process memory through exploited native bugs, resulting in exposure of credentials, keys, and user data held in memory. + +## Mitigations + +- **Enable Compiler Mitigations**: Build all native code and dependencies with stack canaries, PIE/PIC, non-executable memory, and fortified functions enabled, and verify the flags in release binaries rather than assuming toolchain defaults. +- **Keep Memory-Safety Features On**: Use Automatic Reference Counting on iOS and prefer memory-safe languages for new code where feasible. +- **Cover Third-Party Native Libraries**: Verify that prebuilt native dependencies were also compiled with these mitigations, since a single unprotected library weakens the whole process. diff --git a/weaknesses/MASVS-CODE/MASWE-0046.md b/weaknesses/MASVS-CODE/MASWE-0046.md index 3a8ded9..32cdbe5 100644 --- a/weaknesses/MASVS-CODE/MASWE-0046.md +++ b/weaknesses/MASVS-CODE/MASWE-0046.md @@ -14,20 +14,34 @@ refs: - https://developer.android.com/about/versions/12/behavior-changes-all#bouncy-castle - https://developer.android.com/reference/java/security/KeyStore - https://labs.withsecure.com/publications/how-secure-is-your-android-keystore-authentication -draft: - description: | - The app relies on deprecated APIs or functionality that are no longer maintained, may lack - security fixes, or have been superseded by safer alternatives. Continuing to use deprecated - security-relevant APIs can leave the app exposed to known weaknesses that the platform has - already addressed in newer APIs. A representative example is the use of deprecated Android - KeyStore implementations such as Bouncy Castle (BKS), but this weakness covers deprecated - APIs and functionality in general (cryptography, storage, networking, platform, etc.). - topics: - - deprecated KeyStore implementations (e.g. Bouncy Castle / BKS) - - deprecated cryptographic providers and algorithms - - deprecated platform APIs superseded by safer alternatives - - identifying deprecation warnings during build -status: placeholder - +status: new --- +## Overview + +This weakness occurs when an app relies on deprecated APIs or functionality that are no longer maintained, may lack security fixes, or have been superseded by safer alternatives. + +Platforms deprecate APIs precisely because better-designed replacements exist, often fixing security shortcomings of the old API. Continuing to use deprecated security-relevant APIs can leave the app exposed to weaknesses the platform has already addressed. A representative example is the use of deprecated Android KeyStore implementations such as Bouncy Castle (BKS), but this weakness covers deprecated APIs and functionality in general, including cryptography, storage, networking, and platform features. + +## Modes of Introduction + +- **Deprecated Cryptographic Providers**: Using deprecated keystore or cryptographic provider implementations (e.g. Bouncy Castle-backed KeyStore on Android) instead of their maintained replacements. +- **Deprecated Platform APIs**: Continuing to use platform APIs that have been superseded by safer alternatives with improved security behavior. +- **Deprecation Warnings Ignored**: Building with unresolved deprecation warnings, so the use of outdated functionality accumulates unnoticed. + +## Impact + +Attackers can exploit weaknesses that maintained APIs have already addressed by: + +- Exploiting known weaknesses in deprecated APIs or components the app still uses. + +This can lead to: + +- **Compromise of Sensitive Data**: Attackers can exploit the known shortcomings of deprecated implementations, resulting in exposure of data those APIs were supposed to protect. +- **Authentication or Authorization Bypass**: Attackers can abuse weaknesses in deprecated authentication- or keystore-related APIs, resulting in unauthorized access to protected keys or functionality. + +## Mitigations + +- **Migrate Off Deprecated APIs**: Replace deprecated security-relevant APIs with the platform's recommended alternatives as part of regular maintenance. +- **Treat Deprecation Warnings as Actionable**: Surface deprecation warnings in builds and reviews, and track migrations for security-relevant APIs with priority. +- **Follow Platform Release Notes**: Review each platform release's deprecation and behavior-change notes to plan migrations before old functionality is removed or breaks. diff --git a/weaknesses/MASVS-CODE/MASWE-0047.md b/weaknesses/MASVS-CODE/MASWE-0047.md index e376b8e..326d471 100644 --- a/weaknesses/MASVS-CODE/MASWE-0047.md +++ b/weaknesses/MASVS-CODE/MASWE-0047.md @@ -17,42 +17,39 @@ refs: - https://developer.apple.com/documentation/security/password_autofill - https://developer.android.com/privacy-and-security/cryptography#crypto_provider - https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf?__blob=publicationFile -draft: - description: | - Security-critical functionality (cryptography, networking/TLS, DNS, and authentication) should - rely on platform-provided APIs and functionality or established, peer-reviewed libraries, - rather than on custom ("roll-your-own") implementations or unproven third-party components. - Platform APIs and vetted libraries are designed and maintained by experts, incorporate security - best practices, and receive timely updates; custom or non-standard implementations are far more - likely to contain subtle, exploitable flaws and to miss security updates. This weakness also - covers cases where the app fails to leverage secure functionality the platform already provides, - for example using an insecure custom DNS setup instead of the platform's Private DNS / - DNS-over-TLS support. - - This weakness consolidates: - - - **Risky cryptography implementations**: custom or non-compliant crypto (e.g. not meeting - standards such as FIPS 140-2/3), unproven algorithms, or home-grown constructions that - haven't undergone rigorous peer review and formal validation. - - **Non-standard networking**: rolling a custom networking/TLS stack, using an insecure custom - DNS setup instead of the platform's secure name-resolution functionality, or using outdated - third-party networking libraries instead of proven APIs such as `URLSession`/`NSURLSession` - on iOS or `HttpsURLConnection`/`OkHttp` on Android. - - **Non-standard authentication**: implementing custom authentication instead of using - platform-provided authentication APIs (e.g. Android Credential Manager/`AccountManager`, - iOS Authentication Services / Password AutoFill). - - Note: this can be seen as the security-focused counterpart to @MASWE-0074 (Usage of Non-Privacy-Preserving - Functionality), which applies the same "leverage platform-provided features rather than custom - or non-standard alternatives" principle from a privacy angle. The overlap is intentional: some - platform APIs (e.g. `ASWebAuthenticationSession` / Custom Tabs) improve both security and - privacy. - topics: - - roll-your-own cryptography vs. vetted, standards-compliant libraries - - custom networking/TLS stacks vs. proven networking APIs (URLSession, HttpsURLConnection, OkHttp, Alamofire) - - custom authentication vs. platform-provided authentication APIs (Credential Manager, AccountManager, Authentication Services) - - unmaintained/unproven third-party security libraries - - Custom DNS Resolution, the app bypasses platform-provided name resolution by implementing or configuring a custom resolver without equivalent transport security, trust management, and update guarantees. -status: placeholder - +status: new --- + +## Overview + +This weakness occurs when security-critical functionality, such as cryptography, networking and TLS, DNS resolution, or authentication, is implemented with custom code or unproven components instead of platform-provided APIs or established, peer-reviewed libraries. + +Platform APIs and vetted libraries are designed and maintained by experts, incorporate security best practices, and receive timely updates. Custom or non-standard implementations are far more likely to contain subtle, exploitable flaws and to miss security updates. This weakness also covers failing to leverage secure functionality the platform already provides, for example using an insecure custom DNS setup instead of the platform's Private DNS / DNS-over-TLS support. It is the security-focused counterpart to @MASWE-0074, which applies the same principle from a privacy angle. + +## Modes of Introduction + +- **Roll-Your-Own Cryptography**: Implementing custom or non-compliant cryptography (e.g. not meeting standards such as FIPS 140-2/3), unproven algorithms, or home-grown constructions that have not undergone rigorous peer review and formal validation. +- **Custom Networking or TLS Stacks**: Rolling a custom networking/TLS stack or using outdated third-party networking libraries instead of proven APIs such as `URLSession` on iOS or `HttpsURLConnection`/OkHttp on Android. +- **Custom DNS Resolution**: Bypassing platform-provided name resolution with a custom resolver that lacks equivalent transport security, trust management, and update guarantees. +- **Custom Authentication**: Implementing custom authentication flows instead of platform-provided authentication APIs (e.g. Android Credential Manager/`AccountManager`, iOS Authentication Services / Password AutoFill). +- **Unmaintained Security Libraries**: Depending on unproven or unmaintained third-party components for security-critical functionality. + +## Impact + +Attackers can exploit flaws in non-standard security implementations by: + +- Exploiting flaws in custom or unproven security implementations. +- Performing cryptanalysis of broken algorithms, modes, or parameters. +- Performing a Machine-in-the-Middle (MITM) attack, e.g., via ARP poisoning, DNS spoofing, or a rogue access point. + +This can lead to: + +- **Compromise of Sensitive Data**: Attackers can break weak custom cryptography or intercept traffic handled by flawed custom stacks, resulting in unauthorized disclosure or modification of sensitive data. +- **Authentication or Authorization Bypass**: Attackers can exploit logic flaws in custom authentication implementations, resulting in unauthorized access to user accounts and protected functionality. + +## Mitigations + +- **Use Platform Security APIs**: Prefer platform-provided functionality for cryptography, TLS, DNS, and authentication; it is expert-maintained and updated with the OS. +- **Choose Vetted, Standards-Compliant Libraries**: Where a library is needed, use established, peer-reviewed components that comply with recognized standards (e.g. FIPS 140-2/3, BSI TR-02102) and are actively maintained. +- **Never Roll Your Own Crypto or TLS**: Do not design or implement custom cryptographic algorithms, protocols, or TLS stacks for production use. +- **Leverage Secure Platform Defaults**: Use the platform's secure name resolution (e.g. Private DNS / DNS-over-TLS) and credential-management flows instead of custom substitutes. diff --git a/weaknesses/MASVS-CODE/MASWE-0048.md b/weaknesses/MASVS-CODE/MASWE-0048.md index 6d62abd..1b8b06d 100644 --- a/weaknesses/MASVS-CODE/MASWE-0048.md +++ b/weaknesses/MASVS-CODE/MASWE-0048.md @@ -23,35 +23,41 @@ refs: - https://developer.android.com/topic/security/risks/sql-injection - https://developer.android.com/privacy-and-security/risks/unsafe-deserialization - https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html -draft: - description: | - Any data that originates outside the app's trust boundary must be treated as untrusted and - validated, sanitized, or safely parsed before use, even when it arrives over a secure - channel. Failing to do so can lead to injection, path traversal, and memory-corruption - vulnerabilities when the data reaches a sensitive sink. - - This weakness consolidates unsafe handling of data regardless of its source, including: - - - **Network** data (even over TLS). - - **Backup** data restored to the app (unvalidated restored data, CWE-349). - - **External interfaces** such as Bluetooth, NFC, and USB. - - **Local storage** (internal/external files, document pickers), including path traversal - and zip path traversal. - - **User interface** input (text fields, QR codes, URLs, pasteboard). - - **IPC** (received intents, broadcast receivers, content URIs, URL schemes). - - It also covers the dangerous sinks where untrusted data causes harm, such as SQL injection - (use parameterized queries), insecure parsing and escaping (e.g. XXE, improper output - encoding), and insecure object deserialization (e.g. `java.io.Serializable`, `Parcelable`, - `NSCoding`, XML/JSON). - topics: - - untrusted data from network, backups, external interfaces, local storage, UI, and IPC - - input validation and sanitization at trust boundaries - - path traversal and zip path traversal - - SQL injection / parameterized queries - - insecure parsing and escaping (XXE, output encoding) - - insecure object deserialization (Serializable, Parcelable, NSCoding, XML/JSON) - - use of the Uri class on Android which applies little to no validation on untrusted input (see android docs for Uri) -status: placeholder - +status: new --- + +## Overview + +This weakness occurs when data originating outside the app's trust boundary reaches a sensitive sink without being validated, sanitized, or safely parsed. + +Untrusted data is any data the app did not create itself, regardless of how it arrives: network responses (even over TLS), data restored from backups, external interfaces such as Bluetooth, NFC, and USB, local files (including document pickers and archives), user interface input (text fields, QR codes, URLs, the clipboard), and IPC (received intents, broadcasts, content URIs, or deep links). When such data reaches a dangerous sink unchecked, it can cause SQL injection, path traversal (including zip path traversal), XML external entity (XXE) injection, insecure object deserialization, output-encoding flaws, or memory corruption in native parsers. + +## Modes of Introduction + +- **Missing Validation at Trust Boundaries**: Consuming data from the network, backups, external interfaces, files, UI, or IPC without validating type, length, format, and range before use. +- **Untrusted Data in Queries**: Concatenating untrusted input into SQL or other queries instead of using parameterized APIs. +- **Untrusted Paths and Archives**: Using externally supplied file names or paths (e.g. from content providers or zip entries) without canonicalization and containment checks. +- **Insecure Parsing**: Parsing untrusted XML with external entities enabled, or emitting untrusted data without proper output encoding. +- **Insecure Deserialization**: Deserializing untrusted data into rich object types (e.g. `Serializable`, `Parcelable`, `NSCoding`, XML/JSON object mappers) without restricting the allowed types. +- **Weakly Validated URI Handling**: Relying on URI parsing classes that apply little to no validation of untrusted input when making security decisions. + +## Impact + +Attackers can execute injection attacks against the app by: + +- Supplying crafted input through any external interface (network, IPC, files, UI, or peripherals). +- Delivering crafted deep links or intents from a malicious app or web page. + +This can lead to: + +- **Compromise of Sensitive Data**: Attackers can extract or overwrite private files and database contents through path traversal, SQL injection, or XXE, resulting in unauthorized disclosure or modification of user and app data. +- **Execution of Unauthorized Code**: Attackers can exploit insecure deserialization or memory corruption in parsers, resulting in attacker-controlled code running in the app's context. +- **Authentication or Authorization Bypass**: Attackers can manipulate queries or logic through injected input, resulting in access to data or functionality beyond what the caller is authorized for. + +## Mitigations + +- **Validate at Every Trust Boundary**: Treat all externally originated data as untrusted, including data received over TLS or restored from backups, and validate it against strict expectations before use. +- **Use Parameterized Queries**: Access databases exclusively through parameterized or prepared statements; never build queries by concatenating untrusted input. +- **Canonicalize and Contain Paths**: Canonicalize externally supplied file names and paths and verify they resolve inside the intended directory before any file operation, including when extracting archives. +- **Harden Parsers**: Disable external entity resolution for XML, apply correct output encoding for the destination context, and prefer hardened platform parsers. +- **Deserialize Safely**: Avoid deserializing untrusted data into rich object graphs; prefer simple data formats and safe APIs with explicit type allow-lists. diff --git a/weaknesses/MASVS-CODE/MASWE-0075.md b/weaknesses/MASVS-CODE/MASWE-0075.md index fe8149a..ab80d5b 100644 --- a/weaknesses/MASVS-CODE/MASWE-0075.md +++ b/weaknesses/MASVS-CODE/MASWE-0075.md @@ -8,27 +8,42 @@ profiles: [L2] mappings: masvs-v2: [MASVS-CODE-3] cwe: [506, 507, 511] - refs: - https://developer.android.com/privacy-and-security/risks/insecure-library - https://support.google.com/googleplay/android-developer/answer/13326895 - https://developer.apple.com/support/third-party-SDK-requirements/ -draft: - description: | - An app may ship with malicious code, either introduced intentionally by an insider, or - unintentionally through a compromised dependency, SDK, build tool, or supply-chain attack. - Malicious code can exfiltrate data, execute hidden or backdoored functionality, display - unwanted content, or perform actions against the user's interest. Because the developer is - responsible for all code shipped in the app (including third-party SDKs), the app must be - reviewed and its supply chain controlled to detect and prevent inclusion of malicious code. - This complements @MASWE-0041 (dependencies with known vulnerabilities) and - @MASWE-0077 (non-reproducible builds). - topics: - - intentionally introduced malicious code / insider threat - - malicious or compromised third-party SDKs and dependencies (supply-chain) - - backdoors and hidden functionality - - build-tool / build-pipeline compromise - - detecting malicious code (code review, SCA, behavioral analysis) -status: placeholder - +status: new --- + +## Overview + +This weakness occurs when an app ships with malicious code, introduced either intentionally by an insider or unintentionally through a compromised dependency, SDK, build tool, or other supply-chain attack. + +Malicious code can exfiltrate data, execute hidden or backdoored functionality, display unwanted content, or perform actions against the user's interest. Because the developer is responsible for all code shipped in the app, including third-party SDKs, the codebase must be reviewed and the supply chain controlled to detect and prevent the inclusion of malicious code. This complements @MASWE-0041, which covers dependencies with known vulnerabilities, and @MASWE-0077, which covers the inability to verify what was actually built. + +## Modes of Introduction + +- **Insider-Introduced Code**: Malicious code committed intentionally by someone with access to the codebase or through a compromised developer account. +- **Compromised Dependencies**: Malicious or trojanized third-party SDKs and libraries pulled into the app, including through typosquatting or hijacked packages. +- **Compromised Build Pipeline**: Build tools, plugins, or CI/CD infrastructure that inject code into the app during compilation or packaging. +- **Hidden Functionality**: Backdoors, hidden switches, or undisclosed capabilities shipped in the app or its components. + +## Impact + +Attackers can run malicious functionality inside the trusted app by: + +- Compromising a dependency, SDK, or build tool in the app's supply chain. +- Introducing malicious code through an insider or compromised developer account. + +This can lead to: + +- **Compromise of Sensitive Data**: Attackers can exfiltrate user data and credentials from inside the app's trust boundary, resulting in large-scale disclosure across the entire user base. +- **Execution of Unauthorized Code**: Attackers can trigger backdoored or hidden functionality at will, resulting in attacker-controlled behavior running with the app's identity and permissions. +- **Compromise of System Integrity and Business Operations**: The app owner distributes malware to their own users, resulting in app-store removal, incident response costs, and severe reputational damage. + +## Mitigations + +- **Review Code and Changes**: Enforce code review for all changes, restrict and monitor access to the codebase, and require strong authentication for developer accounts. +- **Control the Supply Chain**: Pin dependency versions, verify package integrity and provenance, source components only from reputable publishers, and monitor them with Software Composition Analysis (see @MASWE-0041). +- **Protect the Build Pipeline**: Harden and monitor CI/CD infrastructure, restrict who and what can alter build configurations, and generate build provenance attestations (see @MASWE-0077). +- **Analyze the Shipped Artifact**: Scan and behaviorally analyze release builds to detect unexpected code, permissions, or network endpoints before distribution. diff --git a/weaknesses/MASVS-CODE/MASWE-0077.md b/weaknesses/MASVS-CODE/MASWE-0077.md index 8b95aef..ff73893 100644 --- a/weaknesses/MASVS-CODE/MASWE-0077.md +++ b/weaknesses/MASVS-CODE/MASWE-0077.md @@ -8,25 +8,39 @@ profiles: [L2] mappings: masvs-v2: [MASVS-CODE-3] cwe: [1357, 494] - refs: - https://reproducible-builds.org/ - https://slsa.dev/ - https://github.com/signalapp/Signal-Android/blob/main/reproducible-builds/README.md -draft: - description: | - A build is reproducible when compiling the same source with the same build environment - always yields a bit-for-bit identical artifact. When builds are not reproducible, it is - impossible for a third party (or the developer) to independently verify that a distributed - binary was built from the claimed, unmodified source, which weakens supply-chain integrity - and makes it harder to detect tampering or injected malicious code. Reproducible builds, - together with build provenance/attestation (e.g. SLSA), let stakeholders verify the - integrity of released artifacts. - topics: - - non-deterministic build outputs (timestamps, paths, ordering, embedded environment data) - - inability to independently verify a released binary against its source - - build provenance and attestation (e.g. SLSA) - - pinned, controlled, and documented build environments/toolchains -status: placeholder - +status: new --- + +## Overview + +This weakness occurs when compiling the app's source with the same build environment does not yield a bit-for-bit identical artifact, making it impossible to independently verify that a distributed binary was built from the claimed, unmodified source. + +Reproducible builds allow third parties, and the developers themselves, to detect tampering or injected malicious code by rebuilding from source and comparing the result with the released artifact. Without reproducibility, this verification is impossible, weakening supply-chain integrity. Together with build provenance and attestation frameworks (e.g. SLSA), reproducible builds let stakeholders verify the integrity of released artifacts. + +## Modes of Introduction + +- **Non-Deterministic Build Outputs**: Embedding timestamps, absolute paths, environment data, or unstable orderings in build artifacts, so identical inputs produce differing outputs. +- **Unpinned Build Environments**: Building with undocumented or unpinned toolchains and dependencies, so no one can recreate the environment that produced a release. +- **No Provenance or Attestation**: Publishing releases without provenance describing what was built, from which source, and by which pipeline. + +## Impact + +Attackers can conceal tampering with the app's released binaries by: + +- Distributing tampered builds that cannot be distinguished from legitimate ones. +- Compromising a dependency, SDK, or build tool in the app's supply chain. + +This can lead to: + +- **Execution of Unauthorized Code**: Attackers can inject code during the build or distribution process without detection, since no independent party can verify the binary against the source, resulting in malicious code shipping to the entire user base. +- **Loss of User Trust**: Users and auditors cannot verify that the shipped app matches the published source, resulting in weakened trust in the app, particularly for security- and privacy-sensitive apps. + +## Mitigations + +- **Make Builds Deterministic**: Eliminate timestamps, absolute paths, environment-dependent data, and unstable orderings from build outputs, following [reproducible-builds.org](https://reproducible-builds.org/) guidance. +- **Pin and Document the Build Environment**: Define the exact toolchain and dependency versions in version control so any party can recreate the build environment. +- **Publish Provenance and Attestations**: Generate build provenance (e.g. per [SLSA](https://slsa.dev/)) and, where feasible, publish verification instructions so third parties can reproduce and compare releases. diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0008.md b/weaknesses/MASVS-CRYPTO/MASWE-0008.md index 26ac125..355c6e6 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0008.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0008.md @@ -14,22 +14,37 @@ refs: - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-132.pdf - https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html -draft: - description: | - Cryptographic keys are frequently derived from passwords, passphrases, or other - low-entropy inputs using a Key Derivation Function (KDF). When the KDF is chosen - or configured incorrectly, the derived key is far weaker than intended and can be - recovered through brute-force or dictionary attacks. Common problems include using - a fast, general-purpose hash instead of a dedicated password-based KDF, an - insufficient iteration/work factor, a missing or predictable salt, or deriving keys - from inputs with insufficient entropy. - topics: - - use of a password-based KDF (e.g. PBKDF2, scrypt, Argon2, bcrypt) instead of a plain hash - - insufficient iteration count / work factor (e.g. PBKDF2 with too few iterations) - - missing, hardcoded, or reused salt - - derivation from inputs with insufficient entropy - - selecting KDF parameters per NIST.SP.800-132 and current OWASP guidance -status: placeholder - +status: new --- +## Overview + +This weakness occurs when cryptographic keys are derived from passwords, passphrases, or other low-entropy inputs using a key derivation function (KDF) that is missing, unsuitable, or misconfigured. + +Dedicated password-based KDFs, such as PBKDF2, scrypt, or Argon2, are deliberately expensive to compute and combine the input with a unique random salt, so that each guess costs the attacker significant effort and precomputed tables become useless. When a fast, general-purpose hash is used instead, or when the KDF is configured with a weak work factor or salt, the derived key is far weaker than its nominal length suggests and can be recovered with far less effort than intended. + +## Modes of Introduction + +- **Plain Hash Instead of a KDF**: Deriving keys by applying a fast, general-purpose hash function to a password or passphrase instead of using a dedicated password-based KDF. +- **Insufficient Work Factor**: Configuring the KDF with too few iterations or with memory and parallelism parameters below current recommendations. +- **Missing or Predictable Salt**: Omitting the salt, hardcoding it in the app, or reusing the same salt across users or installations. +- **Low-Entropy Input**: Deriving keys from inputs with insufficient entropy, such as short PINs or predictable device values, without combining them with additional secret material. + +## Impact + +Attackers can predict or reproduce improperly derived cryptographic keys by: + +- Performing offline brute-force or dictionary attacks against keys derived from low-entropy inputs. +- Precomputing derived keys when salts are missing, hardcoded, or reused. + +This can lead to: + +- **Compromise of Sensitive Data**: Attackers can decrypt protected information or forge encrypted data, resulting in unauthorized disclosure or modification of sensitive data. +- **Authentication or Authorization Bypass**: Attackers can recover passwords or derived credentials, resulting in unauthorized access to protected accounts, data, or functionality. + +## Mitigations + +- **Use a Password-Based KDF**: Derive keys from passwords or passphrases only with a dedicated password-based KDF such as PBKDF2, scrypt, or Argon2, following [NIST.SP.800-132](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-132.pdf) and the current [OWASP Password Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html) recommendations. +- **Use an Adequate Work Factor**: Configure iteration counts, memory, and parallelism parameters according to current guidance, and revisit them periodically as hardware improves. +- **Use Unique Random Salts**: Generate a unique salt with a cryptographically secure random number generator for every derivation and store it alongside the derived material; never hardcode or reuse salts. +- **Strengthen Low-Entropy Inputs**: When the input has low entropy (e.g. a PIN), combine the derived key with additional secret material, such as a random key stored in the platform keystore, so the result cannot be brute-forced from the user input alone. diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0009.md b/weaknesses/MASVS-CRYPTO/MASWE-0009.md index 96402d0..98c9b09 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0009.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0009.md @@ -12,20 +12,34 @@ mappings: refs: - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf - https://developers.google.com/tink/managing-key-rotation -draft: - description: | - Cryptographic keys have a limited cryptoperiod after which they should be retired and - replaced. Key rotation limits the amount of data protected by any single key and bounds - the impact of a key compromise. When an app never rotates its keys, a single compromised - key exposes all data ever protected with it. This is especially important for long-lived - keys and asymmetric keys. Rotation must be implemented so that data protected under old - keys can still be decrypted/verified (e.g. via keysets with versioned keys) while new - operations use the current key. - topics: - - long-lived keys and cryptoperiods (as per NIST.SP.800-57pt1r5) - - versioned keysets and graceful re-encryption (e.g. Tink key rotation) - - retiring and destroying superseded keys -status: placeholder - +status: new --- +## Overview + +This weakness occurs when an app uses cryptographic keys beyond their intended cryptoperiod without rotating them, so that a single key protects an ever-growing amount of data over an unbounded lifetime. + +Cryptographic keys have a limited cryptoperiod, as defined in [NIST.SP.800-57pt1r5](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf), after which they should be retired and replaced. Key rotation limits the amount of data protected by any single key and bounds the impact of a key compromise. This is especially important for long-lived symmetric keys and asymmetric key pairs. Rotation must be implemented so that data protected under old keys can still be decrypted or verified, for example via keysets with versioned keys, while new operations use the current key. + +## Modes of Introduction + +- **No Rotation Mechanism**: Designing storage formats or protocols around a single static key, with no key versioning or keyset support that would allow the key to be replaced. +- **Unbounded Cryptoperiods**: Using keys indefinitely without defining a cryptoperiod or expiry after which they must be retired and replaced. +- **Superseded Keys Not Retired**: Keeping old keys active and usable for new operations after rotation, instead of restricting them to decryption or verification of existing data and eventually destroying them. + +## Impact + +Attackers can decrypt or forge all data ever protected with a compromised key by: + +- Applying a single compromised key to all current and historical data protected with it. + +This can lead to: + +- **Compromise of Sensitive Data**: Attackers can decrypt the entire history of data protected with the compromised key, resulting in a much larger disclosure than a rotation-bounded compromise would allow. +- **Authentication or Authorization Bypass**: Attackers can keep forging valid cryptographic values indefinitely with a long-lived compromised key, resulting in persistent unauthorized access that is not curtailed by key expiry. + +## Mitigations + +- **Define Cryptoperiods**: Assign each key a cryptoperiod appropriate to its type and usage as outlined in [NIST.SP.800-57pt1r5](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf), and replace keys when it elapses or upon suspicion of compromise. +- **Use Versioned Keysets**: Structure key material as a keyset with key versions (e.g. as implemented by [Tink key rotation](https://developers.google.com/tink/managing-key-rotation)), so that new data is protected with the current key while older data remains readable during migration. +- **Re-Encrypt and Retire Old Keys**: After rotating, re-encrypt or re-protect existing data under the new key where feasible, restrict superseded keys to decryption or verification only, and securely destroy them once they are no longer needed. diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0010.md b/weaknesses/MASVS-CRYPTO/MASWE-0010.md index 8037ab3..e8a3351 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0010.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0010.md @@ -16,28 +16,40 @@ refs: - https://developer.apple.com/documentation/security/restricting-keychain-item-accessibility - https://source.android.com/docs/security/features/keystore/strongbox - https://developer.apple.com/documentation/security/ksecattrtokenidsecureenclave -draft: - description: Ensuring that cryptographic keys are accessible only under strict conditions, - such as when the device is unlocked by an authenticated user, within secure application - contexts, bound to the current device, or for limited periods of time, is critical to maintaining the confidentiality - and integrity of encrypted data. This applies even to keys generated inside a hardware - security module such as Android StrongBox or the iOS Secure Enclave, where access - restrictions (user authentication, unlocked-device requirement, usage authorization) - must still be configured explicitly. - topics: - - keys generated inside StrongBox / Secure Enclave still requiring access restrictions - - from a Background Process - - locked device (iOS kSecAttrAccessibleWhenUnlockedThisDeviceOnly, Android setUnlockedDeviceRequired) - - device-bound or non-transferable (iOS ThisDeviceOnly) - - time-based access (duration) - - Require User Presence - - application-specific password - - biometric authentication - - key use restricted e.g. requiring user auth with biometrics, User Presence. - - especially for sensitive operations - - keys restricted/authorized for a duration of time or specific crypto operation, - etc. -status: placeholder - +status: new --- +## Overview + +This weakness occurs when cryptographic keys can be used without restrictions on who may use them, under which device conditions, and for how long. + +Platform keystores allow developers to bind key usage to strict conditions, such as requiring user authentication, requiring the device to be unlocked, binding the key to the current device, or limiting the validity of an authorization to a short period or a single operation. When these restrictions are not configured, any code running as the app, or any actor in possession of the device, can use the keys freely. This applies even to keys generated inside a hardware security module such as Android StrongBox or the iOS Secure Enclave: hardware backing protects the key material from extraction, but usage restrictions must still be configured explicitly. + +## Modes of Introduction + +- **No User Authentication Requirement**: Creating keys that can be used without requiring the user to authenticate (e.g. with biometrics or device credentials) for each sensitive operation. +- **Usable While the Device Is Locked**: Not restricting key or Keychain item availability to the unlocked device state (e.g. `setUnlockedDeviceRequired` on Android or `kSecAttrAccessibleWhenUnlockedThisDeviceOnly` on iOS). +- **Not Device-Bound**: Allowing key material to migrate to other devices via backups or transfers instead of using device-only protection classes. +- **Unbounded Authorization Validity**: Configuring long authentication validity durations so that a single user authentication authorizes key use indefinitely, rather than for a short window or a single operation. +- **Assuming Hardware Implies Restriction**: Generating keys inside StrongBox or the Secure Enclave without configuring access restrictions, assuming the hardware alone limits who can use the key. + +## Impact + +Attackers can use the app's cryptographic keys without authorization by: + +- Invoking keystore operations on a compromised or stolen device when key use does not require user authentication. +- Using dynamic instrumentation. +- Debugging the app at runtime. + +This can lead to: + +- **Compromise of Sensitive Data**: Attackers can decrypt protected information or forge encrypted data without ever extracting the key, resulting in unauthorized disclosure or modification of sensitive data. +- **Authentication or Authorization Bypass**: Attackers can perform signing or authentication operations reserved for the legitimate user, resulting in unauthorized transactions or access to protected functionality. + +## Mitigations + +- **Require User Authentication for Key Use**: Bind keys used for sensitive operations to user authentication, e.g. biometric or device-credential authentication on Android (`setUserAuthenticationRequired`) or Keychain access control flags on iOS, so each use requires the user's presence. +- **Restrict Keys to Unlocked Devices**: Configure keys and Keychain items so they are only available while the device is unlocked (e.g. `setUnlockedDeviceRequired(true)` on Android, `kSecAttrAccessibleWhenUnlockedThisDeviceOnly` on iOS). +- **Bind Keys to the Device**: Use device-only protection classes so key material cannot leave the device via backups or transfers. +- **Limit Authorization Validity**: Keep authentication validity durations short or require authentication per operation, so a single unlock does not authorize unlimited key use. +- **Configure Restrictions Even for Hardware-Backed Keys**: Apply the same user-authentication, unlocked-device, and validity restrictions to keys generated in StrongBox or the Secure Enclave; hardware backing protects against extraction, not against unauthorized use. diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0012.md b/weaknesses/MASVS-CRYPTO/MASWE-0012.md index 676e3d5..696d47d 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0012.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0012.md @@ -15,19 +15,34 @@ refs: - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf - https://en.wikipedia.org/wiki/Collision_attack - https://csrc.nist.gov/pubs/ir/8547/ipd -draft: - description: | - Using broken or unsuitable hash functions in a security-sensitive context can - compromise data integrity and authenticity. Broken algorithms such as MD5 and SHA-1 - are vulnerable to collision attacks and must not be used where collision or - second-preimage resistance is required (e.g. digital signatures, integrity checks, - certificate fingerprints). Note that password/passphrase handling requires a - dedicated password-based KDF rather than a plain hash (see @MASWE-0008). - topics: - - broken hashing algorithms (e.g. MD5, SHA-1) - - collision and second-preimage resistance requirements - - selecting an approved hash function (e.g. SHA-256/SHA-3) per NIST guidance -status: placeholder - +status: new --- +## Overview + +This weakness occurs when a broken or unsuitable hash function is used in a security-sensitive context, such as integrity checks, digital signatures, or certificate fingerprints. + +Broken algorithms such as MD5 and SHA-1 are vulnerable to collision attacks and must not be used where collision or second-preimage resistance is required. Using an otherwise sound hash function for the wrong job is equally problematic: passwords and passphrases require a dedicated password-based key derivation function rather than a plain hash (see @MASWE-0008), and non-cryptographic checksums provide no security at all. + +## Modes of Introduction + +- **Broken Hash Algorithms**: Using algorithms such as MD5 or SHA-1 in contexts that require collision or second-preimage resistance, e.g. digital signatures, integrity verification, or fingerprinting. +- **Wrong Hash for the Job**: Using a plain, fast hash for password storage or key derivation instead of a password-based KDF (see @MASWE-0008), or using non-cryptographic checksums such as CRC-32 where a cryptographic hash is required. +- **Truncated Digests**: Truncating hash output below the security strength required by the use case, reducing collision and preimage resistance. + +## Impact + +Attackers can forge or replay data that passes hash-based integrity or authenticity checks by: + +- Crafting collisions or second preimages for broken hash functions. + +This can lead to: + +- **Compromise of Sensitive Data**: Attackers can substitute or modify data without invalidating its hash, resulting in undetected manipulation of sensitive information. +- **Authentication or Authorization Bypass**: Attackers can forge artifacts whose authenticity is established via hashes, such as signed payloads or fingerprinted certificates, resulting in impersonation or unauthorized access. + +## Mitigations + +- **Use Approved Hash Functions**: Use hash functions approved by current standards, such as SHA-256 or stronger members of the SHA-2 and SHA-3 families, per [NIST.SP.800-131Ar2](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf), and follow emerging post-quantum guidance such as [NIST IR 8547](https://csrc.nist.gov/pubs/ir/8547/ipd). +- **Use Password-Based KDFs for Passwords**: Never hash passwords or passphrases directly; use a dedicated password-based KDF as described in @MASWE-0008. +- **Preserve Digest Length**: Do not truncate digests below the security strength required by the use case. diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0013.md b/weaknesses/MASVS-CRYPTO/MASWE-0013.md index 18219da..5b5c2a7 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0013.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0013.md @@ -17,28 +17,43 @@ refs: - https://datatracker.ietf.org/doc/html/rfc6151 - https://web.archive.org/web/20170810051504/http://www.tcs.hut.fi/old/papers/aura/aura-csfws97.pdf - https://en.wikipedia.org/wiki/Replay_attack -draft: - description: | - A Message Authentication Code (MAC) provides integrity and authenticity for a message using a - shared secret key. Improper use of a MAC in a security-sensitive context undermines these - guarantees and can let attackers forge or replay messages, or learn information through side - channels. Typical problems include using a MAC key for more than one purpose or with an - unauthorized algorithm, keys with insufficient entropy, MACs built on broken hash functions - (e.g. MD5/SHA-1), non-cryptographic checksums (e.g. CRC-32) used where a MAC is required, - fragile constructions (e.g. raw CBC-MAC on variable-length messages), truncated tags, missing - replay protection (timestamp/nonce), and incorrect MAC-then-encrypt / encrypt-then-MAC ordering - that leaks information via timing or error messages. - topics: - - Using a MAC key for more than one purpose or with an unauthorized algorithm (key separation) - - Using HMAC with keys with insufficient entropy - - Using HMAC with missing timestamp (or nonce) - - Using MAC‑then‑encrypt or encrypt‑then‑MAC incorrectly, leaking information via timing or error messages - - Allowing predictors (users or attackers) to control data inputs, creating scenarios where forged or replayed tags bypass integrity checks. - - Hash functions lacking collision resistance (e.g., MD5 or SHA‑1 used in HMAC) - - Use of non‑cryptographic checksums (e.g., CRC‑32 instead of HMAC) - - MAC constructions that fail outside narrow assumptions (e.g., raw CBC‑MAC on variable‑length messages) - - Tags that are too short significantly lower the effort required for forgery -status: placeholder - +status: new --- +## Overview + +This weakness occurs when a Message Authentication Code (MAC) is missing, built on broken primitives, or used incorrectly in a security-sensitive context, so the integrity and authenticity of messages are no longer guaranteed. + +A MAC provides integrity and authenticity for a message using a shared secret key. These guarantees only hold when the MAC algorithm is sound, the key is strong and used for a single purpose, the tag is long enough, verification does not leak information, and the protocol prevents captured messages from being accepted again. + +## Modes of Introduction + +- **Non-Cryptographic Checksums**: Using checksums such as CRC-32 where a MAC is required; checksums detect accidental corruption but can be trivially recomputed by an attacker. +- **MACs Built on Broken Hashes**: Building MACs on hash functions lacking collision resistance, such as MD5 or SHA-1. +- **Weak or Reused MAC Keys**: Using MAC keys with insufficient entropy, or using a MAC key for more than one purpose or with an unauthorized algorithm, violating key-separation principles. +- **Fragile Constructions**: Using constructions that fail outside narrow assumptions, such as raw CBC-MAC on variable-length messages, or composing encryption and authentication incorrectly (e.g. MAC-then-encrypt where encrypt-then-MAC is required). +- **Truncated Tags**: Using authentication tags that are too short, significantly lowering the effort required for forgery. +- **Missing Replay Protection**: Authenticating messages without a timestamp, nonce, or sequence number, so previously captured valid messages remain acceptable. +- **Observable Verification Failures**: Exposing timing differences or detailed error messages during MAC verification that can serve as an oracle. + +## Impact + +Attackers can forge or replay messages that the app or its backend accepts as authentic by: + +- Replaying previously captured valid messages or tags. +- Performing cryptanalysis of broken algorithms, modes, or parameters. +- Brute-forcing cryptographic material generated with insufficient length. + +This can lead to: + +- **Compromise of Sensitive Data**: Attackers can modify protected messages or stored data without detection, resulting in undetected manipulation of sensitive information. +- **Authentication or Authorization Bypass**: Attackers can forge or replay authenticated messages, such as commands or transactions, resulting in unauthorized actions being executed on behalf of the user. + +## Mitigations + +- **Use Standard MAC Algorithms**: Use HMAC with an approved hash function (SHA-256 or stronger) or an approved authenticated mode, following [NIST SP 800-224](https://csrc.nist.gov/pubs/sp/800/224/ipd) and [NIST.SP.800-131Ar2](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf); never use non-cryptographic checksums for security purposes. +- **Use Strong, Single-Purpose Keys**: Generate MAC keys with a cryptographically secure random number generator and use each key for only one purpose and algorithm. +- **Prefer AEAD or Encrypt-then-MAC**: When combining encryption and authentication, use an AEAD mode (e.g. AES-GCM) or the encrypt-then-MAC composition. +- **Use Full-Length Tags**: Do not truncate authentication tags below the length required by the security level of the use case. +- **Add Replay Protection**: Include and verify a timestamp, nonce, or sequence number in authenticated messages so captured messages cannot be replayed. +- **Verify in Constant Time**: Compare tags using constant-time comparison and return uniform errors so verification cannot be used as an oracle. diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0014.md b/weaknesses/MASVS-CRYPTO/MASWE-0014.md index 40611dc..6b54a70 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0014.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0014.md @@ -15,20 +15,38 @@ refs: - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf - https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf - https://csrc.nist.gov/pubs/ir/8547/ipd -draft: - description: | - Cryptographic signatures must be generated with algorithms and parameters of - sufficient strength to guarantee integrity and authenticity. Using weak or deprecated - schemes (e.g. SHA1withRSA), short keys, or reusing a signing key for other purposes - undermines the signature's security and can allow forgery. Randomness used during - signing (e.g. the per-signature nonce in (EC)DSA) must be unpredictable and unique. - topics: - - weak or deprecated signature algorithms (e.g. SHA1withRSA) - - insufficient key length for the signing algorithm - - predictable or reused per-signature nonce in (EC)DSA - - using a signing key for more than one purpose (key separation) - - selecting approved signature schemes per NIST FIPS 186-5 -status: placeholder - +status: new --- +## Overview + +This weakness occurs when cryptographic signatures are generated with weak algorithms, insufficient parameters, or flawed randomness, undermining the integrity and authenticity guarantees they are meant to provide. + +Signatures are only as strong as the scheme and parameters behind them: deprecated combinations such as SHA1withRSA, keys that are too short, and signing keys reused for other purposes all weaken the guarantee. In addition, the randomness used during signing is critical: in (EC)DSA, a predictable or reused per-signature nonce allows the private key itself to be recovered from observed signatures. + +## Modes of Introduction + +- **Weak or Deprecated Signature Algorithms**: Generating signatures with deprecated schemes or digest combinations, such as SHA1withRSA. +- **Insufficient Key Length**: Using signing keys shorter than the lengths recommended by current standards for the chosen algorithm. +- **Predictable Signature Nonces**: Generating the per-signature nonce in (EC)DSA with insufficient entropy, or reusing it across signatures. +- **Key Reuse Across Purposes**: Using a signing key for other purposes, such as encryption or key agreement, violating key-separation principles. + +## Impact + +Attackers can forge signatures or recover signing keys by: + +- Recovering private keys from predictable or reused signature nonces. +- Performing cryptanalysis of broken algorithms, modes, or parameters. +- Brute-forcing cryptographic material generated with insufficient length. + +This can lead to: + +- **Authentication or Authorization Bypass**: Attackers can sign arbitrary data as the app or user, resulting in impersonation and unauthorized transactions or API calls accepted by peers that trust the signature. +- **Compromise of Sensitive Data**: Attackers can tamper with signed data while producing valid signatures for it, resulting in undetected manipulation of information whose integrity depends on the signature. + +## Mitigations + +- **Use Approved Signature Schemes**: Generate signatures with schemes approved in [NIST FIPS 186-5](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf), such as ECDSA, RSA-PSS, or EdDSA, with approved digests, and follow post-quantum migration guidance such as [NIST IR 8547](https://csrc.nist.gov/pubs/ir/8547/ipd). +- **Use Sufficient Key Lengths**: Ensure signing keys meet or exceed the lengths recommended by [NIST.SP.800-131Ar2](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf) for the chosen algorithm. +- **Ensure Nonce Uniqueness**: Generate (EC)DSA per-signature nonces with a cryptographically secure random number generator, or use deterministic schemes (e.g. RFC 6979 deterministic ECDSA or Ed25519) that eliminate nonce misuse. +- **Use Signing Keys for a Single Purpose**: Keep signing keys dedicated to signing and generate separate keys for other operations. diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0015.md b/weaknesses/MASVS-CRYPTO/MASWE-0015.md index bf9a262..50c6336 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0015.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0015.md @@ -13,20 +13,36 @@ mappings: refs: - https://cwe.mitre.org/data/definitions/347.html - https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf -draft: - description: | - Cryptographic signature verification must be implemented correctly to guarantee the - integrity and authenticity of data. Common failures include skipping verification - entirely, ignoring or not checking the verification result, accepting signatures from - untrusted or unpinned keys, failing to validate the full certificate/trust chain, or - using algorithms and parameters that do not match the signer's. Any of these lets an - attacker present forged or tampered data as authentic. - topics: - - verification result not checked or ignored - - accepting signatures without validating the signer's key/trust chain - - algorithm confusion or accepting weak/deprecated signature algorithms - - verifying against attacker-controllable public keys -status: placeholder - +status: new --- +## Overview + +This weakness occurs when an app fails to verify cryptographic signatures correctly, accepting forged or tampered data as authentic. + +Signature verification protects the integrity and authenticity of data such as updates, configuration, licenses, or tokens. The guarantee breaks down when verification is skipped, when its result is ignored, when the signer's key is not validated against a trusted identity, or when the app lets the attacker influence which algorithm or key is used for verification. + +## Modes of Introduction + +- **Verification Skipped or Result Ignored**: Not verifying signatures on security-relevant data, or computing the verification but proceeding regardless of its result. +- **Untrusted or Unpinned Signer Keys**: Accepting signatures without validating the signer's key against a trusted set or certificate chain, or verifying against public keys that ship alongside the data and can be replaced by an attacker. +- **Algorithm Confusion**: Accepting the algorithm declared by the data being verified (e.g. a token header), including weak, deprecated, or "none" algorithms, instead of enforcing the expected one. + +## Impact + +Attackers can present forged or tampered data as authentic by: + +- Presenting data with invalid, stripped, or attacker-signed signatures that the app accepts. + +This can lead to: + +- **Execution of Unauthorized Code**: Attackers can deliver tampered updates, plugins, or configuration that the app accepts as genuine, resulting in attacker-controlled code or behavior running within the app. +- **Authentication or Authorization Bypass**: Attackers can forge signed tokens or assertions (e.g. session or license tokens), resulting in unauthorized access to protected accounts, data, or functionality. +- **Compromise of Sensitive Data**: Attackers can substitute tampered data for authentic data without detection, resulting in the app processing or displaying manipulated information. + +## Mitigations + +- **Always Verify and Check the Result**: Verify signatures on all security-relevant data and treat any verification failure as fatal for the operation; never proceed on an ignored or swallowed result. +- **Validate the Signer's Identity**: Verify signatures only against keys anchored in a trusted set, such as pinned keys or a validated certificate chain, and never against keys delivered alongside the data itself. +- **Enforce the Expected Algorithm**: Allow-list the exact signature algorithms the app expects and reject anything else, including "none" or algorithms chosen by the data being verified. +- **Use Approved Schemes**: Verify with signature schemes approved in [NIST FIPS 186-5](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf) and reject weak or deprecated ones. diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0028.md b/weaknesses/MASVS-PLATFORM/MASWE-0028.md index 9746d9f..5e43c7c 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0028.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0028.md @@ -10,19 +10,41 @@ mappings: masvs-v2: [MASVS-PLATFORM-3, MASVS-STORAGE-2] cwe: [200, 359] maswe-beta: [MASWE-0053] -draft: - description: | - Sensitive data such as passwords, PINs, card numbers, or other PII may be exposed - directly through the user interface, for example by displaying it in cleartext, allowing - it to be copied to the clipboard, keeping it in the keyboard cache via auto-correct, or - not using secure text entry fields. An attacker with brief access to the device or its - screen can then read this information. - topics: - - secure text entry (e.g. secureTextEntry / inputType textPassword) - - disabling copy/paste for sensitive fields - - disabling auto-correct / keyboard caching for sensitive fields - - masking or redacting sensitive values shown on screen -status: placeholder - +refs: +- https://developer.android.com/develop/ui/views/text-and-emoji/edittext#SpecifyKeyboardType +- https://developer.apple.com/documentation/uikit/uitextinputtraits/1624427-issecuretextentry +status: new --- +## Overview + +This weakness occurs when sensitive data, such as passwords, PINs, card numbers, or other personal information, is unnecessarily exposed through the app's user interface. + +Typical exposure paths include displaying values in cleartext when masking would suffice, allowing sensitive values to be copied to the clipboard, letting the keyboard cache or auto-correct learn from sensitive input, and not using secure text entry for secret fields. Anyone with brief access to the device or a view of its screen can then read the information. + +## Modes of Introduction + +- **Non-Secure Text Entry**: Building password or PIN fields without secure text entry (e.g. `isSecureTextEntry` on iOS, `textPassword` input types on Android), so the input is shown in cleartext. +- **Copy Allowed on Sensitive Fields**: Allowing users to copy sensitive values, placing them on the shared clipboard. +- **Keyboard Caching and Auto-Correct**: Using input types that let the keyboard cache or auto-correct dictionaries learn sensitive input. +- **Unmasked Sensitive Values**: Displaying full values (e.g. complete card numbers or personal identifiers) where a masked or partial representation would suffice. + +## Impact + +Attackers can capture sensitive data displayed or entered in the user interface by: + +- Observing the device screen while sensitive data is displayed or entered (shoulder surfing). +- Reading sensitive data from the clipboard when users copy it between apps. +- Accessing the device storage on a compromised device. + +This can lead to: + +- **Compromise of Sensitive Data**: Attackers can read personal or financial information from the screen, the clipboard, or keyboard cache files, resulting in unauthorized disclosure of user data. +- **Authentication or Authorization Bypass**: Attackers can capture credentials, PINs, or one-time codes exposed through the UI, resulting in unauthorized access to the user's accounts. + +## Mitigations + +- **Use Secure Text Entry**: Configure secret fields with the platform's secure input types so the input is masked and excluded from keyboard learning. +- **Disable Copy for Sensitive Fields**: Prevent copying of sensitive values to the clipboard where it is not essential. +- **Disable Keyboard Caching**: Use non-caching input types for sensitive fields so keyboards and auto-correct do not retain the values. +- **Mask Displayed Values**: Show masked or partial representations of sensitive values and reveal the full value only on explicit user request. diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0029.md b/weaknesses/MASVS-PLATFORM/MASWE-0029.md index b765183..c33a34f 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0029.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0029.md @@ -9,17 +9,37 @@ mappings: masvs-v2: [MASVS-PLATFORM-3, MASVS-STORAGE-2] cwe: [200, 359] maswe-beta: [MASWE-0054] -draft: - description: | - Apps may place sensitive data (e.g. OTPs, message contents, account details) into - notifications. Notifications are rendered on the lock screen and can be read by other apps - holding notification access (e.g. an Android `NotificationListenerService`), leaking the - data to unauthorized parties or the shoulder-surfing observer. - topics: - - sensitive content shown in notifications on the lock screen - - notifications readable by other apps (e.g. NotificationListenerService) - - notification visibility levels and redaction for sensitive notifications -status: placeholder - +refs: +- https://developer.android.com/develop/ui/views/notifications/build-notification#lockscreenNotification +- https://developer.apple.com/documentation/usernotifications +status: new --- +## Overview + +This weakness occurs when an app places sensitive data, such as one-time codes, message contents, or account details, into system notifications without restricting where and to whom they are visible. + +Notifications are rendered on the lock screen, where anyone holding the device can read them without unlocking it, and they can be read by other apps that hold notification access (e.g. an Android `NotificationListenerService`). Any sensitive value included in a notification therefore leaves the app's control the moment it is posted. + +## Modes of Introduction + +- **Sensitive Content in Notifications**: Including one-time codes, message contents, financial details, or other sensitive values directly in notification titles or bodies. +- **No Lock-Screen Redaction**: Not configuring notification visibility so that sensitive content is redacted or hidden on the lock screen. + +## Impact + +Attackers can access sensitive data shown in notifications by: + +- Reading notification content shown on the lock screen without unlocking the device. +- Reading notification content from another app holding notification-access permissions. + +This can lead to: + +- **Compromise of Sensitive Data**: Attackers can read message contents or account details from notifications, resulting in unauthorized disclosure of user data. +- **Authentication or Authorization Bypass**: Attackers can capture one-time codes delivered via notifications, resulting in the defeat of SMS- or push-based authentication factors and unauthorized account access. + +## Mitigations + +- **Keep Sensitive Data Out of Notifications**: Use notifications to signal that something happened and reveal the sensitive details only inside the app after unlocking it. +- **Redact Notifications on the Lock Screen**: Configure notification visibility (e.g. private visibility with a public redacted version on Android) so sensitive content is hidden until the device is unlocked. +- **Review Notification Content Regularly**: Audit which notifications the app posts and ensure new features do not introduce sensitive values into them. diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0031.md b/weaknesses/MASVS-PLATFORM/MASWE-0031.md index 2442586..747851f 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0031.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0031.md @@ -14,20 +14,34 @@ mappings: maswe-beta: [MASWE-0056] refs: - https://developer.android.com/topic/security/risks/tapjacking -draft: - description: | - Overlay attacks occur when a malicious app (or an attacker-controlled window) draws content - on top of the target app to trick the user into interacting with it (tapjacking) or to - capture their input. The app is vulnerable when it does not defend against being fully or - partially obscured, e.g. by not using `View.setFilterTouchesWhenObscured(true)` / - `android:filterTouchesWhenObscured="true"` and not ignoring touch events carrying the - `FLAG_WINDOW_IS_PARTIALLY_OBSCURED` flag. This can lead the user to unknowingly approve - sensitive actions or disclose sensitive input. - topics: - - tapjacking (full and partial occlusion) - - filtering touches when the window is obscured - - protecting sensitive confirmation screens from overlays -status: placeholder - +status: new --- +## Overview + +This weakness occurs when an app does not defend its sensitive screens against being fully or partially obscured by attacker-controlled windows. + +In an overlay attack, a malicious app draws content on top of the target app to trick the user into interacting with it (tapjacking) or to capture their input. The user believes they are interacting with the visible overlay while their touches reach the app underneath, or vice versa. Sensitive confirmation screens, permission-like prompts, and input fields are the typical targets. + +## Modes of Introduction + +- **Touch Filtering Not Enabled**: Not enabling touch filtering on sensitive views (e.g. `setFilterTouchesWhenObscured(true)` or `android:filterTouchesWhenObscured="true"`) and not discarding touch events flagged as obscured (e.g. `FLAG_WINDOW_IS_PARTIALLY_OBSCURED`). +- **Sensitive Screens Not Protected**: Presenting confirmation dialogs or security-relevant screens without any occlusion defense, so their content can be covered or mimicked by an overlay. + +## Impact + +Attackers can hijack user interactions with the app by: + +- Displaying overlays or tampering with the UI to alter what the user sees while approving an action. + +This can lead to: + +- **Financial Loss**: Attackers can trick users into confirming payments or transfers they believe to be something else, resulting in direct financial harm to the user. +- **Authentication or Authorization Bypass**: Attackers can trick users into granting permissions or approving security prompts, resulting in unauthorized access to protected data or functionality. +- **Compromise of Sensitive Data**: Attackers can capture input entered into overlay-mimicked fields, resulting in the disclosure of credentials or other sensitive user input. + +## Mitigations + +- **Enable Touch Filtering on Sensitive Views**: Configure sensitive views to ignore touches delivered while the window is obscured, and discard motion events flagged as (partially) obscured. +- **Protect Sensitive Screens**: Apply overlay defenses to confirmation and authentication screens specifically, and consider pausing or hiding sensitive content when the app detects it is being drawn over. +- **Use Trusted Confirmation Paths for Critical Actions**: For the most critical approvals, use hardware-protected confirmation mechanisms that overlays cannot forge (see @MASWE-0019). diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0032.md b/weaknesses/MASVS-PLATFORM/MASWE-0032.md index a8fdb1f..485cbfc 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0032.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0032.md @@ -12,24 +12,40 @@ mappings: android-risks: - https://developer.android.com/privacy-and-security/risks/unsafe-use-of-deeplinks maswe-beta: [MASWE-0058] -draft: - description: | - Deep links (Android App Links and custom URL schemes, iOS Universal Links and custom schemes) let - other apps and websites launch the app at a specific screen and pass parameters. They become - insecure when the app relies on unverified custom URL schemes (which any app can claim), does not - verify App Links / Universal Links through domain association, or fails to validate and sanitize - the incoming URL and its parameters. Because deep-link input is attacker-controllable, a malformed - URI or parameter can trigger injection or logic abuse at various points in the app (CWE-939 for - source verification, CWE-917 for content/expression injection). - topics: - - URL Custom Schemes (claimable by any app) - - Android App Links / iOS Universal Links domain association (autoVerify, apple-app-site-association) - - validating and sanitizing the deep-link URL and its parameters - - injection via unsanitized deep-link parameters (CWE-917 / CWE-939) - - platform/OS-version differences in deep-link security refs: - https://developer.apple.com/documentation/technotes/tn3155-debugging-universal-links -status: placeholder - +- https://developer.android.com/training/app-links/verify-android-applinks +status: new --- +## Overview + +This weakness occurs when an app handles deep links insecurely, relying on unverified schemes or trusting the attacker-controllable data they carry. + +Deep links (Android App Links and custom URL schemes, iOS Universal Links and custom schemes) let other apps and websites launch the app at a specific screen and pass parameters. They become insecure when the app relies on custom URL schemes that any app can claim, does not verify App Links or Universal Links through domain association, or fails to validate and sanitize the incoming URL and its parameters. Because deep-link input is attacker-controllable, a malformed URI or parameter can trigger injection or logic abuse at various points in the app. + +## Modes of Introduction + +- **Unverified Custom URL Schemes**: Relying on custom URL schemes for sensitive flows even though any installed app can claim the same scheme. +- **Missing Domain Association**: Declaring App Links without `autoVerify` and Digital Asset Links, or Universal Links without a valid apple-app-site-association file, so links are not cryptographically tied to the app's domain. +- **Unvalidated Deep-Link Input**: Passing the deep-link URL and its parameters into navigation decisions, WebViews, or queries without validation and sanitization. + +## Impact + +Attackers can hijack deep links or inject malicious input into the app by: + +- Registering the same custom URL scheme to intercept links intended for the app. +- Delivering crafted deep links or intents from a malicious app or web page. + +This can lead to: + +- **Compromise of Sensitive Data**: Attackers can intercept tokens or personal data carried in deep links, or exfiltrate data through injected parameters, resulting in unauthorized disclosure of user data. +- **Authentication or Authorization Bypass**: Attackers can capture authentication material delivered via hijacked links (e.g. login or password-reset links), resulting in account takeover. +- **Execution of Unauthorized Code**: Attackers can inject expressions or script through unsanitized deep-link parameters that reach interpreters or WebViews, resulting in attacker-controlled behavior inside the app. + +## Mitigations + +- **Use Verified Link Mechanisms**: Handle sensitive flows only through verified Android App Links (with `autoVerify` and Digital Asset Links) and iOS Universal Links, not through claimable custom schemes. +- **Validate and Sanitize Deep-Link Input**: Treat every deep-link URL and parameter as untrusted input; validate against an allowlist of expected destinations and value formats before use. +- **Validate the Source Where Possible**: Verify the calling application or referrer for custom scheme invocations when the platform allows it. +- **Keep Secrets Out of Deep Links**: Avoid transporting session tokens or other secrets in links; where unavoidable, make them single-use and short-lived. diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0033.md b/weaknesses/MASVS-PLATFORM/MASWE-0033.md index 044317b..3ab2f44 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0033.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0033.md @@ -14,23 +14,37 @@ mappings: refs: - https://developer.android.com/develop/ui/views/touch-and-input/copy-paste#PreventingSensitiveData - https://developer.apple.com/documentation/uikit/uipasteboard -draft: - description: | - The system clipboard is a shared resource: any app (and, on some platforms, nearby devices - via universal clipboard) can read its contents. Copying sensitive data (passwords, OTPs, - card numbers, tokens) to the clipboard, or failing to mark it as sensitive/clear it, can - leak that data to other apps. Apps should avoid placing sensitive data on the clipboard, - mark clipboard content as sensitive where supported (e.g. `EXTRA_IS_SENSITIVE` on Android, - excluding items from universal clipboard on iOS), and clear it when appropriate. - - Note: the general IPC / localhost-server aspects previously covered here have moved to - @MASWE-0020; this weakness exclusively covers improper use of the clipboard. - topics: - - copying sensitive data to the clipboard - - not marking clipboard content as sensitive (e.g. Android EXTRA_IS_SENSITIVE) - - not restricting universal/shared clipboard for sensitive content on iOS - - reading untrusted data from the clipboard without validation -status: placeholder - +status: new --- +## Overview + +This weakness occurs when an app places sensitive data on the system clipboard, or handles clipboard content insecurely, exposing that data beyond the app's control. + +The clipboard is a shared resource: other apps can read its contents, and on some platforms clipboard content synchronizes to nearby devices via a universal clipboard. Copying sensitive data such as passwords, one-time codes, card numbers, or tokens to the clipboard, failing to mark it as sensitive, or leaving it there indefinitely can leak that data to other apps and devices. + +## Modes of Introduction + +- **Sensitive Data Copyable**: Allowing sensitive values such as passwords, one-time codes, or card numbers to be copied to the clipboard. +- **Clipboard Content Not Marked Sensitive**: Not flagging copied sensitive content as sensitive where the platform supports it (e.g. `EXTRA_IS_SENSITIVE` on Android), so previews and clipboard history show it in cleartext. +- **Universal Clipboard Not Restricted**: Not restricting sensitive clipboard items to the local device or setting an expiration on iOS, letting them sync to other devices. +- **Clipboard Not Cleared**: Leaving sensitive content on the clipboard after it has served its purpose. +- **Untrusted Clipboard Input**: Processing pasted clipboard data without validation, even though any app can have written it. + +## Impact + +Attackers can capture sensitive data placed on the clipboard by: + +- Reading sensitive data from the clipboard when users copy it between apps. + +This can lead to: + +- **Compromise of Sensitive Data**: Attackers can read personal or financial data from the clipboard, resulting in unauthorized disclosure of user data. +- **Authentication or Authorization Bypass**: Attackers can capture copied credentials or one-time codes, resulting in unauthorized access to the user's accounts. + +## Mitigations + +- **Avoid the Clipboard for Secrets**: Disable copying for sensitive fields and provide secure alternatives such as auto-fill (see @MASWE-0024) so users never need to copy secrets. +- **Mark Clipboard Content as Sensitive**: When sensitive content must be copied, flag it as sensitive so the platform masks previews and treats it accordingly. +- **Restrict Clipboard Scope and Lifetime**: Keep sensitive clipboard items local to the device, set expirations where supported, and clear the clipboard once the data has been used. +- **Validate Pasted Data**: Treat clipboard content as untrusted input and validate it before use. diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0034.md b/weaknesses/MASVS-PLATFORM/MASWE-0034.md index a786e42..99584fe 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0034.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0034.md @@ -10,20 +10,37 @@ mappings: masvs-v2: [MASVS-PLATFORM-1, MASVS-STORAGE-2] cwe: [200] maswe-beta: [MASWE-0061] -draft: - description: | - On iOS, app extensions (e.g. custom keyboards, share and action extensions) run third-party code - that can interact with the host app and observe or exfiltrate the data the app hands to them. An - app that handles sensitive data should restrict which extension point identifiers it allows, for - example by implementing `application(_:shouldAllowExtensionPointIdentifier:)` to reject untrusted - extension categories, and by disabling third-party keyboards via the - `UIApplicationKeyboardExtensionPointIdentifier` for sensitive input fields. Allowing untrusted - extensions unconditionally can leak sensitive user input or content. - topics: - - restricting extensions via application(_:shouldAllowExtensionPointIdentifier:) - - disabling third-party keyboards (UIApplicationKeyboardExtensionPointIdentifier) for sensitive fields - - risks of custom keyboard / share / action extensions handling sensitive data -status: placeholder - +refs: +- https://developer.apple.com/documentation/uikit/uiapplicationdelegate/1623122-application +- https://developer.apple.com/documentation/uikit/uiapplication/extensionpointidentifier/keyboard +status: new --- +## Overview + +This weakness occurs when an app allows untrusted app extensions, such as custom keyboards or share and action extensions, to interact with it and observe the data it handles. + +On iOS, app extensions run third-party code that can interact with the host app and observe or exfiltrate the data the app hands to them. A custom keyboard, for example, sees every keystroke typed while it is active. An app that handles sensitive data should restrict which extension point identifiers it allows, for example by implementing `application(_:shouldAllowExtensionPointIdentifier:)` to reject untrusted extension categories, and by disabling third-party keyboards for sensitive input. + +## Modes of Introduction + +- **All Extension Points Allowed**: Not implementing `application(_:shouldAllowExtensionPointIdentifier:)`, so every extension category, including custom keyboards, can interact with the app. +- **Third-Party Keyboards Allowed for Sensitive Input**: Allowing custom keyboards (the `keyboard` extension point) while users enter credentials, payment data, or other secrets. +- **Sensitive Data Handed to Extensions**: Passing more data than necessary to share or action extensions, which can process and transmit it outside the app's control. + +## Impact + +Attackers can capture sensitive user input and content by: + +- Capturing user input through a malicious custom keyboard or app extension. + +This can lead to: + +- **Compromise of Sensitive Data**: Attackers can log keystrokes or read content handed to a malicious extension, resulting in unauthorized disclosure of personal data typed into or shared from the app. +- **Authentication or Authorization Bypass**: Attackers can capture credentials or one-time codes typed on a malicious keyboard, resulting in unauthorized access to the user's accounts. + +## Mitigations + +- **Restrict Extension Points**: Implement `application(_:shouldAllowExtensionPointIdentifier:)` and reject extension categories the app does not need to support. +- **Keep Sensitive Input on the System Keyboard**: Disable third-party keyboards for sensitive fields; secure text entry fields automatically use the system keyboard. +- **Minimize Data Shared with Extensions**: Hand share and action extensions only the specific items being shared, never broader app data. diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0035.md b/weaknesses/MASVS-PLATFORM/MASWE-0035.md index cfc3d00..af21f1a 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0035.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0035.md @@ -22,21 +22,39 @@ refs: - https://developer.android.com/topic/security/risks/implicit-intent-hijacking - https://developer.android.com/topic/security/risks/pending-intent - https://developer.android.com/topic/security/risks/sticky-broadcast -draft: - description: | - This weakness covers everything related to the insecure handling of Android Intents, e.g. - calling `startActivity`, `startService`, `sendBroadcast`, or `setResult` on untrusted - Intents without validating or sanitizing them. Using an implicit intent to start a service - is a security hazard because you can't be certain what service will respond and the user - can't see which service starts. It also covers mutable pending intents (not using - `FLAG_IMMUTABLE`), replayable pending intents (not using `FLAG_ONE_SHOT`), implicit intent - hijacking, intent redirection, and sticky broadcasts. - topics: - - Insecure Intent Redirection - - Insecure Implicit Intents - - Insecure Pending Intents (mutable, replaying) - - Sticky broadcasts -status: placeholder - +status: new --- +## Overview + +This weakness occurs when an app creates or handles Android intents insecurely, allowing other apps to intercept, redirect, or manipulate its communication. + +Intents are Android's primary inter- and intra-app messaging mechanism. Insecure handling includes sending sensitive data via implicit intents that any matching app can receive, acting on untrusted intents (e.g. calling `startActivity`, `startService`, `sendBroadcast`, or `setResult` on intents received from other apps) without validation, creating PendingIntents that other apps can modify or replay, and using sticky broadcasts, which any app can read and replace. + +## Modes of Introduction + +- **Implicit Intents for Internal Communication**: Using implicit intents, which any matching app can receive, for internal app communication or for carrying sensitive extras. +- **Intent Redirection**: Extracting a nested intent from untrusted extras and forwarding it (e.g. via `startActivity`) without validating its destination, letting other apps reach the app's non-exported components. +- **Mutable PendingIntents**: Creating PendingIntents without `FLAG_IMMUTABLE`, allowing the receiving app to modify the underlying intent and execute it with the app's identity. +- **Replayable PendingIntents**: Creating one-off PendingIntents without `FLAG_ONE_SHOT`, allowing them to be reused. +- **Sticky Broadcasts**: Using sticky broadcasts, which remain accessible after delivery and can be read or replaced by any app. + +## Impact + +Attackers can intercept or manipulate the app's intents by: + +- Registering intent filters to intercept implicit intents sent by the app. +- Modifying or replaying mutable PendingIntents obtained from the app. +- Delivering crafted deep links or intents from a malicious app or web page. + +This can lead to: + +- **Compromise of Sensitive Data**: Attackers can receive sensitive extras carried in implicit intents or broadcasts, resulting in unauthorized disclosure of user or app data to other apps. +- **Authentication or Authorization Bypass**: Attackers can reach non-exported components through intent redirection or execute actions with the app's identity through manipulated PendingIntents, resulting in privileged operations performed on the attacker's behalf. + +## Mitigations + +- **Use Explicit Intents Internally**: Address internal communication to explicit component targets so no other app can receive it, and never place sensitive data in implicit intents. +- **Validate Redirected Intents**: Before forwarding a nested intent from untrusted input, validate its destination against an allowlist and strip unexpected flags. +- **Create Immutable, Explicit PendingIntents**: Build PendingIntents with `FLAG_IMMUTABLE` over explicit base intents, and add `FLAG_ONE_SHOT` where a single use is intended. +- **Avoid Sticky Broadcasts**: Use regular broadcasts protected with permissions, or more targeted mechanisms, instead of sticky broadcasts. diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0036.md b/weaknesses/MASVS-PLATFORM/MASWE-0036.md index 07f04ee..30163d9 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0036.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0036.md @@ -14,19 +14,36 @@ mappings: maswe-beta: [MASWE-0068] refs: - https://support.google.com/faqs/answer/9095419 -draft: - description: | - WebViews can expose native/sensitive functionality to the web content they render, most - commonly through JavaScript bridges (e.g. Android `addJavascriptInterface`, - `WKScriptMessageHandler` / `evaluateJavaScript` on iOS). When such bridges expose more - capability than needed, or are reachable by untrusted content, malicious JavaScript can - invoke native methods, access sensitive data, or perform privileged actions. - topics: - - addJavascriptInterface and other JavaScript bridges - - exposing more native functionality than necessary - - bridges reachable by untrusted web content - - restricting bridge exposure to trusted origins only -status: placeholder - +status: new --- +## Overview + +This weakness occurs when an app exposes sensitive native functionality to the web content rendered in its WebViews, most commonly through JavaScript bridges. + +Bridges such as `addJavascriptInterface` on Android or script message handlers and JavaScript evaluation on iOS let web content invoke native code. When such bridges expose more capability than needed, or are reachable by untrusted content, malicious JavaScript can invoke native methods, access sensitive data, or perform privileged actions with the app's identity. + +## Modes of Introduction + +- **Over-Exposed Bridges**: Exposing more native functionality through the bridge than the web content actually needs. +- **Bridges Reachable by Untrusted Content**: Making bridge interfaces available to any page the WebView loads instead of restricting them to trusted origins. +- **Sensitive Data in Bridge Replies**: Returning sensitive data into the WebView's JavaScript context in a way that any content running in the page can read. + +## Impact + +Attackers can invoke exposed native functionality from web content by: + +- Injecting malicious JavaScript into WebView content (e.g., via MITM on insecure connections or a compromised website). +- Delivering crafted deep links or intents from a malicious app or web page. + +This can lead to: + +- **Compromise of Sensitive Data**: Attackers can call bridge methods that return user or app data, resulting in exfiltration of sensitive information to attacker-controlled servers. +- **Execution of Unauthorized Code**: Attackers can drive native functionality exposed through the bridge, resulting in privileged actions performed within the app's context. + +## Mitigations + +- **Minimize the Bridge Surface**: Expose only the specific methods the web content needs, and strip bridges entirely from WebViews that do not need them. +- **Restrict Bridges to Trusted Origins**: Attach bridges only when loading trusted content and prefer origin-scoped messaging mechanisms over global bridges. +- **Validate Bridge Messages**: Treat every message arriving over the bridge as untrusted input and validate it before acting on it. +- **Return Data Through Scoped Replies**: Use reply mechanisms scoped to the calling message (e.g. script message handlers with replies) instead of injecting sensitive data into the page's global context. diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0037.md b/weaknesses/MASVS-PLATFORM/MASWE-0037.md index 2c9924d..31b1c9e 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0037.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0037.md @@ -14,21 +14,37 @@ mappings: maswe-beta: [MASWE-0069, MASWE-0073] refs: - https://blog.oversecured.com/Android-Exploring-vulnerabilities-in-WebResourceResponse/ -draft: - description: | - When a WebView is configured to access local resources (e.g. `setAllowFileAccessFromFileURLs`, - `setAllowUniversalAccessFromFileURLs`, `setAllowFileAccess`, `setAllowContentAccess`) while - also rendering untrusted content, malicious JavaScript can read app-private files, traverse the - filesystem, or exfiltrate data via XHR. This also covers insecure custom resource loading via - `WebResourceResponse` (instead of `WebViewAssetLoader`), which can serve attacker-controllable - HTML/JS (enabling XSS) and expose files from a protected internal sphere to the less-trusted - WebView JavaScript context or external websites. - topics: - - universal file access from file URLs - - restricting file:// and content:// access - - insecure WebResourceResponse vs. WebViewAssetLoader - - exposing app-private files/data to the WebView JavaScript context -status: placeholder - +status: new --- +## Overview + +This weakness occurs when a WebView is configured to access local resources while also rendering untrusted content, allowing that content to reach files and data outside the web sandbox. + +Settings that enable file or content access (e.g. `setAllowFileAccess`, `setAllowFileAccessFromFileURLs`, `setAllowUniversalAccessFromFileURLs`, `setAllowContentAccess` on Android, or overly broad file read access grants on iOS) let JavaScript running in the WebView read app-private files, traverse the filesystem, or exfiltrate data. Insecure custom resource loading, such as serving internal files through a hand-rolled `WebResourceResponse` instead of a safe asset loader, can likewise expose protected files to the less-trusted WebView JavaScript context or serve attacker-controllable content from the app's own origin. + +## Modes of Introduction + +- **File Access Enabled with Untrusted Content**: Enabling file or content access settings on WebViews that also render untrusted or externally influenced content. +- **Universal Access from File URLs**: Allowing universal or file-URL cross-origin access, so a local HTML file can read other local files and send them to remote origins. +- **Insecure Custom Resource Loading**: Serving internal files through custom response handlers without path validation, instead of a dedicated asset-loading mechanism with a restricted scope. +- **Overly Broad File Read Grants**: Granting the WebView read access to broader directories than the specific content it needs to display. + +## Impact + +Attackers can access local files and app-private data from web content by: + +- Injecting malicious JavaScript into WebView content (e.g., via MITM on insecure connections or a compromised website). +- Delivering crafted deep links or intents from a malicious app or web page. + +This can lead to: + +- **Compromise of Sensitive Data**: Attackers can read and exfiltrate app-private files, such as databases, preferences, or cached tokens, resulting in unauthorized disclosure of user and app data. +- **Authentication or Authorization Bypass**: Attackers can steal session material stored in reachable files or WebView storage, resulting in account takeover. + +## Mitigations + +- **Disable File and Content Access**: Keep file, file-URL, and content access settings disabled unless strictly required, and never combine them with untrusted content. +- **Use a Safe Asset Loader**: Serve local app resources through a dedicated asset-loading mechanism with a fixed, validated scope instead of custom response handlers over arbitrary paths. +- **Scope File Read Access Narrowly**: When loading local files, grant read access only to the specific file or directory being displayed. +- **Separate Trusted and Untrusted Content**: Render untrusted content only in WebViews with no local resource access and no privileged configuration. diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0038.md b/weaknesses/MASVS-PLATFORM/MASWE-0038.md index 70352e3..621c49d 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0038.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0038.md @@ -14,22 +14,39 @@ mappings: maswe-beta: [MASWE-0071, MASWE-0070, MASWE-0072] refs: - https://blog.oversecured.com/Evernote-Universal-XSS-theft-of-all-cookies-from-all-sites-and-more/ -draft: - description: | - WebView objects shouldn't load URLs, HTML, or JavaScript from untrusted sources, and the app - shouldn't let users navigate to sites outside of the developer's control. Loading untrusted - content (e.g. a URL received via an intent or deep link, or JavaScript fetched from an - unverified source) can lead to cross-site scripting, including Universal XSS, allowing an - attacker to steal cookies/tokens from any site, perform phishing, or drive-by downloads. - Whenever possible, use an allowlist to restrict what the WebView loads (e.g. via - `WebViewClient.shouldOverrideUrlLoading`) and enable Safe Browsing. - topics: - - not restricting navigation to trusted origins - - loading URLs from untrusted sources (e.g. intents or deep links) - - loading JavaScript from untrusted/unverified sources - - Universal XSS (theft of cookies/tokens across sites) - - not enabling Safe Browsing -status: placeholder - +status: new --- +## Overview + +This weakness occurs when a WebView loads URLs, HTML, or JavaScript from untrusted sources, or lets users navigate to arbitrary sites outside the developer's control. + +WebViews often run with app-specific privileges, such as JavaScript bridges, cookies, and stored sessions, so loading untrusted content into them is far more dangerous than opening it in the system browser. A URL received via an intent or deep link, or JavaScript fetched from an unverified source, can lead to cross-site scripting, including Universal XSS, allowing an attacker to steal cookies and tokens from any site, perform phishing, or trigger drive-by downloads. + +## Modes of Introduction + +- **Unrestricted Navigation**: Not restricting which origins the WebView may load (e.g. via `WebViewClient.shouldOverrideUrlLoading` or navigation delegates), letting users or content navigate anywhere. +- **Untrusted URLs from External Input**: Loading URLs received through intents, deep links, or other external input without validating them against an allowlist. +- **Untrusted Script Inclusion**: Loading JavaScript from unverified sources into pages rendered by the WebView. +- **Safe Browsing Disabled**: Disabling platform protections such as Safe Browsing that warn about known-malicious sites. +- **Deprecated WebView Components**: Using deprecated WebView implementations that lack modern process isolation and security protections. + +## Impact + +Attackers can execute malicious web content inside the app's WebView by: + +- Delivering crafted deep links or intents from a malicious app or web page. +- Injecting malicious JavaScript into WebView content (e.g., via MITM on insecure connections or a compromised website). + +This can lead to: + +- **Compromise of Sensitive Data**: Attackers can steal cookies, tokens, or displayed data from any origin via cross-site scripting in the privileged WebView, resulting in unauthorized disclosure of session material and user data. +- **Authentication or Authorization Bypass**: Attackers can reuse stolen session cookies or tokens, resulting in account takeover across the sites the WebView had sessions with. +- **Loss of User Trust**: Attackers can render phishing pages or trigger unwanted downloads inside the app's own UI, resulting in users being deceived under the app's identity and reputational damage for the app owner. + +## Mitigations + +- **Allowlist Navigation**: Restrict the WebView to an allowlist of trusted origins and open everything else in the system browser. +- **Validate Externally Supplied URLs**: Treat URLs arriving via intents or deep links as untrusted input and validate them before loading (see @MASWE-0032). +- **Load Scripts Only from Trusted Sources**: Never inject or include JavaScript fetched from unverified sources. +- **Keep Platform Protections Enabled**: Leave Safe Browsing and equivalent protections enabled and use current, supported WebView components. diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0039.md b/weaknesses/MASVS-PLATFORM/MASWE-0039.md index d3709cb..c9b30d7 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0039.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0039.md @@ -8,28 +8,40 @@ profiles: [L2] mappings: masvs-v2: [MASVS-PLATFORM-3, MASVS-STORAGE-2] cwe: [200, 359] - refs: - https://developer.android.com/guide/topics/ui/accessibility/service - https://support.google.com/googleplay/android-developer/answer/10964491 - https://developer.apple.com/documentation/uikit/uiaccessibility -draft: - description: | - Accessibility services (e.g. Android `AccessibilityService`) can observe screen content, - read text of on-screen nodes, and receive UI events across apps. A malicious or overly - privileged accessibility service can therefore harvest sensitive data (passwords, OTPs, - messages, PII) that an app displays or that the user enters. Apps handling sensitive data - should minimize what is exposed to accessibility APIs, mark sensitive views appropriately - (e.g. excluding them from accessibility where suitable, avoiding placing secrets in - accessibility node text), and be aware that accessibility-based malware is a common - exfiltration and overlay-abuse vector. Similarly on iOS, sensitive values should not be - exposed through accessibility labels/values beyond what is necessary. - topics: - - Android AccessibilityService reading on-screen content and events - - sensitive data exposed via accessibility node text / labels - - accessibility-based malware and overlay abuse - - minimizing sensitive data exposed to accessibility APIs - - iOS accessibility labels/values leaking sensitive data -status: placeholder - +status: new --- + +## Overview + +This weakness occurs when an app exposes sensitive data to accessibility APIs beyond what is necessary, making it harvestable by malicious or overly privileged accessibility services. + +Accessibility services (e.g. Android's `AccessibilityService`) can observe screen content, read the text of on-screen nodes, and receive UI events across apps. This power is essential for assistive technology, but it also makes accessibility a common exfiltration and automation vector for malware: a malicious service that the user was tricked into enabling can harvest passwords, one-time codes, messages, and other personal data, and even drive the UI. Apps handling sensitive data should minimize what is exposed through accessibility metadata without degrading accessibility for legitimate users. + +## Modes of Introduction + +- **Secrets in Accessibility Metadata**: Exposing sensitive values through accessibility node text, labels, or hints beyond what assistive technology needs. +- **Sensitive Fields Not Using Secure Input**: Presenting secret input in fields that are not marked as password/secure entry, so their content is readable through accessibility APIs. +- **High-Risk Flows Fully Automatable**: Designing sensitive flows (e.g. payments) so that they can be completed entirely through programmatic UI interaction without any additional verification. + +## Impact + +Attackers can capture sensitive data displayed or entered in the app by: + +- Harvesting on-screen content through a malicious accessibility service the user was tricked into enabling. + +This can lead to: + +- **Compromise of Sensitive Data**: Attackers can read messages, personal data, and financial details from on-screen content, resulting in unauthorized disclosure of user data. +- **Authentication or Authorization Bypass**: Attackers can harvest credentials and one-time codes as they are displayed or entered, resulting in account takeover. +- **Financial Loss**: Attackers can combine harvested data with accessibility-driven UI automation to initiate fraudulent transactions, resulting in direct financial harm to the user. + +## Mitigations + +- **Keep Secrets Out of Accessibility Metadata**: Do not place sensitive values in accessibility labels, hints, or node text beyond what assistive technology requires. +- **Use Secure Input Fields**: Mark secret fields as password/secure entry so platforms mask their content from accessibility reading. +- **Add Friction to High-Risk Flows**: Require verification that UI automation cannot satisfy (e.g. biometric-bound confirmation, see @MASWE-0021) for the most sensitive actions. +- **Preserve Legitimate Accessibility**: Minimize only the sensitive values exposed; never degrade the app's overall accessibility for assistive-technology users. diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0069.md b/weaknesses/MASVS-PRIVACY/MASWE-0069.md index f8b975f..b2da55d 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0069.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0069.md @@ -34,7 +34,7 @@ This can lead to: - **Violation of User Privacy**: Users cannot exercise their rights to manage their personal data, such as deleting or exporting their information, resulting in the loss of control over their data and an increased amount of exposed data if a breach occurs. - **Loss of User Trust**: Users can perceive that they have no control over their personal data, resulting in negative reviews, decreased user engagement, and reduced retention for the app owner. -- **Legal and Regulatory Non-Compliance**: Failing to provide data management capabilities required by regulations like GDPR and CCPA can result in fines, legal action, and other consequences for the app owner. +- **Legal and Regulatory Non-Compliance**: Failing to provide data management capabilities can violate regulations like GDPR and CCPA, resulting in fines, legal action, and other consequences for the app owner. ## Mitigations diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0073.md b/weaknesses/MASVS-PRIVACY/MASWE-0073.md index f6a88c9..0048e54 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0073.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0073.md @@ -3,10 +3,9 @@ title: Inadequate Tracking Domains Declarations id: MASWE-0073 alias: tracking-domains-declarations requirement: "The app adequately declares all tracking domains it connects to." -platform: ["android", "ios"] -profiles: ["P"] +platform: [android, ios] +profiles: [P] mappings: - masvs-v1: [] masvs-v2: [MASVS-PRIVACY-3] cwe: [359] maswe-beta: [MASWE-0108] @@ -15,21 +14,37 @@ refs: - https://developer.apple.com/documentation/bundleresources/privacy_manifest_files - https://developer.apple.com/app-store/app-privacy-details/#user-tracking - https://developer.apple.com/documentation/apptrackingtransparency/ -draft: - description: | - Platforms increasingly require apps to declare the domains they use for tracking so the - system can enforce user tracking choices (e.g. Apple's privacy manifest lists tracking - domains, and connections to those domains are blocked when the user has not granted App - Tracking Transparency permission). This weakness occurs when an app fails to declare its - tracking domains, declares them incompletely, or declares domains inconsistently with the - app's actual network behavior. Inadequate or inaccurate tracking-domain declarations - prevent the platform from enforcing the user's tracking preferences and mislead users - about how their data is used, and can also lead to app-review rejections. - topics: - - declaring tracking domains in Apple's privacy manifest (NSPrivacyTrackingDomains) - - consistency between declared tracking domains and actual network connections - - interaction with App Tracking Transparency (ATT) enforcement - - incomplete or missing tracking-domain declarations for third-party SDKs -status: placeholder - +status: new --- + +## Overview + +This weakness occurs when an app fails to declare the domains it uses for tracking, declares them incompletely, or declares them inconsistently with its actual network behavior. + +Platforms increasingly require apps to declare their tracking domains so the system can enforce the user's tracking choices. For example, Apple's privacy manifest lists tracking domains (`NSPrivacyTrackingDomains`), and connections to those domains are blocked when the user has not granted App Tracking Transparency permission. Inadequate or inaccurate declarations prevent the platform from enforcing the user's tracking preferences, mislead users about how their data is used, and can lead to app-review rejections. + +## Modes of Introduction + +- **Missing or Incomplete Declarations**: Not declaring tracking domains at all, or declaring only a subset of the domains the app actually contacts for tracking purposes. +- **Undeclared Third-Party SDK Domains**: Omitting tracking domains contacted by embedded third-party SDKs, whose network behavior the developer may not have audited. +- **Declarations Inconsistent with Behavior**: Declaring domains that do not match the app's observed network connections, e.g. after adding new tracking endpoints without updating the manifest. + +## Impact + +Apps and embedded third-party components can track users against their expressed preferences by: + +- Contacting undeclared tracking domains that platform enforcement cannot block. +- Collecting and correlating identifiers and usage data across apps, devices, and services. + +This can lead to: + +- **Violation of User Privacy**: Tracking traffic can bypass the platform's enforcement of the user's tracking choice, resulting in users being tracked despite having refused permission. +- **Loss of User Trust**: Users and researchers can discover undeclared tracking connections, resulting in negative publicity and reduced trust in the app. +- **Legal and Regulatory Non-Compliance**: Inaccurate tracking declarations can violate platform policies and privacy regulations, resulting in app-review rejection, removal, or fines for the app owner. + +## Mitigations + +- **Declare All Tracking Domains**: Enumerate every domain used for tracking, including those contacted by third-party SDKs, in the platform's declaration mechanism (e.g. the privacy manifest's `NSPrivacyTrackingDomains`). +- **Audit Network Behavior**: Regularly capture and review the app's network traffic to verify that its actual connections match the declared tracking domains. +- **Track SDK Changes**: Re-review declarations when adding or updating SDKs, using the SDKs' own privacy manifests where provided. +- **Respect the User's Tracking Choice**: Gate all tracking activity on the user's platform-level tracking permission rather than relying on enforcement alone (see @MASWE-0066). diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0074.md b/weaknesses/MASVS-PRIVACY/MASWE-0074.md index bbcd796..130aa87 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0074.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0074.md @@ -8,41 +8,41 @@ profiles: [P] mappings: masvs-v2: [MASVS-PRIVACY-2] cwe: [359] - refs: - https://datatracker.ietf.org/doc/html/rfc8252#appendix-B - https://developer.apple.com/documentation/authenticationservices/aswebauthenticationsession - https://developer.android.com/training/data-storage/shared/photopicker - https://developer.apple.com/documentation/photokit/phpickerviewcontroller -draft: - description: | - Apps often have a choice between functionality that unnecessarily exposes user data and a - privacy-preserving alternative provided by the platform. Using the non-privacy-preserving - option when a privacy-friendly one exists leads to avoidable data exposure and over-collection. - - Examples include: - - - Using deprecated or non-isolated web-authentication flows such as `SFAuthenticationSession` - (deprecated) or embedding a general-purpose WebView for authentication, instead of - `ASWebAuthenticationSession` on iOS or Chrome Custom Tabs / Android Custom Tabs on Android - (see [RFC 8252, Appendix B](https://datatracker.ietf.org/doc/html/rfc8252#appendix-B)), - which keep credentials and browsing state isolated from the app. - - Requesting broad permissions unnecessarily instead of using a privacy-friendly API, e.g. - requesting full photo-library or camera access instead of using the system photo picker - (`PHPickerViewController` on iOS, the Android Photo Picker), which returns only the items - the user selects without any permission grant. - - Note: this can be seen as the privacy-focused counterpart to @MASWE-0047 (Using Non-Standard APIs for - Security-Critical Functionality), which applies the same "leverage platform-provided features - rather than custom or non-standard alternatives" principle from a security angle. The overlap is - intentional: some platform features (e.g. `ASWebAuthenticationSession` / Custom Tabs) improve - both privacy and security. Here the focus is specifically on choosing privacy-preserving - functionality. - topics: - - use of ASWebAuthenticationSession / Custom Tabs instead of embedded WebViews or SFAuthenticationSession - - RFC 8252 best practices for OAuth in native apps - - using the system photo picker instead of requesting full photo/camera permissions - - preferring privacy-friendly, least-exposing platform APIs -status: placeholder - +status: new --- + +## Overview + +This weakness occurs when an app uses functionality that unnecessarily exposes user data even though the platform provides a privacy-preserving alternative. + +Platforms increasingly offer least-exposing APIs for common tasks: system authentication sessions (`ASWebAuthenticationSession` on iOS, Custom Tabs on Android, per [RFC 8252, Appendix B](https://datatracker.ietf.org/doc/html/rfc8252#appendix-B)) keep credentials and browsing state isolated from the app, and system pickers (e.g. `PHPickerViewController` on iOS, the Android Photo Picker) return only the items the user selects without any broad permission grant. Choosing the non-privacy-preserving option leads to avoidable data exposure and over-collection. This is the privacy-focused counterpart to @MASWE-0047, which applies the same "prefer platform-provided functionality" principle from a security angle; some features, such as system authentication sessions, improve both. + +## Modes of Introduction + +- **Embedded Authentication Flows**: Handling third-party authentication in embedded WebViews or deprecated session APIs, exposing credentials and browsing state to the app, instead of isolated system authentication sessions. +- **Broad Permissions Instead of Pickers**: Requesting full photo-library, camera, or file access when a system picker would return only the user-selected items without any permission. +- **Over-Exposing API Choices**: Choosing APIs that reveal more user data than the feature requires when a least-exposing platform alternative exists (see also @MASWE-0072). + +## Impact + +Apps and embedded third-party components can access more user data than the feature requires by: + +- Handling credentials and browsing state inside the app instead of isolated system flows. +- Holding excessive or no-longer-needed permissions granted to the app. + +This can lead to: + +- **Violation of User Privacy**: The app and its embedded components can observe credentials, browsing state, or whole data collections (e.g. the entire photo library) that a privacy-preserving alternative would never have exposed, resulting in avoidable over-collection of personal data. +- **Compromise of Sensitive Data**: Data unnecessarily accessible to the app can be leaked through any other weakness or through embedded third parties, resulting in exposure of user data that the app never needed to hold. +- **Loss of User Trust**: Users can perceive unnecessary permission prompts and embedded login flows as invasive, resulting in refused permissions, abandoned logins, and reduced retention. + +## Mitigations + +- **Use System Authentication Sessions**: Authenticate against third-party services with `ASWebAuthenticationSession` on iOS or Custom Tabs on Android, following RFC 8252, instead of embedded WebViews or deprecated APIs. +- **Prefer System Pickers**: Use the system photo, file, and contact pickers so the app receives only what the user explicitly selects, without broad permission grants. +- **Choose Least-Exposing APIs**: When the platform offers a privacy-preserving variant of a capability, prefer it and request broad access only when the feature genuinely requires it (see @MASWE-0072). diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0049.md b/weaknesses/MASVS-RESILIENCE/MASWE-0049.md index 7bd8fc3..6de9350 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0049.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0049.md @@ -11,19 +11,35 @@ mappings: maswe-beta: [MASWE-0008] refs: - https://developer.apple.com/documentation/localauthentication/logging_a_user_into_your_app_with_face_id_or_touch_id -- https://grep.app/search?q=isdevicesecure%28&filter[repo][0]=threema-ch/threema-android +- https://developer.android.com/reference/android/app/KeyguardManager#isDeviceSecure() - https://developer.android.com/reference/android/hardware/biometrics/BiometricManager#canAuthenticate(int) -draft: - description: | - Apps that protect sensitive data or operations should verify that the device has a secure lock - (passcode/PIN/pattern/biometric) configured before relying on it. If the app does not check for a - secure device lock, it may allow access to sensitive data on devices with no lock at all. On iOS, - enforcing that a passcode is set has the added benefit that it is tightly coupled with data - protection (file encryption), provided the app uses the correct data-protection APIs. - topics: - - user set a device passcode via `isDeviceSecure()` on Android better than only ensuring that the secure screen lock is set via `KeyguardManager.isKeyguardSecure()` - - before attempting to authenticate, test to make sure that you actually have the ability to do so by calling the `LAContext.canEvaluatePolicy(_:error:)` method on iOS - - to make sure that biometrics can be used, verify that the `kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly` or the `kSecAttrAccessibleWhenPasscodeSet` protection class is set when the `SecAccessControlCreateWithFlags` method is called -status: placeholder - +status: new --- + +## Overview + +This weakness occurs when an app enables sensitive functionality without verifying that the device has a secure lock screen (passcode, PIN, pattern, or biometric) configured. + +Many of the platform's data-protection guarantees assume a device credential exists: on iOS, file encryption classes tied to the passcode only protect data if a passcode is set, and on Android, keystore protections such as unlocked-device requirements are meaningless on a device with no lock. If the app does not check for a secure device lock, it may expose sensitive data on devices where anyone who picks them up has full access. + +## Modes of Introduction + +- **No Secure-Lock Check**: Enabling sensitive features without verifying the device lock state, e.g. via `KeyguardManager.isDeviceSecure()` on Android or `LAContext.canEvaluatePolicy(_:error:)` on iOS. +- **Data Protection Not Tied to the Passcode**: Storing sensitive items on iOS without passcode-dependent protection classes (e.g. `kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly`), so the data remains available even when no passcode is set. + +## Impact + +Attackers can access sensitive data and functionality on unprotected devices by: + +- Accessing a lost or stolen device that has no secure lock screen configured. + +This can lead to: + +- **Compromise of Sensitive Data**: Attackers can open the app and read its data on a device with no lock, resulting in unauthorized disclosure of user data whose protection assumed a device credential. +- **Authentication or Authorization Bypass**: Attackers can act within the app's active sessions on an unprotected device, resulting in unauthorized use of the victim's accounts. + +## Mitigations + +- **Verify the Device Lock State**: Check that a secure lock screen is configured (e.g. `isDeviceSecure()` on Android, `canEvaluatePolicy` on iOS) before enabling sensitive functionality, and guide users to set one when missing. +- **Bind Data Protection to the Passcode**: On iOS, store sensitive Keychain items with passcode-dependent protection classes such as `kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly`, so data becomes unavailable if the passcode is removed. +- **Degrade Gracefully**: On devices without a secure lock, restrict the most sensitive features or require in-app authentication instead of silently operating unprotected. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0051.md b/weaknesses/MASVS-RESILIENCE/MASWE-0051.md index df45894..d8fbfec 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0051.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0051.md @@ -10,16 +10,37 @@ mappings: masvs-v2: [MASVS-RESILIENCE-3] cwe: [693] maswe-beta: [MASWE-0089, MASWE-0092] -draft: - description: The app's code doesn’t implement effective obfuscation techniques to protect against reverse engineering and static analysis (CWE-693), e.g. polymorphic obfuscation, method-inlining, insertion of opaque predicates, instruction substitution, and instruction block chopping. This also covers failing to hinder static analysis tools from decompiling the app ("static damage control"). - topics: - - polymorphic obfuscation - - method-inlining - - insertion of opaque predicates - - instruction substitution - - instruction block chopping - - preventing/hindering decompilation by static analysis tools -status: placeholder - +refs: +- https://developer.android.com/build/shrink-code +status: new --- +## Overview + +This weakness occurs when an app's code, particularly its security-relevant logic, ships without effective obfuscation, making reverse engineering and static analysis straightforward. + +Obfuscation does not prevent reverse engineering, but it raises its cost. Effective schemes go beyond default identifier renaming and include techniques such as control-flow transformations, opaque predicates, instruction substitution, instruction block chopping, and method inlining, as well as hindering decompilers from producing usable output. Without them, attackers can quickly understand and locate the app's defenses and proprietary logic. + +## Modes of Introduction + +- **No Obfuscation Applied**: Shipping release builds without any minification or obfuscation, leaving class, method, and symbol names intact. +- **Security-Relevant Logic Left Readable**: Applying only default renaming while leaving security checks, licensing logic, and proprietary algorithms trivially analyzable, without stronger techniques such as opaque predicates, instruction substitution, or control-flow transformations. +- **Effectiveness Never Assessed**: Never testing the obfuscation against current decompilers and deobfuscation tooling, so its actual strength is unknown. + +## Impact + +Attackers can analyze the app's logic and security controls with minimal effort by: + +- Obtaining the app package and reverse engineering it. + +This can lead to: + +- **Bypass of Protection Mechanisms**: Attackers can quickly locate and defeat client-side checks such as root detection, licensing, or anti-tampering logic, resulting in the circumvention of the app's defenses. +- **Compromise of Sensitive Data**: Attackers can recover proprietary algorithms and embedded secrets from readable code, resulting in intellectual property theft and easier planning of further attacks. + +## Mitigations + +- **Enable Obfuscation for Release Builds**: Apply the platform's minification and obfuscation tooling (e.g. R8) or established commercial obfuscators to all release builds. +- **Harden Security-Relevant Code**: Apply stronger transformations (opaque predicates, instruction substitution, control-flow obfuscation, method inlining) to the code implementing security checks and proprietary logic. +- **Assess Obfuscation Effectiveness**: Regularly attempt to reverse engineer the release build with state-of-the-art decompilers and deobfuscators to validate that the protection meets its goal. +- **Combine with Runtime Protections**: Pair obfuscation with runtime integrity and anti-instrumentation checks (see @MASWE-0053, @MASWE-0061, @MASWE-0064), since obfuscation alone only delays attackers. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0052.md b/weaknesses/MASVS-RESILIENCE/MASWE-0052.md index 5624661..a962ba9 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0052.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0052.md @@ -10,19 +10,36 @@ mappings: masvs-v2: [MASVS-RESILIENCE-3] cwe: [693] maswe-beta: [MASWE-0090] -draft: - description: | - Beyond code, an app's resources and assets (e.g. strings, layouts, images, configuration, and - native binaries) can reveal how the app works and aid reverse engineering. This weakness occurs - when resources are left in clear, unobfuscated form and binaries are neither encrypted nor packed. - Note that obfuscation or encryption applied without integrity validation can itself be tampered - with (CWE-649), so resource protection should complement, not replace, integrity checks. - topics: - - data/resources not obfuscated or encrypted - - native binaries not encrypted/packed - - obfuscation/encryption used without integrity validation (CWE-649) - - resource/string identifier obfuscation -status: placeholder - +status: new --- +## Overview + +This weakness occurs when an app's resources and assets are left in clear, unprotected form, revealing how the app works and aiding reverse engineering. + +Beyond code, strings, layouts, configuration files, bundled data, and native binaries all carry information about the app's inner workings. Attackers mining the package can use them to map features, find security-relevant configuration, and identify targets for tampering. Note that obfuscation or encryption applied without integrity validation can itself be tampered with, so resource protection should complement, not replace, integrity checks (see @MASWE-0063). + +## Modes of Introduction + +- **Resources Left in Clear**: Shipping strings, configuration, and other assets unobfuscated and unencrypted in the package. +- **Native Binaries Not Protected**: Shipping native libraries without encryption or packing, exposing their full structure to static analysis. +- **Identifiers Left Meaningful**: Keeping descriptive resource and string identifiers that map directly to features and security controls. +- **Protection Without Integrity Validation**: Obfuscating or encrypting resources without verifying their integrity, leaving the protected resources silently replaceable. + +## Impact + +Attackers can analyze the app's inner workings through its resources by: + +- Obtaining the app package and reverse engineering it. + +This can lead to: + +- **Bypass of Protection Mechanisms**: Attackers can locate security-relevant configuration and assets and use them to target the app's defenses, resulting in easier circumvention of its protections. +- **Compromise of Sensitive Data**: Attackers can extract proprietary content and internal information from clear resources, resulting in intellectual property exposure. + +## Mitigations + +- **Obfuscate or Encrypt Sensitive Resources**: Protect strings, configuration, and assets that reveal security-relevant behavior, decrypting them only when needed at runtime. +- **Pack or Encrypt Native Binaries**: Apply packing or encryption to native libraries containing sensitive logic. +- **Obfuscate Resource Identifiers**: Replace meaningful resource and string identifiers with non-descriptive ones in release builds. +- **Validate Resource Integrity**: Combine resource protection with integrity verification (see @MASWE-0063) so protected resources cannot simply be replaced. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0053.md b/weaknesses/MASVS-RESILIENCE/MASWE-0053.md index 4f459bb..7c06a69 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0053.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0053.md @@ -10,19 +10,36 @@ mappings: masvs-v2: [MASVS-RESILIENCE-3] cwe: [693] maswe-beta: [MASWE-0091] -draft: - description: | - Obfuscation alone can be undone by automated deobfuscation and static-analysis tooling. This - weakness occurs when the app does not implement anti-deobfuscation techniques that raise the cost - of reversing obfuscated code (CWE-693), such as anti-decompilation tricks, control-flow constructs - that defeat common deobfuscators, self-checks, and detection of tampering with the obfuscation. It - complements code obfuscation (@MASWE-0051) by protecting the obfuscation itself. - topics: - - anti-deobfuscation / anti-decompilation techniques - - control-flow constructs resistant to automated deobfuscators - - detecting tampering with obfuscated code - - Effectiveness Assessment (e.g. attempting deobfuscation) -status: placeholder - +status: new --- +## Overview + +This weakness occurs when an app relies on obfuscation that automated deobfuscation and static-analysis tooling can undo, because no techniques protect the obfuscation itself. + +Obfuscation alone is a moving target: publicly available deobfuscators, decompilers, and scripted analyses can strip common transformations automatically. Anti-deobfuscation techniques, such as anti-decompilation constructs, control-flow shapes that defeat common deobfuscators, and self-checks that detect tampering with obfuscated code, raise the cost of reversing the obfuscation. This weakness complements @MASWE-0051 by protecting the obfuscation itself. + +## Modes of Introduction + +- **Obfuscation Without Hardening**: Applying standard obfuscation whose transformations are automatically reversible by publicly available tooling. +- **Deobfuscator-Friendly Control Flow**: Using control-flow patterns that common deobfuscators normalize without difficulty. +- **No Tamper Detection for Obfuscated Code**: Not detecting when obfuscated code has been modified, unpacked, or re-written by analysis tooling. +- **Effectiveness Never Assessed**: Never attempting deobfuscation with current tooling to measure how long the protection actually holds. + +## Impact + +Attackers can undo the app's obfuscation with automated tooling by: + +- Obtaining the app package and reverse engineering it. + +This can lead to: + +- **Bypass of Protection Mechanisms**: Attackers can recover near-original code and then locate and defeat the app's client-side defenses, resulting in the circumvention of protections the obfuscation was meant to shield. +- **Compromise of Sensitive Data**: Attackers can recover proprietary algorithms and embedded secrets despite the obfuscation, resulting in intellectual property exposure. + +## Mitigations + +- **Use Anti-Decompilation Constructs**: Include constructs that break or degrade the output of common decompilers and disassemblers. +- **Resist Automated Deobfuscation**: Choose control-flow and data transformations that current automated deobfuscators cannot normalize cheaply. +- **Detect Tampering with Obfuscated Code**: Add self-checks that detect modification or unpacking of obfuscated code and trigger a response (see @MASWE-0064). +- **Assess Against Current Tooling**: Regularly run state-of-the-art deobfuscation tooling against release builds and strengthen the scheme when it falls. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0054.md b/weaknesses/MASVS-RESILIENCE/MASWE-0054.md index a174e4f..42b7307 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0054.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0054.md @@ -12,30 +12,37 @@ mappings: android-risks: - https://developer.android.com/privacy-and-security/risks/test-debug maswe-beta: [MASWE-0094, MASWE-0093, MASWE-0095] -draft: - description: | - The app contains developer debug artifacts that should not be present in production builds. - These include verbose logging and code flows, enabled testing utilities (e.g. StrictMode), - debugging symbols, and, most critically, leftover debug/test code or backdoors, such as - hidden switches or an insecure trust manager, that can disable security controls (e.g. TLS - certificate validation). Such artifacts help adversaries understand the app's behavior and - potentially exploit it (CWE-497), may include sensitive information (CWE-540) or - implementation details (CWE-1295), and may allow bypassing security controls (CWE-489, - CWE-912). - - Note the distinction from @MASWE-0006: that weakness (in - STORAGE) covers developer _leftover artifacts_ that leak confidentiality, such as staging / - integration URLs, developer emails/usernames, and source code files hardcoded in the package. - This weakness (in RESILIENCE) covers developer _debug artifacts_ that weaken the app's - resilience, such as verbose logging, backdoors (e.g. an insecure trust manager behind a - hidden switch/config), debugging symbols, code flows, and testing utilities. - topics: - - verbose logging and code flows left in production - - enabled testing utilities (e.g. StrictMode) - - debugging symbols not stripped - - backdoors / hidden settings that disable security controls (e.g. TLS verification) - - leftover debug/test code -status: placeholder - +status: new --- +## Overview + +This weakness occurs when an app ships to production containing developer debug artifacts, such as verbose logging, testing utilities, debugging symbols, or leftover debug and test code. + +Such artifacts help adversaries understand the app's behavior and internals, may include sensitive implementation details, and, most critically, may include backdoors, such as hidden switches or an insecure trust manager, that can disable security controls like TLS certificate validation. Note the distinction from @MASWE-0006: that weakness covers developer leftover artifacts that leak confidentiality (staging URLs, developer identities, source files), while this one covers debug artifacts that weaken the app's resilience. + +## Modes of Introduction + +- **Verbose Logging and Debug Flows**: Leaving verbose or debug-level logging and diagnostic code paths active in production builds. +- **Testing Utilities Enabled**: Shipping with development-time utilities enabled, such as StrictMode on Android. +- **Debugging Symbols Not Stripped**: Releasing binaries with debugging symbols that map the code for reverse engineers. +- **Backdoors and Hidden Switches**: Leaving debug or test code that can disable security controls, e.g. an insecure trust manager or a hidden configuration flag that turns off TLS verification. + +## Impact + +Attackers can analyze the app's internals and disable its security controls by: + +- Obtaining the app package and reverse engineering it. +- Accessing the system logs on a compromised device or from an app holding log-access permissions. + +This can lead to: + +- **Bypass of Protection Mechanisms**: Attackers can activate leftover debug switches or code paths that disable security controls such as certificate validation, resulting in the defeat of protections the production app is supposed to enforce. +- **Compromise of Sensitive Data**: Attackers can use verbose logs, symbols, and debug flows to learn implementation details and extract sensitive values, resulting in information disclosure that enables further attacks. + +## Mitigations + +- **Strip Symbols and Debug Code**: Remove debugging symbols and compile debug-only code paths out of release builds using build variants and flags. +- **Disable Verbose Logging in Production**: Ensure debug and verbose logging is removed or disabled in release configurations. +- **Remove Testing Utilities**: Keep development-time utilities such as StrictMode out of production builds. +- **Eliminate Backdoors**: Enforce code review and release checks that reject hidden switches, test hooks, or alternative code paths capable of weakening security controls in production. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0055.md b/weaknesses/MASVS-RESILIENCE/MASWE-0055.md index 4be183d..dcacd54 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0055.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0055.md @@ -10,19 +10,33 @@ mappings: masvs-v2: [MASVS-RESILIENCE-3, MASVS-NETWORK-1] cwe: [319] maswe-beta: [MASWE-0096] -draft: - description: | - The app does not apply an additional layer of application-level (payload / end-to-end) - encryption on top of the transport encryption. Even when the connection is encrypted (e.g. - HTTPS), an attacker who can perform a MITM attack (for example by bypassing certificate - pinning on a device they control) would be able to observe or tamper with the plaintext - payloads, revealing the inner workings of the app and its operations. Application-level - payload encryption raises the effort required to analyze and manipulate the app's traffic. - This is a resilience measure and is not necessarily related to privacy. - topics: - - application-level / end-to-end payload encryption on top of TLS - - protecting the confidentiality of app traffic against MITM on attacker-controlled devices -status: placeholder - +status: new --- +## Overview + +This weakness occurs when an app relies solely on transport-layer encryption for its network traffic, without an additional layer of application-level payload encryption. + +Even when the connection uses HTTPS, an attacker who controls the device can bypass transport protections (for example by defeating certificate pinning with instrumentation) and observe or tamper with the plaintext payloads, revealing the inner workings of the app and its API. Application-level payload encryption raises the effort required to analyze and manipulate the app's traffic. This is a resilience measure aimed at hindering analysis and abuse; it complements rather than replaces transport security (see @MASWE-0025, @MASWE-0027). + +## Modes of Introduction + +- **TLS-Only Protection**: Sending security-relevant API payloads with no protection beyond the transport channel, so they appear in plaintext as soon as TLS is intercepted on a controlled device. +- **No Integrity Binding on Requests**: Not signing or otherwise binding sensitive requests, so intercepted payloads can be modified and replayed once the transport layer is bypassed. + +## Impact + +Attackers can inspect and manipulate the app's API payloads by: + +- Inspecting or modifying app traffic on a device they control after bypassing transport protections (e.g., pinning). + +This can lead to: + +- **Compromise of System Integrity and Business Operations**: Attackers can map the app's API and craft or tamper with requests, resulting in fraud, scraping, and abuse of backend services at the app owner's expense. +- **Bypass of Protection Mechanisms**: Attackers can modify payloads that carry security-relevant state, resulting in the circumvention of client-reported controls and business logic. + +## Mitigations + +- **Encrypt Sensitive Payloads at the Application Layer**: Apply an additional layer of encryption to security-relevant payloads before they enter the transport channel, using keys managed via the platform keystore. +- **Sign Security-Relevant Requests**: Authenticate and integrity-protect sensitive requests (e.g. with signatures bound to attested, hardware-backed keys) so tampered payloads are rejected server-side. +- **Treat It as Defense in Depth**: Keep full transport security (TLS and pinning) in place; application-level encryption raises analysis effort but is still client-side and ultimately bypassable. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0056.md b/weaknesses/MASVS-RESILIENCE/MASWE-0056.md index 06fc01d..6ce0dad 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0056.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0056.md @@ -10,14 +10,37 @@ mappings: masvs-v2: [MASVS-RESILIENCE-1, MASVS-RESILIENCE-4] cwe: [693] maswe-beta: [MASWE-0097, MASWE-0103] -draft: - description: no root/jailbreak detection implemented e.g. check for Cydia, SuperSU, - Magisk, Xposed, etc. The app does not implement effective techniques to detect if the device is rooted or jailbroken (CWE-693). More broadly, the app should apply Runtime Application Self-Protection (RASP) techniques that detect a compromised environment and trigger appropriate responses. - topics: - - detection in place - - RASP techniques with detection triggering different responses - - Effectiveness Assessment (e.g. bypassing the detection) -status: placeholder - +status: new --- +## Overview + +This weakness occurs when an app does not implement effective techniques to detect whether the device it runs on is rooted or jailbroken. + +On a rooted or jailbroken device, the platform's sandboxing and permission guarantees no longer hold: privileged users and tools (e.g. Magisk, SuperSU, Xposed, or jailbreak toolchains and their managers) can access the app's private data, instrument its process, and defeat its client-side controls. More broadly, the app should apply Runtime Application Self-Protection (RASP) techniques that detect a compromised environment and trigger appropriate responses. + +## Modes of Introduction + +- **No Detection Implemented**: Shipping without any checks for rooting or jailbreak artifacts, such as management apps, su binaries, hooking frameworks, modified system properties, or writable system partitions. +- **Naive or Single-Point Checks**: Implementing one easily located check whose removal or hooking disables the entire defense. +- **No Response Strategy**: Detecting a compromised environment but not responding to it in a way appropriate to the app's risk profile. + +## Impact + +Attackers can run and manipulate the app in a privileged environment without resistance by: + +- Running the app on a rooted or jailbroken device they control. +- Using dynamic instrumentation. +- Accessing the device storage on a compromised device. + +This can lead to: + +- **Bypass of Protection Mechanisms**: Attackers can use elevated privileges to defeat the app's client-side security controls, resulting in the circumvention of protections such as anti-tampering, licensing, or fraud controls. +- **Compromise of Sensitive Data**: Attackers can read the app's private data and intercept its runtime state without sandbox restrictions, resulting in exposure of user data, keys, and tokens. + +## Mitigations + +- **Implement Layered Detection**: Combine multiple, varied checks (file-system artifacts, system properties, management apps, behavioral probes) implemented in different layers (e.g. native code) so no single patch disables them all. +- **Respond Appropriately**: Define graded responses to detection, from warning the user to restricting sensitive functionality or terminating, matched to the app's risk profile. +- **Combine with Attestation**: Back local checks with server-verified device attestation (see @MASWE-0059) so the backend can act on integrity signals even if local checks are bypassed. +- **Assess Effectiveness**: Regularly test the detection against publicly available bypass tools and update it as evasion techniques evolve. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0057.md b/weaknesses/MASVS-RESILIENCE/MASWE-0057.md index ab0e917..8356217 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0057.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0057.md @@ -9,20 +9,36 @@ mappings: masvs-v2: [MASVS-RESILIENCE-1] cwe: [693] maswe-beta: [MASWE-0098] -draft: - description: | - App virtualization/cloning frameworks (and "dual-app" containers) run an app inside another app's - process, letting an attacker instrument it, access its data, or run multiple cloned instances - without rooting the device. This weakness occurs when the app does not detect that it is running - inside such a virtualized or cloned environment (CWE-693), for example by checking its process path - and package structure for anomalies or looking for known virtualization frameworks, and does not - respond when one is detected. - topics: - - detection of cloned apps / virtualized (dual-app) environments - - checks for known virtualization frameworks and process/path anomalies - - responding to a detected virtualized environment - - Effectiveness Assessment (e.g. bypassing the detection) -status: placeholder - +status: new --- +## Overview + +This weakness occurs when an app does not detect that it is running inside an app-virtualization or cloning environment. + +App virtualization and "dual-app" container frameworks run an app inside another app's process, letting the hosting app intercept its calls, access its data, and instrument it, all without rooting the device. They also enable running multiple cloned instances of the same app. An app that does not check for anomalies in its process path and package structure, or for known virtualization frameworks, cannot respond to running in such a hostile host. + +## Modes of Introduction + +- **No Virtualization Checks**: Not verifying the app's process path, package structure, or runtime environment for signs of running inside another app's process. +- **Known Frameworks Not Detected**: Not checking for artifacts of known virtualization and cloning frameworks. +- **No Response Strategy**: Detecting a virtualized environment but continuing to operate normally with sensitive functionality enabled. + +## Impact + +Attackers can observe and manipulate the app from a hosting process by: + +- Running the app inside an app-virtualization or cloning framework. + +This can lead to: + +- **Compromise of Sensitive Data**: Attackers can intercept the virtualized app's files, credentials, and API calls from the hosting app, resulting in exposure of user data without requiring root access. +- **Bypass of Protection Mechanisms**: Attackers can instrument the app inside the container to defeat its client-side controls, resulting in the circumvention of its defenses on unrooted devices. +- **Compromise of System Integrity and Business Operations**: Attackers can run multiple cloned instances to abuse promotions or multi-account limits, resulting in fraud against the app owner. + +## Mitigations + +- **Detect Environment Anomalies**: Verify the app's process path, data directory, and package structure at runtime and treat mismatches as indicators of virtualization. +- **Check for Known Frameworks**: Detect artifacts of known virtualization and cloning frameworks and their hosting packages. +- **Respond to Detection**: Restrict sensitive functionality, notify the backend, or terminate when a virtualized environment is detected, according to the app's risk profile. +- **Assess Effectiveness**: Test the detection against current virtualization frameworks and update it as they evolve. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0058.md b/weaknesses/MASVS-RESILIENCE/MASWE-0058.md index 30eea86..e7d8774 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0058.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0058.md @@ -10,13 +10,36 @@ mappings: masvs-v2: [MASVS-RESILIENCE-1, MASVS-RESILIENCE-4] cwe: [693] maswe-beta: [MASWE-0099, MASWE-0103] -draft: - description: The app's code doesn’t implement effective techniques to detect if it is running in an emulator (CWE-693), e.g. identifying features and limitations available for commonly used emulation solutions. More broadly, the app should apply Runtime Application Self-Protection (RASP) techniques that detect a compromised environment and trigger appropriate responses. - topics: - - detection in place - - RASP techniques with detection triggering different responses - - Effectiveness Assessment (e.g. bypassing the detection) -status: placeholder - +status: new --- +## Overview + +This weakness occurs when an app does not implement effective techniques to detect that it is running in an emulator or virtual device. + +Emulators give attackers a fully controlled, snapshottable environment for analyzing the app, automating interactions, and running it at scale in bot farms. Detection typically relies on identifying the features and limitations of commonly used emulation solutions, such as characteristic device identifiers, hardware properties, sensors, and timing behavior. More broadly, the app should apply Runtime Application Self-Protection (RASP) techniques that detect a compromised environment and trigger appropriate responses. + +## Modes of Introduction + +- **No Emulator Checks**: Shipping without any verification of device properties, hardware features, or sensor behavior that distinguish emulators from real devices. +- **Trivially Spoofable Checks**: Relying on a single property (e.g. a device model string) that emulators can trivially fake. +- **No Response Strategy**: Detecting an emulated environment but not adapting the app's behavior in response. + +## Impact + +Attackers can analyze and automate the app in a fully controlled environment by: + +- Running the app in an emulator or virtual device. +- Using dynamic instrumentation. + +This can lead to: + +- **Bypass of Protection Mechanisms**: Attackers can iterate on bypasses of the app's defenses with snapshots and full inspection, resulting in faster and cheaper circumvention of its protections. +- **Compromise of System Integrity and Business Operations**: Attackers can run automated fleets of emulated instances, resulting in bot-driven fraud, fake accounts, and abuse of the app owner's services. + +## Mitigations + +- **Detect Emulator Characteristics**: Check device identifiers, hardware capabilities, sensor availability, and behavioral traits that differ between emulators and physical devices, combining multiple signals. +- **Respond to Detection**: Restrict sensitive functionality, require additional verification, or terminate when an emulated environment is detected, according to the app's risk profile. +- **Combine with Attestation**: Use server-verified device attestation (see @MASWE-0059) so emulated environments are also flagged independently of local checks. +- **Assess Effectiveness**: Test the detection against popular emulators and hardening/evasion tools and refine it over time. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0059.md b/weaknesses/MASVS-RESILIENCE/MASWE-0059.md index 653f680..a187513 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0059.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0059.md @@ -15,26 +15,43 @@ refs: - https://support.google.com/googleplay/android-developer/answer/11395166?hl=en - https://www.youtube.com/watch?v=TyxL78e5Bag - https://github.com/1nikolas/play-integrity-checker-app -- https://developer.apple.com/videos/play/wwdc2021/10244/ -- https://developer.apple.com/documentation/devicecheck/preparing-to-use-the-app-attest-service -- https://github.com/iansampson/AppAttest -- https://github.com/firebase/firebase-ios-sdk/blob/v8.15.0/FirebaseAppCheck/Sources/AppAttestProvider/DCAppAttestService%2BFIRAppAttestService.h +- https://developer.apple.com/videos/play/wwdc2021/10244/ +- https://developer.apple.com/documentation/devicecheck/preparing-to-use-the-app-attest-service +- https://github.com/iansampson/AppAttest +- https://github.com/firebase/firebase-ios-sdk/blob/v8.15.0/FirebaseAppCheck/Sources/AppAttestProvider/DCAppAttestService%2BFIRAppAttestService.h - https://blog.restlesslabs.com/john/ios-app-attest -draft: - description: | - Device attestation lets the backend gain assurance about the integrity of the device and platform - the app runs on, using platform services such as the Android Play Integrity API or iOS - DeviceCheck / App Attest. This weakness occurs when the app does not implement device attestation, - so the backend cannot distinguish requests from genuine, uncompromised devices from those coming - from rooted, emulated, tampered, or automated environments (CWE-693), exposing it to tampering, - fraud, replay attacks, and abuse of premium features. Attestation results must be verified - server-side (including nonce/freshness) to be meaningful. - topics: - - Android Play Integrity API / iOS DeviceCheck & App Attest - - server-side verification of attestation results (nonce, freshness) - - detecting rooted/emulated/tampered environments via attestation - - Effectiveness Assessment (e.g. bypassing the detection) -status: placeholder - +status: new --- +## Overview + +This weakness occurs when an app does not implement device attestation, so its backend cannot distinguish requests from genuine, uncompromised devices from those coming from rooted, emulated, tampered, or automated environments. + +Device attestation uses platform services, such as the Android Play Integrity API or iOS DeviceCheck and App Attest, to give the backend cryptographic assurance about the integrity of the device and platform the app runs on. Without it, the backend must trust whatever the client claims. Attestation results must be verified server-side, including nonce-based freshness, to be meaningful; a verdict checked only on the client is just another bypassable local check. + +## Modes of Introduction + +- **No Attestation Integrated**: Not using the platform's attestation services at all, leaving the backend with no device-integrity signal. +- **Client-Side-Only Verification**: Requesting attestation but evaluating the verdict in the app instead of verifying it server-side. +- **Missing Freshness Guarantees**: Verifying attestation without a server-issued nonce or timeliness check, allowing verdicts to be replayed. +- **Verdicts Not Enforced**: Collecting attestation results but not gating sensitive operations on them. + +## Impact + +Attackers can interact with the backend from untrusted environments by: + +- Impersonating the app with scripts, bots, or tampered clients when interacting with the backend. +- Running the app on a rooted or jailbroken device they control. +- Running the app in an emulator or virtual device. + +This can lead to: + +- **Compromise of System Integrity and Business Operations**: Attackers can drive the backend with automated or tampered clients, resulting in fraud, scraping, fake accounts, and abuse of the app owner's services. +- **Financial Loss**: Attackers can abuse promotions, premium features, or transaction flows from unattested environments, resulting in direct monetary loss to the app owner. + +## Mitigations + +- **Integrate Platform Attestation**: Use the Android Play Integrity API and iOS DeviceCheck / App Attest to obtain device- and app-integrity verdicts. +- **Verify Server-Side with Freshness**: Have the backend verify attestation tokens cryptographically, bind them to a server-issued nonce, and check timeliness before trusting them. +- **Gate Sensitive Operations on Verdicts**: Require valid attestation for high-risk API calls and degrade or deny service to unattested clients. +- **Layer with Local Checks**: Combine attestation with local environment checks (see @MASWE-0056, @MASWE-0058) for defense in depth, and assess the overall scheme against known bypasses. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0060.md b/weaknesses/MASVS-RESILIENCE/MASWE-0060.md index 94686eb..2ef2972 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0060.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0060.md @@ -10,18 +10,35 @@ mappings: masvs-v2: [MASVS-RESILIENCE-4] cwe: [693] maswe-beta: [MASWE-0101] -draft: - description: | - A debugger attached to the running app lets an attacker inspect memory, set breakpoints, and alter - control flow to bypass client-side controls. This weakness occurs when the app does not detect the - presence of a debugger at runtime (CWE-693), for example via platform checks - (`Debug.isDebuggerConnected()` and the `TracerPid` in `/proc/self/status` on Android, or - `sysctl`/`ptrace`-based checks on iOS), and does not respond appropriately when one is detected. - topics: - - debugger presence detection (Android Debug.isDebuggerConnected() / TracerPid; iOS sysctl/ptrace) - - responding to a detected debugger - - Effectiveness Assessment (e.g. bypassing the detection) -status: placeholder - +status: new --- +## Overview + +This weakness occurs when an app does not detect the presence of a debugger attached to it at runtime. + +A debugger lets an attacker inspect memory, set breakpoints, and alter control flow to bypass client-side controls, even when the release build is not flagged as debuggable (see @MASWE-0050 for that case). Platforms offer detection primitives such as `Debug.isDebuggerConnected()` and the `TracerPid` field in `/proc/self/status` on Android, or `sysctl`- and `ptrace`-based checks on iOS. Without such checks and a response, a debugger can be attached and used against the app unnoticed. + +## Modes of Introduction + +- **No Debugger Checks**: Shipping without any runtime verification that a debugger is attached to the process. +- **One-Time or Single-Point Checks**: Checking only at startup or in a single location, so attackers can attach later or patch out the one check. +- **No Response Strategy**: Detecting a debugger but not reacting in a way that protects the app's sensitive operations. + +## Impact + +Attackers can inspect and manipulate the running app without resistance by: + +- Debugging the app at runtime. + +This can lead to: + +- **Bypass of Protection Mechanisms**: Attackers can alter control flow at breakpoints to skip the app's client-side checks, resulting in the circumvention of its defenses. +- **Compromise of Sensitive Data**: Attackers can read secrets and user data from process memory during debugging, resulting in exposure of credentials, keys, and tokens. + +## Mitigations + +- **Implement Debugger Detection**: Use platform primitives (e.g. `Debug.isDebuggerConnected()`, `TracerPid`, `sysctl`/`ptrace`-based checks) implemented in multiple layers, including native code. +- **Check Continuously**: Run detection periodically and around sensitive operations, not only at startup, so late attachment is also caught. +- **Respond to Detection**: Terminate, wipe sensitive state, or restrict functionality when a debugger is detected, according to the app's risk profile. +- **Assess Effectiveness**: Test the checks against common anti-anti-debugging techniques and refine them over time. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0061.md b/weaknesses/MASVS-RESILIENCE/MASWE-0061.md index a008a56..24f2e30 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0061.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0061.md @@ -10,20 +10,35 @@ mappings: masvs-v2: [MASVS-RESILIENCE-4] cwe: [693] maswe-beta: [MASWE-0102] -draft: - description: | - Dynamic instrumentation and hooking frameworks let an attacker observe and modify the app at - runtime, bypassing client-side security controls. This weakness occurs when the app does not detect - the presence of such tools (CWE-693), e.g. Frida, Xposed/LSPosed, and ElleKit/Cydia Substrate, by - checking for their artifacts (loaded libraries, named pipes, listening ports, installed hooks), and - does not respond when they are detected. - topics: - - Frida detection - - Xposed / LSPosed detection - - ElleKit / Cydia Substrate detection - - detecting hooking artifacts (loaded libraries, ports, named pipes) - - Effectiveness Assessment (e.g. bypassing the detection) -status: placeholder - +status: new --- +## Overview + +This weakness occurs when an app does not detect the presence of dynamic instrumentation and hooking frameworks at runtime. + +Tools such as Frida, Xposed/LSPosed, and ElleKit/Cydia Substrate let attackers observe and modify the app while it runs, replacing method implementations and defeating client-side security controls. These frameworks leave detectable artifacts, such as loaded libraries, named pipes, listening ports, and installed hooks, that the app can check for. Without detection and a response, instrumentation proceeds unnoticed. + +## Modes of Introduction + +- **No Instrumentation Checks**: Shipping without any detection of well-known instrumentation and hooking frameworks. +- **Artifact Checks Missing or Shallow**: Not checking for hooking artifacts such as suspicious loaded libraries, named pipes, listening ports, or modified function prologues, or checking only from easily hooked Java/Swift code. +- **No Response Strategy**: Detecting instrumentation but continuing to expose sensitive functionality. + +## Impact + +Attackers can observe and modify the running app without resistance by: + +- Using dynamic instrumentation. + +This can lead to: + +- **Bypass of Protection Mechanisms**: Attackers can hook and replace the app's security checks at runtime, resulting in the circumvention of its client-side defenses, including root, debugger, and integrity checks. +- **Compromise of Sensitive Data**: Attackers can intercept function arguments and memory contents during instrumentation, resulting in exposure of credentials, keys, and user data. + +## Mitigations + +- **Detect Instrumentation Artifacts**: Check for known frameworks and their artifacts (loaded libraries, named pipes, listening ports, hooked functions), implementing the checks in native code where they are harder to bypass. +- **Check Continuously and Diversify**: Run varied checks at multiple points in the app lifecycle so a single hook cannot disable them all. +- **Respond to Detection**: Terminate, restrict sensitive functionality, or signal the backend when instrumentation is detected. +- **Assess Effectiveness**: Regularly test the detection against current instrumentation tools and their evasion modules, and update it as they evolve. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0062.md b/weaknesses/MASVS-RESILIENCE/MASWE-0062.md index 18be328..f1e0a41 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0062.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0062.md @@ -13,28 +13,37 @@ mappings: refs: - https://developer.apple.com/documentation/xcode/using-the-latest-code-signature-format - https://developer.apple.com/documentation/devicecheck/preparing-to-use-the-app-attest-service -draft: - description: | - The app does not attest its own authenticity/integrity, i.e. it doesn't implement effective - techniques to verify that the running binary is a genuine, unmodified copy of the app - (CWE-347). This includes verifying the app signature and binaries at runtime (e.g. detecting - an invalid app signing certificate, or an outdated signing scheme such as Android V1-only or - an iOS CodeDirectory version below 20400). - - This weakness previously focused on "Official Store Verification". Rather than only checking - whether the app was downloaded from an official store (e.g. by verifying the package name), - the emphasis is now on verifying the app's own signature / app attestation, which is a - stronger guarantee and also covers apps distributed through alternative stores. Checking the - app's signature or package name against the expected values remains one of the techniques. - topics: - - app signature / binaries checked at runtime - - native libraries verifying app integrity (e.g. AppAttest) - - invalid app signing certificate detection - - latest signing scheme not used (Android V1-only, iOS CodeDirectory < 20400) - - verifying the app's signature / package name (incl. official-store assurance) - - Effectiveness Assessment (e.g. bypassing the detection) - note: consider Static Code Modification? / Repackaging Detection Not Implemented -status: placeholder - +status: new --- +## Overview + +This weakness occurs when an app does not attest its own authenticity and integrity, i.e. it implements no effective techniques to verify that the running binary is a genuine, unmodified copy of the app. + +App attestation includes verifying the app's signature and binaries at runtime, detecting an invalid or unexpected signing certificate, and using platform attestation services that vouch for the app's identity (e.g. App Attest on iOS, Play Integrity app verdicts on Android). It also covers using current signing schemes: outdated formats, such as Android V1-only signatures or an iOS CodeDirectory version below 20400, weaken the platform's own integrity guarantees. Verifying the package or signature against expected values, which also provides official-store assurance, remains one of the applicable techniques. + +## Modes of Introduction + +- **No Runtime Integrity Verification**: Not verifying the app's signature, package identity, or binaries at runtime, so a repackaged copy runs unnoticed. +- **No Platform App Attestation**: Not using platform services that attest the app's identity to the backend, so servers cannot distinguish genuine clients from modified ones. +- **Outdated Signing Schemes**: Signing releases with outdated formats (e.g. Android V1-only signatures, iOS CodeDirectory below version 20400) that are easier to abuse. + +## Impact + +Attackers can distribute and run modified copies of the app by: + +- Patching or repackaging the app to remove or alter client-side checks. +- Installing a repackaged version of the app on victim devices. + +This can lead to: + +- **Bypass of Protection Mechanisms**: Attackers can strip security controls from a repackaged copy that still works against the backend, resulting in the circumvention of the app's defenses at scale. +- **Compromise of Sensitive Data**: Attackers can distribute trojanized versions of the app that harvest credentials and data from the users they deceive, resulting in account compromise attributed to the app. +- **Compromise of System Integrity and Business Operations**: Modified clients, cracked features, and clone apps circulate under the app's brand, resulting in revenue loss and reputational damage for the app owner. + +## Mitigations + +- **Verify App Integrity at Runtime**: Check the app's signing certificate, package identity, and binaries at runtime against expected values, implementing checks in layers that are harder to patch out (e.g. native code). +- **Use Platform App Attestation**: Integrate services such as iOS App Attest or Play Integrity app verdicts and verify their results server-side, so the backend rejects modified or repackaged clients. +- **Use Current Signing Schemes**: Sign releases with up-to-date signature formats and rotate away from deprecated ones. +- **Respond to Failed Checks**: Terminate, restrict functionality, or flag the session to the backend when integrity verification fails, and assess the checks against known bypass techniques. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0063.md b/weaknesses/MASVS-RESILIENCE/MASWE-0063.md index 2a938e8..ef14c2e 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0063.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0063.md @@ -10,19 +10,37 @@ mappings: masvs-v2: [MASVS-RESILIENCE-2, MASVS-CODE-4] cwe: [693] maswe-beta: [MASWE-0105] -draft: - description: | - Beyond executable code, an app relies on resources and assets whose integrity should be verified, - including files in the app sandbox, downloaded resources, and dynamically loaded resources (e.g. - those restored from a backup). This weakness occurs when the app does not verify that these - resources have not been tampered with (CWE-693), allowing an attacker to change app behavior or - inject malicious content by altering resources. - topics: - - sandbox / app-resource integrity verification - - integrity of downloaded resources - - integrity of dynamically loaded resources (e.g. via backup restore) - - responding to failed resource-integrity checks -status: placeholder - +status: new --- +## Overview + +This weakness occurs when an app does not verify that the resources it relies on have not been tampered with. + +Beyond executable code, apps depend on resources whose integrity matters: files in the app sandbox, configuration, downloaded content, and dynamically loaded resources, including data restored from backups. An attacker who can alter these resources can change the app's behavior or inject malicious content without touching its code, sidestepping code-focused integrity checks (see @MASWE-0062, @MASWE-0064). + +## Modes of Introduction + +- **Sandbox Files Not Verified**: Trusting files in the app's data directory without integrity checks, although they can be modified on compromised devices or through backup manipulation. +- **Downloaded Resources Not Verified**: Using downloaded content or configuration without verifying its integrity and authenticity. +- **Restored Data Trusted Implicitly**: Loading data restored from backups or transfers as if the app had written it moments ago. +- **No Response to Tampering**: Having no defined behavior for when a resource fails validation. + +## Impact + +Attackers can alter the app's behavior through its resources by: + +- Modifying the app's files or resources on a compromised device. +- Tampering with backup contents and restoring the modified backup to a device. + +This can lead to: + +- **Bypass of Protection Mechanisms**: Attackers can modify configuration or state files that drive security-relevant behavior, resulting in the circumvention of controls without modifying any code. +- **Execution of Unauthorized Code**: Attackers can inject malicious content into resources the app renders or interprets (e.g. scripts or templates), resulting in attacker-controlled behavior inside the app. + +## Mitigations + +- **Verify Resource Integrity**: Validate hashes or signatures of security-relevant files in the sandbox before trusting them, keeping reference values out of the attacker's reach (e.g. signed or server-held). +- **Authenticate Downloaded Content**: Verify integrity and authenticity (e.g. a signature, see @MASWE-0015) of downloaded resources before use. +- **Treat Restored Data as Untrusted**: Re-validate data that reappears via backup restore or device transfer before acting on it (see @MASWE-0048). +- **Respond to Failed Checks**: Discard or re-fetch tampered resources, restrict functionality, or alert the backend when validation fails. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0064.md b/weaknesses/MASVS-RESILIENCE/MASWE-0064.md index 4f738b0..0a3cc6b 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0064.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0064.md @@ -10,18 +10,37 @@ mappings: masvs-v2: [MASVS-RESILIENCE-2] cwe: [693] maswe-beta: [MASWE-0107] -draft: - description: | - An app's executable code can be modified at runtime through in-memory patching, code injection, or - hooking. This weakness occurs when the app does not verify the integrity of its own code at runtime - (CWE-693), for example by detecting modifications to loaded code/segments, injected libraries, or - patched functions, and does not respond when tampering is detected. It complements static app - integrity/attestation (@MASWE-0062) by covering runtime tampering. - topics: - - in-memory code / patch tampering detection - - detecting injected libraries and function hooks - - runtime code/segment integrity checks - - Effectiveness Assessment (e.g. bypassing the detection) -status: placeholder - +status: new --- + +## Overview + +This weakness occurs when an app does not verify the integrity of its own code at runtime, allowing in-memory patching, code injection, and hooking to go undetected. + +Even a correctly signed app can be modified while it runs: attackers can patch instructions in memory, inject libraries into the process, or hook functions to change their behavior. Runtime code integrity verification, such as checking loaded code segments, detecting injected libraries, and spotting patched function prologues, complements static app attestation (see @MASWE-0062) by covering tampering that happens after the app has launched. + +## Modes of Introduction + +- **No Runtime Code Checks**: Not verifying the integrity of loaded code segments or executable memory at runtime. +- **Injected Libraries Not Detected**: Not inspecting the process for libraries that are not part of the app or platform. +- **Hooked Functions Not Detected**: Not checking security-critical functions for patched prologues or redirected implementations. +- **No Response to Tampering**: Detecting modifications but not reacting to protect sensitive operations. + +## Impact + +Attackers can modify the app's code while it runs by: + +- Using dynamic instrumentation. +- Debugging the app at runtime. + +This can lead to: + +- **Bypass of Protection Mechanisms**: Attackers can patch or hook the functions implementing the app's security checks, resulting in the circumvention of its client-side defenses. +- **Compromise of Sensitive Data**: Attackers can redirect or wrap data-handling functions to siphon their inputs and outputs, resulting in exposure of credentials and user data processed by the app. + +## Mitigations + +- **Verify Code Segments at Runtime**: Periodically validate the integrity of the app's loaded code and executable memory, especially around sensitive operations. +- **Detect Injection and Hooking**: Check for foreign libraries in the process and for patched prologues or redirected implementations of security-critical functions. +- **Layer and Protect the Checks**: Implement checks in native code, diversify them, and protect them with obfuscation (see @MASWE-0051) so they cannot all be disabled with one patch. +- **Respond to Detection**: Terminate, restrict functionality, or signal the backend when runtime tampering is detected, and assess the checks against current hooking frameworks. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0076.md b/weaknesses/MASVS-RESILIENCE/MASWE-0076.md index c087e11..d4efa6b 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0076.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0076.md @@ -8,26 +8,39 @@ profiles: [R] mappings: masvs-v2: [MASVS-RESILIENCE-2] cwe: [693] - refs: - https://developers.google.com/android/play-protect - https://support.google.com/googleplay/android-developer/answer/13375539 -draft: - description: | - The app does not implement or integrate techniques to detect the presence of malware on the - device or malicious apps/components that could target it (e.g. apps abusing accessibility - services, overlay-capable apps, known malicious packages, or a compromised runtime - environment). For high-assurance apps, detecting a potentially hostile environment allows - the app to warn the user, restrict functionality, or trigger other protective responses. - This complements environment-integrity checks such as - @MASWE-0056 (root/jailbreak detection) and platform services such as Google - Play Protect / the Play Integrity API. - topics: - - detecting known malicious apps/packages on the device - - detecting apps abusing accessibility services or screen overlays - - integrating platform malware/threat signals (e.g. Play Protect / Play Integrity) - - responses to a detected hostile environment (warn, restrict, block) - - Effectiveness Assessment (e.g. bypassing the detection) -status: placeholder - +status: new --- + +## Overview + +This weakness occurs when an app does not implement or integrate techniques to detect malware on the device or malicious apps and components that could target it. + +Mobile malware commonly attacks other apps indirectly: abusing accessibility services to read screens and drive the UI, drawing overlays to phish credentials, or exploiting a compromised runtime environment. For high-assurance apps, detecting a potentially hostile environment, e.g. known malicious packages, apps holding accessibility or overlay capabilities, or platform threat signals such as Google Play Protect status, allows the app to warn the user, restrict functionality, or trigger other protective responses. This complements environment-integrity checks such as @MASWE-0056 and platform services such as the Play Integrity API. + +## Modes of Introduction + +- **No Hostile-Environment Checks**: Not checking for known malicious packages or platform threat signals before enabling sensitive functionality. +- **Abuse-Prone Capabilities Ignored**: Not considering apps holding accessibility or overlay capabilities in the app's risk decisions for sensitive flows (see @MASWE-0031, @MASWE-0039). +- **No Response Strategy**: Detecting a hostile environment but not warning the user or restricting sensitive functionality. + +## Impact + +Attackers can target the app with malware running on the same device by: + +- Harvesting on-screen content through a malicious accessibility service the user was tricked into enabling. +- Displaying overlays or tampering with the UI to alter what the user sees while approving an action. + +This can lead to: + +- **Compromise of Sensitive Data**: Malware can capture credentials, one-time codes, and displayed content while the app takes no protective action, resulting in exposure of user data the app could have defended. +- **Financial Loss**: Malware can automate or manipulate transactions against the unprotected app, resulting in direct financial harm to users and fraud losses for the app owner. + +## Mitigations + +- **Integrate Platform Threat Signals**: Use available platform services (e.g. Play Protect status, Play Integrity verdicts) to learn about known malware and a compromised environment. +- **Assess Risky Capabilities**: Factor the presence of accessibility- or overlay-capable apps into risk decisions for sensitive flows, combined with the UI-level defenses of @MASWE-0031 and @MASWE-0039. +- **Respond Proportionately**: Warn the user, require additional verification, restrict functionality, or block sensitive operations when a hostile environment is detected. +- **Assess Effectiveness**: Validate the detection against current malware behaviors and update it as the threat landscape evolves. From 5181cd59298f57a0a56fa0b17f11af880b6c31c3 Mon Sep 17 00:00:00 2001 From: Carlos Holguera Date: Mon, 20 Jul 2026 01:19:41 +0200 Subject: [PATCH 10/70] 25 MASWEs now carry android-core-app-quality mappings using the current named IDs from the Core App Quality checklist, and the two legacy-style mappings were migrated --- .github/instructions/maswe.instructions.md | 2 +- weaknesses/MASVS-AUTH/MASWE-0017.md | 1 + weaknesses/MASVS-AUTH/MASWE-0020.md | 1 + weaknesses/MASVS-AUTH/MASWE-0021.md | 1 + weaknesses/MASVS-AUTH/MASWE-0022.md | 1 + weaknesses/MASVS-AUTH/MASWE-0024.md | 1 + weaknesses/MASVS-CODE/MASWE-0041.md | 2 +- weaknesses/MASVS-CODE/MASWE-0043.md | 1 + weaknesses/MASVS-CODE/MASWE-0044.md | 1 + weaknesses/MASVS-CODE/MASWE-0047.md | 1 + weaknesses/MASVS-CRYPTO/MASWE-0007.md | 1 + weaknesses/MASVS-CRYPTO/MASWE-0011.md | 1 + weaknesses/MASVS-CRYPTO/MASWE-0012.md | 1 + weaknesses/MASVS-CRYPTO/MASWE-0016.md | 1 + weaknesses/MASVS-NETWORK/MASWE-0025.md | 2 +- weaknesses/MASVS-NETWORK/MASWE-0026.md | 1 + weaknesses/MASVS-NETWORK/MASWE-0027.md | 1 + weaknesses/MASVS-PLATFORM/MASWE-0035.md | 1 + weaknesses/MASVS-PLATFORM/MASWE-0036.md | 1 + weaknesses/MASVS-PLATFORM/MASWE-0037.md | 1 + weaknesses/MASVS-PRIVACY/MASWE-0066.md | 1 + weaknesses/MASVS-PRIVACY/MASWE-0072.md | 1 + weaknesses/MASVS-PRIVACY/MASWE-0074.md | 1 + weaknesses/MASVS-RESILIENCE/MASWE-0054.md | 1 + weaknesses/MASVS-STORAGE/MASWE-0001.md | 1 + weaknesses/MASVS-STORAGE/MASWE-0004.md | 1 + 26 files changed, 26 insertions(+), 3 deletions(-) diff --git a/.github/instructions/maswe.instructions.md b/.github/instructions/maswe.instructions.md index b6a2830..5ca8fa4 100644 --- a/.github/instructions/maswe.instructions.md +++ b/.github/instructions/maswe.instructions.md @@ -79,7 +79,7 @@ Field rules: - **maswe-beta**: One or more MASWE v0.x (pre-1.0.0-rc) weaknesses that this weakness supersedes or absorbs. This is optional but encouraged for traceability. - **cwe**: One or more CWE IDs that correspond to this weakness. This helps link to the broader software security ecosystem. - **android-risks**: One or more specific risks from the Android developer documentation (https://developer.android.com/privacy-and-security/risks) that correspond to this weakness. This is an optional field that can help link to Android-specific guidance, but it should only be used when there is a clear match - - **android-core-app-quality**: One or more security checklist IDs from the [Android Core App Quality guidelines](https://developer.android.com/docs/quality-guidelines/core-app-quality). Optional. + - **android-core-app-quality**: One or more checklist item IDs from the [Android Core App Quality guidelines](https://developer.android.com/docs/quality-guidelines/core-app-quality), using the current named IDs (e.g. `Network_Security_Traffic`, `Minimize_Permissions`), not the legacy `SC-*`/`PS-*` numbering. Optional; only use when there is a clear match, and only for weaknesses whose `platform` includes `android`. - **nist-ssdf**: One or more practice IDs from the [NIST Secure Software Development Framework (SP 800-218)](https://csrc.nist.gov/projects/ssdf). Optional. - **observed_examples**: Links to public, real-world occurrences of the weakness (e.g. CVE entries or published research). Optional. - **refs**: External references. Prefer stable, vendor-neutral sources (official platform docs, CWE, NIST, academic papers). diff --git a/weaknesses/MASVS-AUTH/MASWE-0017.md b/weaknesses/MASVS-AUTH/MASWE-0017.md index 6e879c8..70674ce 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0017.md +++ b/weaknesses/MASVS-AUTH/MASWE-0017.md @@ -9,6 +9,7 @@ mappings: masvs-v1: [MSTG-AUTH-10] masvs-v2: [MASVS-AUTH-3, MASVS-PLATFORM-3] cwe: [306] + android-core-app-quality: [Biometric_Authentication] maswe-beta: [MASWE-0029] refs: - https://developer.apple.com/documentation/localauthentication diff --git a/weaknesses/MASVS-AUTH/MASWE-0020.md b/weaknesses/MASVS-AUTH/MASWE-0020.md index e9eeb47..a47f407 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0020.md +++ b/weaknesses/MASVS-AUTH/MASWE-0020.md @@ -15,6 +15,7 @@ mappings: - https://developer.android.com/privacy-and-security/risks/access-control-to-exported-components - https://developer.android.com/privacy-and-security/risks/android-exported - https://developer.android.com/privacy-and-security/risks/custom-permissions + android-core-app-quality: [Component_Export, Component_Permissions, Component_Protection] maswe-beta: [MASWE-0033, MASWE-0038, MASWE-0040, MASWE-0051, MASWE-0059, MASWE-0062, MASWE-0063, MASWE-0064, MASWE-0065, MASWE-0119] refs: - https://developer.android.com/privacy-and-security/security-tips#IPNetworking diff --git a/weaknesses/MASVS-AUTH/MASWE-0021.md b/weaknesses/MASVS-AUTH/MASWE-0021.md index 9d273f4..397c5bb 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0021.md +++ b/weaknesses/MASVS-AUTH/MASWE-0021.md @@ -9,6 +9,7 @@ mappings: masvs-v1: [MSTG-AUTH-8, MSTG-AUTH-1, MSTG-AUTH-12] masvs-v2: [MASVS-AUTH-2, MASVS-CRYPTO-2] cwe: [285, 287, 312, 319, 326, 602, 603, 863, 922] + android-core-app-quality: [Biometric_Authentication] maswe-beta: [MASWE-0034, MASWE-0044, MASWE-0041, MASWE-0042, MASWE-0043] refs: - https://developer.android.com/training/sign-in/biometric-auth#crypto diff --git a/weaknesses/MASVS-AUTH/MASWE-0022.md b/weaknesses/MASVS-AUTH/MASWE-0022.md index b5eac9d..af8f7b5 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0022.md +++ b/weaknesses/MASVS-AUTH/MASWE-0022.md @@ -8,6 +8,7 @@ profiles: [L2] mappings: masvs-v2: [MASVS-AUTH-2] cwe: [288, 287] + android-core-app-quality: [Biometric_Authentication] maswe-beta: [MASWE-0045] refs: - https://developer.android.com/training/sign-in/biometric-auth#allow-fallback diff --git a/weaknesses/MASVS-AUTH/MASWE-0024.md b/weaknesses/MASVS-AUTH/MASWE-0024.md index 4aefb71..abc1848 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0024.md +++ b/weaknesses/MASVS-AUTH/MASWE-0024.md @@ -9,6 +9,7 @@ mappings: masvs-v1: [MSTG-AUTH-9] masvs-v2: [MASVS-AUTH-1, MASVS-AUTH-3] cwe: [287, 522] + android-core-app-quality: [Autofill_Hints, Credential_Manager] maswe-beta: [MASWE-0028, MASWE-0032, MASWE-0035, MASWE-0039] refs: - https://developer.apple.com/documentation/security/password_autofill diff --git a/weaknesses/MASVS-CODE/MASWE-0041.md b/weaknesses/MASVS-CODE/MASWE-0041.md index 27831b3..b69e95e 100644 --- a/weaknesses/MASVS-CODE/MASWE-0041.md +++ b/weaknesses/MASVS-CODE/MASWE-0041.md @@ -12,7 +12,7 @@ mappings: android-risks: - https://developer.android.com/privacy-and-security/risks/insecure-library - https://developer.android.com/privacy-and-security/risks/unsafe-download-manager - android-core-app-quality: [SC-N3, PS-T4] + android-core-app-quality: [SDK_Maintenance, Security_Provider_Initialization] nist-ssdf: [PS.3.2] maswe-beta: [MASWE-0076] refs: diff --git a/weaknesses/MASVS-CODE/MASWE-0043.md b/weaknesses/MASVS-CODE/MASWE-0043.md index a742591..c77538c 100644 --- a/weaknesses/MASVS-CODE/MASWE-0043.md +++ b/weaknesses/MASVS-CODE/MASWE-0043.md @@ -8,6 +8,7 @@ profiles: [L2] mappings: masvs-v2: [MASVS-CODE-1] cwe: [693, 1357] + android-core-app-quality: [Target_SDK_Version, Compile_SDK_Version] maswe-beta: [MASWE-0078] refs: - https://developer.android.com/google/play/requirements/target-sdk diff --git a/weaknesses/MASVS-CODE/MASWE-0044.md b/weaknesses/MASVS-CODE/MASWE-0044.md index 4dc2964..59de252 100644 --- a/weaknesses/MASVS-CODE/MASWE-0044.md +++ b/weaknesses/MASVS-CODE/MASWE-0044.md @@ -11,6 +11,7 @@ mappings: android-risks: - https://developer.android.com/privacy-and-security/risks/dynamic-code-loading - https://developer.android.com/privacy-and-security/risks/create-package-context + android-core-app-quality: [App_Bundles] maswe-beta: [MASWE-0085] refs: - https://developer.android.com/privacy-and-security/risks/dynamic-code-loading diff --git a/weaknesses/MASVS-CODE/MASWE-0047.md b/weaknesses/MASVS-CODE/MASWE-0047.md index 326d471..c0bfbd8 100644 --- a/weaknesses/MASVS-CODE/MASWE-0047.md +++ b/weaknesses/MASVS-CODE/MASWE-0047.md @@ -11,6 +11,7 @@ mappings: cwe: [287, 326, 327, 1240] android-risks: - https://developer.android.com/privacy-and-security/risks/bad-dns + android-core-app-quality: [Cryptographic_Algorithms] maswe-beta: [MASWE-0019, MASWE-0032, MASWE-0049] refs: - https://developer.android.com/privacy-and-security/security-tips#Credentials diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0007.md b/weaknesses/MASVS-CRYPTO/MASWE-0007.md index 8186140..dd0583b 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0007.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0007.md @@ -11,6 +11,7 @@ mappings: cwe: [331, 337, 338, 522] android-risks: - https://developer.android.com/privacy-and-security/risks/weak-prng + android-core-app-quality: [Cryptographic_Algorithms] maswe-beta: [MASWE-0009, MASWE-0017] refs: - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0011.md b/weaknesses/MASVS-CRYPTO/MASWE-0011.md index d9b6867..34d8dda 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0011.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0011.md @@ -11,6 +11,7 @@ mappings: cwe: [208, 323, 325, 326, 327, 329, 780] android-risks: - https://developer.android.com/privacy-and-security/risks/broken-cryptographic-algorithm + android-core-app-quality: [Cryptographic_Algorithms] maswe-beta: [MASWE-0020, MASWE-0012, MASWE-0022, MASWE-0023] refs: - https://support.google.com/faqs/answer/10046138?hl=en diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0012.md b/weaknesses/MASVS-CRYPTO/MASWE-0012.md index 696d47d..935671a 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0012.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0012.md @@ -9,6 +9,7 @@ mappings: masvs-v1: [MSTG-CRYPTO-4] masvs-v2: [MASVS-CRYPTO-1] cwe: [328] + android-core-app-quality: [Cryptographic_Algorithms] maswe-beta: [MASWE-0021] refs: - https://developer.android.com/privacy-and-security/cryptography#deprecated-functionality diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0016.md b/weaknesses/MASVS-CRYPTO/MASWE-0016.md index 525e261..3ff0725 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0016.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0016.md @@ -11,6 +11,7 @@ mappings: cwe: [332, 337, 338] android-risks: - https://developer.android.com/privacy-and-security/risks/weak-prng + android-core-app-quality: [Cryptographic_Algorithms] maswe-beta: [MASWE-0027] observed_examples: - https://nvd.nist.gov/vuln/detail/CVE-2013-6386 diff --git a/weaknesses/MASVS-NETWORK/MASWE-0025.md b/weaknesses/MASVS-NETWORK/MASWE-0025.md index c1500d1..1eb4d1a 100644 --- a/weaknesses/MASVS-NETWORK/MASWE-0025.md +++ b/weaknesses/MASVS-NETWORK/MASWE-0025.md @@ -12,7 +12,7 @@ mappings: android-risks: - https://developer.android.com/privacy-and-security/risks/cleartext-communications - https://developer.android.com/privacy-and-security/risks/insecure-machine-to-machine - android-core-app-quality: [SC-9, SC-N1, SC-N2] + android-core-app-quality: [Network_Security_Traffic, Network_Security_Configuration] maswe-beta: [MASWE-0050, MASWE-0037, MASWE-0048] refs: - https://developer.apple.com/documentation/security/preventing-insecure-network-connections diff --git a/weaknesses/MASVS-NETWORK/MASWE-0026.md b/weaknesses/MASVS-NETWORK/MASWE-0026.md index 7bf6902..4065959 100644 --- a/weaknesses/MASVS-NETWORK/MASWE-0026.md +++ b/weaknesses/MASVS-NETWORK/MASWE-0026.md @@ -12,6 +12,7 @@ mappings: android-risks: - https://developer.android.com/privacy-and-security/risks/unsafe-trustmanager - https://developer.android.com/privacy-and-security/risks/unsafe-hostname + android-core-app-quality: [Network_Security_Configuration, Security_Provider_Initialization] maswe-beta: [MASWE-0052] refs: - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf#page=17 diff --git a/weaknesses/MASVS-NETWORK/MASWE-0027.md b/weaknesses/MASVS-NETWORK/MASWE-0027.md index 8502c9d..724f9b5 100644 --- a/weaknesses/MASVS-NETWORK/MASWE-0027.md +++ b/weaknesses/MASVS-NETWORK/MASWE-0027.md @@ -9,6 +9,7 @@ mappings: masvs-v1: [MSTG-NETWORK-4] masvs-v2: [MASVS-NETWORK-2] cwe: [295] + android-core-app-quality: [Network_Security_Configuration] maswe-beta: [MASWE-0047] refs: - https://developer.android.com/privacy-and-security/security-config#CertificatePinning diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0035.md b/weaknesses/MASVS-PLATFORM/MASWE-0035.md index af21f1a..3a811a5 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0035.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0035.md @@ -14,6 +14,7 @@ mappings: - https://developer.android.com/privacy-and-security/risks/pending-intent - https://developer.android.com/privacy-and-security/risks/sender-of-pending-intents - https://developer.android.com/privacy-and-security/risks/sticky-broadcast + android-core-app-quality: [Component_Permissions] maswe-beta: [MASWE-0066] refs: - https://support.google.com/faqs/answer/9267555?hl=en diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0036.md b/weaknesses/MASVS-PLATFORM/MASWE-0036.md index 30163d9..76c3877 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0036.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0036.md @@ -11,6 +11,7 @@ mappings: cwe: [749, 94] android-risks: - https://developer.android.com/privacy-and-security/risks/insecure-webview-native-bridges + android-core-app-quality: [WebView_JavaScript] maswe-beta: [MASWE-0068] refs: - https://support.google.com/faqs/answer/9095419 diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0037.md b/weaknesses/MASVS-PLATFORM/MASWE-0037.md index 31b1c9e..3fcbd3b 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0037.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0037.md @@ -11,6 +11,7 @@ mappings: cwe: [22, 79, 200, 669] android-risks: - https://developer.android.com/privacy-and-security/risks/webview-unsafe-file-inclusion + android-core-app-quality: [WebView_Asset_Loader] maswe-beta: [MASWE-0069, MASWE-0073] refs: - https://blog.oversecured.com/Android-Exploring-vulnerabilities-in-WebResourceResponse/ diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0066.md b/weaknesses/MASVS-PRIVACY/MASWE-0066.md index 4e85168..5117ed6 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0066.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0066.md @@ -8,6 +8,7 @@ profiles: [P] mappings: masvs-v2: [MASVS-PRIVACY-2] cwe: [359] + android-core-app-quality: [Hardware_IDs] maswe-beta: [MASWE-0110] refs: - https://developer.android.com/reference/android/provider/Settings.Secure#ANDROID_ID diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0072.md b/weaknesses/MASVS-PRIVACY/MASWE-0072.md index dd48336..cfff8fc 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0072.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0072.md @@ -8,6 +8,7 @@ profiles: [P] mappings: masvs-v2: [MASVS-PRIVACY-1] cwe: [250] + android-core-app-quality: [Minimize_Permissions, Sensitive_Permissions, Runtime_Permissions, Permission_Rationale, Graceful_Degradation] maswe-beta: [MASWE-0117] refs: - https://developer.apple.com/design/human-interface-guidelines/privacy#Requesting-permission diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0074.md b/weaknesses/MASVS-PRIVACY/MASWE-0074.md index 130aa87..3f545bf 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0074.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0074.md @@ -8,6 +8,7 @@ profiles: [P] mappings: masvs-v2: [MASVS-PRIVACY-2] cwe: [359] + android-core-app-quality: [Minimize_Permissions] refs: - https://datatracker.ietf.org/doc/html/rfc8252#appendix-B - https://developer.apple.com/documentation/authenticationservices/aswebauthenticationsession diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0054.md b/weaknesses/MASVS-RESILIENCE/MASWE-0054.md index 42b7307..4318917 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0054.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0054.md @@ -11,6 +11,7 @@ mappings: cwe: [489, 497, 540, 912, 1295] android-risks: - https://developer.android.com/privacy-and-security/risks/test-debug + android-core-app-quality: [Production_Build_Quality] maswe-beta: [MASWE-0094, MASWE-0093, MASWE-0095] status: new --- diff --git a/weaknesses/MASVS-STORAGE/MASWE-0001.md b/weaknesses/MASVS-STORAGE/MASWE-0001.md index 2e888e5..fe0405c 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0001.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0001.md @@ -11,6 +11,7 @@ mappings: cwe: [209, 359, 497, 532] android-risks: - https://developer.android.com/privacy-and-security/risks/log-info-disclosure + android-core-app-quality: [Sensitive_Data_Logging] maswe-beta: [MASWE-0001] refs: - https://developer.android.com/privacy-and-security/risks/log-info-disclosure diff --git a/weaknesses/MASVS-STORAGE/MASWE-0004.md b/weaknesses/MASVS-STORAGE/MASWE-0004.md index 5488b42..d10f73d 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0004.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0004.md @@ -12,6 +12,7 @@ mappings: cwe: [200, 284, 312, 313, 732, 921, 922] android-risks: - https://developer.android.com/privacy-and-security/risks/sensitive-data-external-storage + android-core-app-quality: [Sensitive_Data_Storage] maswe-beta: [MASWE-0007, MASWE-0002] refs: - https://developer.android.com/training/data-storage From c0f15577d56e42d75c220a91e2f1ea52dcb9202e Mon Sep 17 00:00:00 2001 From: Carlos Holguera Date: Mon, 20 Jul 2026 11:04:25 +0200 Subject: [PATCH 11/70] remove unused mappings --- .github/instructions/maswe.instructions.md | 3 --- weaknesses/MASVS-CODE/MASWE-0041.md | 1 - weaknesses/MASVS-CODE/MASWE-0045.md | 2 -- weaknesses/MASVS-CRYPTO/MASWE-0016.md | 5 ----- weaknesses/MASVS-STORAGE/MASWE-0003.md | 1 - weaknesses/MASVS-STORAGE/MASWE-0004.md | 1 - 6 files changed, 13 deletions(-) diff --git a/.github/instructions/maswe.instructions.md b/.github/instructions/maswe.instructions.md index 5ca8fa4..ee6a83d 100644 --- a/.github/instructions/maswe.instructions.md +++ b/.github/instructions/maswe.instructions.md @@ -75,13 +75,10 @@ Field rules: - **mappings**: Cross-references to related controls and weaknesses in other standards. At least one MASVS v2 control is required. Mappings to MASVS v1, CWE, and Android risks are optional but encouraged when applicable. - **masvs-v1**: One or more MSTG v1 controls that covered this topic. This helps identify content to port from MASTG v1. - **masvs-v2**: One or more MASVS v2 controls this weakness helps verify. At least one entry is required. - - **mastg-v1**: One or more MASTG v1 tests that covered this topic. Optional; helps identify content to port from MASTG v1. - **maswe-beta**: One or more MASWE v0.x (pre-1.0.0-rc) weaknesses that this weakness supersedes or absorbs. This is optional but encouraged for traceability. - **cwe**: One or more CWE IDs that correspond to this weakness. This helps link to the broader software security ecosystem. - **android-risks**: One or more specific risks from the Android developer documentation (https://developer.android.com/privacy-and-security/risks) that correspond to this weakness. This is an optional field that can help link to Android-specific guidance, but it should only be used when there is a clear match - **android-core-app-quality**: One or more checklist item IDs from the [Android Core App Quality guidelines](https://developer.android.com/docs/quality-guidelines/core-app-quality), using the current named IDs (e.g. `Network_Security_Traffic`, `Minimize_Permissions`), not the legacy `SC-*`/`PS-*` numbering. Optional; only use when there is a clear match, and only for weaknesses whose `platform` includes `android`. - - **nist-ssdf**: One or more practice IDs from the [NIST Secure Software Development Framework (SP 800-218)](https://csrc.nist.gov/projects/ssdf). Optional. -- **observed_examples**: Links to public, real-world occurrences of the weakness (e.g. CVE entries or published research). Optional. - **refs**: External references. Prefer stable, vendor-neutral sources (official platform docs, CWE, NIST, academic papers). - **status**: When you generate a new MASWE draft, set `status: new`. diff --git a/weaknesses/MASVS-CODE/MASWE-0041.md b/weaknesses/MASVS-CODE/MASWE-0041.md index b69e95e..607c255 100644 --- a/weaknesses/MASVS-CODE/MASWE-0041.md +++ b/weaknesses/MASVS-CODE/MASWE-0041.md @@ -13,7 +13,6 @@ mappings: - https://developer.android.com/privacy-and-security/risks/insecure-library - https://developer.android.com/privacy-and-security/risks/unsafe-download-manager android-core-app-quality: [SDK_Maintenance, Security_Provider_Initialization] - nist-ssdf: [PS.3.2] maswe-beta: [MASWE-0076] refs: - https://developer.android.com/privacy-and-security/risks/insecure-library diff --git a/weaknesses/MASVS-CODE/MASWE-0045.md b/weaknesses/MASVS-CODE/MASWE-0045.md index 14fc093..07c5431 100644 --- a/weaknesses/MASVS-CODE/MASWE-0045.md +++ b/weaknesses/MASVS-CODE/MASWE-0045.md @@ -11,8 +11,6 @@ mappings: android-risks: - https://developer.android.com/privacy-and-security/risks/use-of-native-code maswe-beta: [MASWE-0116] -observed_examples: -- https://nvd.nist.gov/vuln/detail/CVE-2019-3568 refs: - https://partners.trellix.com/enterprise/en-us/assets/white-papers/wp-secure-coding-android-applications.pdf - https://sensepost.com/blog/2021/on-ios-binary-protections/ diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0016.md b/weaknesses/MASVS-CRYPTO/MASWE-0016.md index 3ff0725..6f799ff 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0016.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0016.md @@ -13,11 +13,6 @@ mappings: - https://developer.android.com/privacy-and-security/risks/weak-prng android-core-app-quality: [Cryptographic_Algorithms] maswe-beta: [MASWE-0027] -observed_examples: -- https://nvd.nist.gov/vuln/detail/CVE-2013-6386 -- https://nvd.nist.gov/vuln/detail/CVE-2006-3419 -- https://nvd.nist.gov/vuln/detail/CVE-2008-4102 -- https://www.zellic.io/blog/proton-dart-flutter-csprng-prng/ refs: - https://www.ietf.org/rfc/rfc1750.txt - https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html#secure-random-number-generation diff --git a/weaknesses/MASVS-STORAGE/MASWE-0003.md b/weaknesses/MASVS-STORAGE/MASWE-0003.md index 56dc5bb..94332e2 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0003.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0003.md @@ -8,7 +8,6 @@ profiles: [L2] mappings: masvs-v1: [MSTG-STORAGE-2] masvs-v2: [MASVS-STORAGE-1, MASVS-STORAGE-2, MASVS-CRYPTO-2, MASVS-PRIVACY-1] - mastg-v1: [MASTG-TEST-0052, MASTG-TEST-0001] cwe: [200, 284, 312, 313, 732, 922] android-risks: - https://developer.android.com/privacy-and-security/risks/file-providers diff --git a/weaknesses/MASVS-STORAGE/MASWE-0004.md b/weaknesses/MASVS-STORAGE/MASWE-0004.md index d10f73d..1e24ca4 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0004.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0004.md @@ -8,7 +8,6 @@ profiles: [L1, L2] mappings: masvs-v1: [MSTG-STORAGE-2] masvs-v2: [MASVS-STORAGE-1, MASVS-STORAGE-2] - mastg-v1: [MASTG-TEST-0052, MASTG-TEST-0001] cwe: [200, 284, 312, 313, 732, 921, 922] android-risks: - https://developer.android.com/privacy-and-security/risks/sensitive-data-external-storage From b45f2730779a5e86a743f3c64388d5044f43c29d Mon Sep 17 00:00:00 2001 From: Carlos Holguera Date: Mon, 20 Jul 2026 11:44:08 +0200 Subject: [PATCH 12/70] Refactor android-risk references to use simplified identifiers across multiple weakness documents --- .github/instructions/maswe.instructions.md | 8 ++++---- weaknesses/MASVS-AUTH/MASWE-0020.md | 10 +++++----- weaknesses/MASVS-CODE/MASWE-0041.md | 6 +++--- weaknesses/MASVS-CODE/MASWE-0042.md | 4 ++-- weaknesses/MASVS-CODE/MASWE-0044.md | 6 +++--- weaknesses/MASVS-CODE/MASWE-0045.md | 2 +- weaknesses/MASVS-CODE/MASWE-0047.md | 2 +- weaknesses/MASVS-CODE/MASWE-0048.md | 16 ++++++++-------- weaknesses/MASVS-CODE/MASWE-0075.md | 2 +- weaknesses/MASVS-CRYPTO/MASWE-0007.md | 2 +- weaknesses/MASVS-CRYPTO/MASWE-0011.md | 2 +- weaknesses/MASVS-CRYPTO/MASWE-0016.md | 2 +- weaknesses/MASVS-NETWORK/MASWE-0025.md | 4 ++-- weaknesses/MASVS-NETWORK/MASWE-0026.md | 4 ++-- weaknesses/MASVS-PLATFORM/MASWE-0031.md | 2 +- weaknesses/MASVS-PLATFORM/MASWE-0032.md | 2 +- weaknesses/MASVS-PLATFORM/MASWE-0033.md | 2 +- weaknesses/MASVS-PLATFORM/MASWE-0035.md | 10 +++++----- weaknesses/MASVS-PLATFORM/MASWE-0036.md | 2 +- weaknesses/MASVS-PLATFORM/MASWE-0037.md | 2 +- weaknesses/MASVS-PLATFORM/MASWE-0038.md | 4 ++-- weaknesses/MASVS-RESILIENCE/MASWE-0050.md | 2 +- weaknesses/MASVS-RESILIENCE/MASWE-0054.md | 2 +- weaknesses/MASVS-STORAGE/MASWE-0001.md | 6 +++--- weaknesses/MASVS-STORAGE/MASWE-0002.md | 2 +- weaknesses/MASVS-STORAGE/MASWE-0003.md | 2 +- weaknesses/MASVS-STORAGE/MASWE-0004.md | 2 +- weaknesses/MASVS-STORAGE/MASWE-0005.md | 2 +- weaknesses/MASVS-STORAGE/MASWE-0006.md | 2 +- 29 files changed, 57 insertions(+), 57 deletions(-) diff --git a/.github/instructions/maswe.instructions.md b/.github/instructions/maswe.instructions.md index ee6a83d..8587545 100644 --- a/.github/instructions/maswe.instructions.md +++ b/.github/instructions/maswe.instructions.md @@ -74,11 +74,11 @@ Field rules: - **profiles**: MAS Testing Profiles that the weakness is relevant for. Most weaknesses apply to `L1` and `L2`. Resilience weaknesses apply to `R` and Privacy to `P`. Use the current profile values defined in - **mappings**: Cross-references to related controls and weaknesses in other standards. At least one MASVS v2 control is required. Mappings to MASVS v1, CWE, and Android risks are optional but encouraged when applicable. - **masvs-v1**: One or more MSTG v1 controls that covered this topic. This helps identify content to port from MASTG v1. - - **masvs-v2**: One or more MASVS v2 controls this weakness helps verify. At least one entry is required. + - **masvs-v2**: One or more MASVS v2 controls this weakness helps verify. At least one entry is required. Example: `masvs-v2: [MASVS-STORAGE-1]` which will be rendered as - **maswe-beta**: One or more MASWE v0.x (pre-1.0.0-rc) weaknesses that this weakness supersedes or absorbs. This is optional but encouraged for traceability. - - **cwe**: One or more CWE IDs that correspond to this weakness. This helps link to the broader software security ecosystem. - - **android-risks**: One or more specific risks from the Android developer documentation (https://developer.android.com/privacy-and-security/risks) that correspond to this weakness. This is an optional field that can help link to Android-specific guidance, but it should only be used when there is a clear match - - **android-core-app-quality**: One or more checklist item IDs from the [Android Core App Quality guidelines](https://developer.android.com/docs/quality-guidelines/core-app-quality), using the current named IDs (e.g. `Network_Security_Traffic`, `Minimize_Permissions`), not the legacy `SC-*`/`PS-*` numbering. Optional; only use when there is a clear match, and only for weaknesses whose `platform` includes `android`. + - **cwe**: One or more CWE IDs that correspond to this weakness. This helps link to the broader software security ecosystem. Example: `cwe: [200]` which will be rendered as + - **android-risks**: One or more specific risks from the Android developer documentation (https://developer.android.com/privacy-and-security/risks/) that correspond to this weakness. This is an optional field that can help link to Android-specific guidance, but it should only be used when there is a clear match + - **android-core-app-quality**: One or more checklist item IDs from the [Android Core App Quality guidelines](https://developer.android.com/docs/quality-guidelines/core-app-quality), using the current named IDs (e.g. `android-core-app-quality: [Network_Security_Traffic]` which will be rendered as ), not the legacy `SC-*`/`PS-*` numbering. Optional; only use when there is a clear match, and only for weaknesses whose `platform` includes `android`. - **refs**: External references. Prefer stable, vendor-neutral sources (official platform docs, CWE, NIST, academic papers). - **status**: When you generate a new MASWE draft, set `status: new`. diff --git a/weaknesses/MASVS-AUTH/MASWE-0020.md b/weaknesses/MASVS-AUTH/MASWE-0020.md index a47f407..0abba77 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0020.md +++ b/weaknesses/MASVS-AUTH/MASWE-0020.md @@ -10,11 +10,11 @@ mappings: masvs-v2: [MASVS-AUTH-1, MASVS-PLATFORM-1, MASVS-STORAGE-2] cwe: [200, 276, 284, 285, 287, 732, 749, 923, 925, 926] android-risks: - - https://developer.android.com/privacy-and-security/risks/content-resolver - - https://developer.android.com/privacy-and-security/risks/insecure-broadcast-receiver - - https://developer.android.com/privacy-and-security/risks/access-control-to-exported-components - - https://developer.android.com/privacy-and-security/risks/android-exported - - https://developer.android.com/privacy-and-security/risks/custom-permissions + - content-resolver + - insecure-broadcast-receiver + - access-control-to-exported-components + - android-exported + - custom-permissions android-core-app-quality: [Component_Export, Component_Permissions, Component_Protection] maswe-beta: [MASWE-0033, MASWE-0038, MASWE-0040, MASWE-0051, MASWE-0059, MASWE-0062, MASWE-0063, MASWE-0064, MASWE-0065, MASWE-0119] refs: diff --git a/weaknesses/MASVS-CODE/MASWE-0041.md b/weaknesses/MASVS-CODE/MASWE-0041.md index 607c255..1cadf92 100644 --- a/weaknesses/MASVS-CODE/MASWE-0041.md +++ b/weaknesses/MASVS-CODE/MASWE-0041.md @@ -10,12 +10,12 @@ mappings: masvs-v2: [MASVS-CODE-3] cwe: [1395, 1357] android-risks: - - https://developer.android.com/privacy-and-security/risks/insecure-library - - https://developer.android.com/privacy-and-security/risks/unsafe-download-manager + - insecure-library + - unsafe-download-manager android-core-app-quality: [SDK_Maintenance, Security_Provider_Initialization] maswe-beta: [MASWE-0076] refs: -- https://developer.android.com/privacy-and-security/risks/insecure-library +- insecure-library - https://www.cisa.gov/sites/default/files/2023-04/sbom-types-document-508c.pdf - https://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf - https://developer.android.com/guide/practices/sdk-best-practices diff --git a/weaknesses/MASVS-CODE/MASWE-0042.md b/weaknesses/MASVS-CODE/MASWE-0042.md index 8cf102a..aaefa2c 100644 --- a/weaknesses/MASVS-CODE/MASWE-0042.md +++ b/weaknesses/MASVS-CODE/MASWE-0042.md @@ -9,8 +9,8 @@ mappings: masvs-v2: [MASVS-CODE-1] cwe: [451, 693, 1104, 1357] android-risks: - - https://developer.android.com/privacy-and-security/risks/strandhogg - - https://developer.android.com/privacy-and-security/risks/unsafe-download-manager + - strandhogg + - unsafe-download-manager maswe-beta: [MASWE-0077, MASWE-0057] refs: - https://developer.android.com/topic/security/risks/strandhogg diff --git a/weaknesses/MASVS-CODE/MASWE-0044.md b/weaknesses/MASVS-CODE/MASWE-0044.md index 59de252..e9fd154 100644 --- a/weaknesses/MASVS-CODE/MASWE-0044.md +++ b/weaknesses/MASVS-CODE/MASWE-0044.md @@ -9,12 +9,12 @@ mappings: masvs-v2: [MASVS-CODE-4] cwe: [494] android-risks: - - https://developer.android.com/privacy-and-security/risks/dynamic-code-loading - - https://developer.android.com/privacy-and-security/risks/create-package-context + - dynamic-code-loading + - create-package-context android-core-app-quality: [App_Bundles] maswe-beta: [MASWE-0085] refs: -- https://developer.android.com/privacy-and-security/risks/dynamic-code-loading +- dynamic-code-loading status: new --- diff --git a/weaknesses/MASVS-CODE/MASWE-0045.md b/weaknesses/MASVS-CODE/MASWE-0045.md index 07c5431..d381185 100644 --- a/weaknesses/MASVS-CODE/MASWE-0045.md +++ b/weaknesses/MASVS-CODE/MASWE-0045.md @@ -9,7 +9,7 @@ mappings: masvs-v2: [MASVS-CODE-3, MASVS-CODE-4] cwe: [693] android-risks: - - https://developer.android.com/privacy-and-security/risks/use-of-native-code + - use-of-native-code maswe-beta: [MASWE-0116] refs: - https://partners.trellix.com/enterprise/en-us/assets/white-papers/wp-secure-coding-android-applications.pdf diff --git a/weaknesses/MASVS-CODE/MASWE-0047.md b/weaknesses/MASVS-CODE/MASWE-0047.md index c0bfbd8..5f516e6 100644 --- a/weaknesses/MASVS-CODE/MASWE-0047.md +++ b/weaknesses/MASVS-CODE/MASWE-0047.md @@ -10,7 +10,7 @@ mappings: masvs-v2: [MASVS-CODE-3, MASVS-AUTH-1, MASVS-CRYPTO-1, MASVS-NETWORK-1] cwe: [287, 326, 327, 1240] android-risks: - - https://developer.android.com/privacy-and-security/risks/bad-dns + - bad-dns android-core-app-quality: [Cryptographic_Algorithms] maswe-beta: [MASWE-0019, MASWE-0032, MASWE-0049] refs: diff --git a/weaknesses/MASVS-CODE/MASWE-0048.md b/weaknesses/MASVS-CODE/MASWE-0048.md index 1b8b06d..5085923 100644 --- a/weaknesses/MASVS-CODE/MASWE-0048.md +++ b/weaknesses/MASVS-CODE/MASWE-0048.md @@ -10,18 +10,18 @@ mappings: masvs-v2: [MASVS-CODE-4] cwe: [20, 22, 73, 89, 116, 345, 348, 349, 502, 611, 924] android-risks: - - https://developer.android.com/privacy-and-security/risks/path-traversal - - https://developer.android.com/privacy-and-security/risks/zip-path-traversal - - https://developer.android.com/privacy-and-security/risks/sql-injection - - https://developer.android.com/privacy-and-security/risks/unsafe-deserialization - - https://developer.android.com/privacy-and-security/risks/xml-external-entities-injection - - https://developer.android.com/privacy-and-security/risks/untrustworthy-contentprovider-provided-filename - - https://developer.android.com/privacy-and-security/risks/use-of-native-code + - path-traversal + - zip-path-traversal + - sql-injection + - unsafe-deserialization + - xml-external-entities-injection + - untrustworthy-contentprovider-provided-filename + - use-of-native-code maswe-beta: [MASWE-0079, MASWE-0080, MASWE-0081, MASWE-0082, MASWE-0083, MASWE-0084, MASWE-0086, MASWE-0087, MASWE-0088] refs: - https://developer.android.com/topic/security/risks/path-traversal - https://developer.android.com/topic/security/risks/sql-injection -- https://developer.android.com/privacy-and-security/risks/unsafe-deserialization +- unsafe-deserialization - https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html status: new --- diff --git a/weaknesses/MASVS-CODE/MASWE-0075.md b/weaknesses/MASVS-CODE/MASWE-0075.md index ab80d5b..eb60d05 100644 --- a/weaknesses/MASVS-CODE/MASWE-0075.md +++ b/weaknesses/MASVS-CODE/MASWE-0075.md @@ -9,7 +9,7 @@ mappings: masvs-v2: [MASVS-CODE-3] cwe: [506, 507, 511] refs: -- https://developer.android.com/privacy-and-security/risks/insecure-library +- insecure-library - https://support.google.com/googleplay/android-developer/answer/13326895 - https://developer.apple.com/support/third-party-SDK-requirements/ status: new diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0007.md b/weaknesses/MASVS-CRYPTO/MASWE-0007.md index dd0583b..3b1738a 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0007.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0007.md @@ -10,7 +10,7 @@ mappings: masvs-v2: [MASVS-CRYPTO-2] cwe: [331, 337, 338, 522] android-risks: - - https://developer.android.com/privacy-and-security/risks/weak-prng + - weak-prng android-core-app-quality: [Cryptographic_Algorithms] maswe-beta: [MASWE-0009, MASWE-0017] refs: diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0011.md b/weaknesses/MASVS-CRYPTO/MASWE-0011.md index 34d8dda..2be38ab 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0011.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0011.md @@ -10,7 +10,7 @@ mappings: masvs-v2: [MASVS-CRYPTO-1, MASVS-CRYPTO-2] cwe: [208, 323, 325, 326, 327, 329, 780] android-risks: - - https://developer.android.com/privacy-and-security/risks/broken-cryptographic-algorithm + - broken-cryptographic-algorithm android-core-app-quality: [Cryptographic_Algorithms] maswe-beta: [MASWE-0020, MASWE-0012, MASWE-0022, MASWE-0023] refs: diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0016.md b/weaknesses/MASVS-CRYPTO/MASWE-0016.md index 6f799ff..32b08c8 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0016.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0016.md @@ -10,7 +10,7 @@ mappings: masvs-v2: [MASVS-CRYPTO-1] cwe: [332, 337, 338] android-risks: - - https://developer.android.com/privacy-and-security/risks/weak-prng + - weak-prng android-core-app-quality: [Cryptographic_Algorithms] maswe-beta: [MASWE-0027] refs: diff --git a/weaknesses/MASVS-NETWORK/MASWE-0025.md b/weaknesses/MASVS-NETWORK/MASWE-0025.md index 1eb4d1a..4623eed 100644 --- a/weaknesses/MASVS-NETWORK/MASWE-0025.md +++ b/weaknesses/MASVS-NETWORK/MASWE-0025.md @@ -10,8 +10,8 @@ mappings: masvs-v2: [MASVS-NETWORK-1] cwe: [311, 319] android-risks: - - https://developer.android.com/privacy-and-security/risks/cleartext-communications - - https://developer.android.com/privacy-and-security/risks/insecure-machine-to-machine + - cleartext-communications + - insecure-machine-to-machine android-core-app-quality: [Network_Security_Traffic, Network_Security_Configuration] maswe-beta: [MASWE-0050, MASWE-0037, MASWE-0048] refs: diff --git a/weaknesses/MASVS-NETWORK/MASWE-0026.md b/weaknesses/MASVS-NETWORK/MASWE-0026.md index 4065959..024efd1 100644 --- a/weaknesses/MASVS-NETWORK/MASWE-0026.md +++ b/weaknesses/MASVS-NETWORK/MASWE-0026.md @@ -10,8 +10,8 @@ mappings: masvs-v2: [MASVS-NETWORK-1] cwe: [295, 297] android-risks: - - https://developer.android.com/privacy-and-security/risks/unsafe-trustmanager - - https://developer.android.com/privacy-and-security/risks/unsafe-hostname + - unsafe-trustmanager + - unsafe-hostname android-core-app-quality: [Network_Security_Configuration, Security_Provider_Initialization] maswe-beta: [MASWE-0052] refs: diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0031.md b/weaknesses/MASVS-PLATFORM/MASWE-0031.md index 747851f..d5c78c5 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0031.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0031.md @@ -10,7 +10,7 @@ mappings: masvs-v2: [MASVS-PLATFORM-3, MASVS-CODE-1] cwe: [1021] android-risks: - - https://developer.android.com/privacy-and-security/risks/tapjacking + - tapjacking maswe-beta: [MASWE-0056] refs: - https://developer.android.com/topic/security/risks/tapjacking diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0032.md b/weaknesses/MASVS-PLATFORM/MASWE-0032.md index 485cbfc..321b103 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0032.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0032.md @@ -10,7 +10,7 @@ mappings: masvs-v2: [MASVS-PLATFORM-1, MASVS-STORAGE-2, MASVS-CODE-4] cwe: [939, 917] android-risks: - - https://developer.android.com/privacy-and-security/risks/unsafe-use-of-deeplinks + - unsafe-use-of-deeplinks maswe-beta: [MASWE-0058] refs: - https://developer.apple.com/documentation/technotes/tn3155-debugging-universal-links diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0033.md b/weaknesses/MASVS-PLATFORM/MASWE-0033.md index 3ab2f44..5e96272 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0033.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0033.md @@ -9,7 +9,7 @@ mappings: masvs-v2: [MASVS-PLATFORM-1, MASVS-STORAGE-2] cwe: [200, 668] android-risks: - - https://developer.android.com/privacy-and-security/risks/secure-clipboard-handling + - secure-clipboard-handling maswe-beta: [MASWE-0059] refs: - https://developer.android.com/develop/ui/views/touch-and-input/copy-paste#PreventingSensitiveData diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0035.md b/weaknesses/MASVS-PLATFORM/MASWE-0035.md index 3a811a5..8718708 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0035.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0035.md @@ -9,11 +9,11 @@ mappings: masvs-v2: [MASVS-PLATFORM-1, MASVS-STORAGE-2] cwe: [927, 940] android-risks: - - https://developer.android.com/privacy-and-security/risks/implicit-intent-hijacking - - https://developer.android.com/privacy-and-security/risks/intent-redirection - - https://developer.android.com/privacy-and-security/risks/pending-intent - - https://developer.android.com/privacy-and-security/risks/sender-of-pending-intents - - https://developer.android.com/privacy-and-security/risks/sticky-broadcast + - implicit-intent-hijacking + - intent-redirection + - pending-intent + - sender-of-pending-intents + - sticky-broadcast android-core-app-quality: [Component_Permissions] maswe-beta: [MASWE-0066] refs: diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0036.md b/weaknesses/MASVS-PLATFORM/MASWE-0036.md index 76c3877..0e64cb4 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0036.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0036.md @@ -10,7 +10,7 @@ mappings: masvs-v2: [MASVS-PLATFORM-2, MASVS-STORAGE-2] cwe: [749, 94] android-risks: - - https://developer.android.com/privacy-and-security/risks/insecure-webview-native-bridges + - insecure-webview-native-bridges android-core-app-quality: [WebView_JavaScript] maswe-beta: [MASWE-0068] refs: diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0037.md b/weaknesses/MASVS-PLATFORM/MASWE-0037.md index 3fcbd3b..8d09bfa 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0037.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0037.md @@ -10,7 +10,7 @@ mappings: masvs-v2: [MASVS-PLATFORM-2, MASVS-STORAGE-2, MASVS-CODE-4] cwe: [22, 79, 200, 669] android-risks: - - https://developer.android.com/privacy-and-security/risks/webview-unsafe-file-inclusion + - webview-unsafe-file-inclusion android-core-app-quality: [WebView_Asset_Loader] maswe-beta: [MASWE-0069, MASWE-0073] refs: diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0038.md b/weaknesses/MASVS-PLATFORM/MASWE-0038.md index 621c49d..8db8829 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0038.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0038.md @@ -9,8 +9,8 @@ mappings: masvs-v2: [MASVS-PLATFORM-2, MASVS-CODE-4] cwe: [79, 601, 829] android-risks: - - https://developer.android.com/privacy-and-security/risks/cross-app-scripting - - https://developer.android.com/privacy-and-security/risks/unsafe-uri-loading + - cross-app-scripting + - unsafe-uri-loading maswe-beta: [MASWE-0071, MASWE-0070, MASWE-0072] refs: - https://blog.oversecured.com/Evernote-Universal-XSS-theft-of-all-cookies-from-all-sites-and-more/ diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0050.md b/weaknesses/MASVS-RESILIENCE/MASWE-0050.md index a4c641f..5ee51c8 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0050.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0050.md @@ -10,7 +10,7 @@ mappings: masvs-v2: [MASVS-RESILIENCE-4, MASVS-PLATFORM-2] cwe: [489] android-risks: - - https://developer.android.com/privacy-and-security/risks/android-debuggable + - android-debuggable maswe-beta: [MASWE-0067, MASWE-0074] refs: - https://developer.android.com/guide/topics/manifest/application-element diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0054.md b/weaknesses/MASVS-RESILIENCE/MASWE-0054.md index 4318917..a5eb462 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0054.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0054.md @@ -10,7 +10,7 @@ mappings: masvs-v2: [MASVS-RESILIENCE-3] cwe: [489, 497, 540, 912, 1295] android-risks: - - https://developer.android.com/privacy-and-security/risks/test-debug + - test-debug android-core-app-quality: [Production_Build_Quality] maswe-beta: [MASWE-0094, MASWE-0093, MASWE-0095] status: new diff --git a/weaknesses/MASVS-STORAGE/MASWE-0001.md b/weaknesses/MASVS-STORAGE/MASWE-0001.md index fe0405c..4b5794f 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0001.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0001.md @@ -10,11 +10,11 @@ mappings: masvs-v2: [MASVS-STORAGE-2, MASVS-PRIVACY-1] cwe: [209, 359, 497, 532] android-risks: - - https://developer.android.com/privacy-and-security/risks/log-info-disclosure + - log-info-disclosure android-core-app-quality: [Sensitive_Data_Logging] maswe-beta: [MASWE-0001] refs: -- https://developer.android.com/privacy-and-security/risks/log-info-disclosure +- log-info-disclosure - https://developer.apple.com/documentation/os/logging/generating_log_messages_from_your_code status: new --- @@ -49,4 +49,4 @@ This can lead to: - **Redact Sensitive Data**: Where log statements are needed around sensitive values, redact or mask those values before writing them. - **Remove Unnecessary Logging**: Strip logging statements from release builds unless they are deemed necessary to the app and explicitly identified as safe, e.g. as a result of a security audit. - **Use Log Levels Properly**: Assign debug-only details to debug or verbose levels and ensure those levels are disabled in production releases. -- **Disable Logging in Production**: Use build flags or configuration to disable logging in production releases, following the platform guidance for [Android](https://developer.android.com/privacy-and-security/risks/log-info-disclosure#mitigations) and [iOS](https://developer.apple.com/documentation/os/logging/generating_log_messages_from_your_code#3665948). +- **Disable Logging in Production**: Use build flags or configuration to disable logging in production releases, following the platform guidance for [Android](log-info-disclosure#mitigations) and [iOS](https://developer.apple.com/documentation/os/logging/generating_log_messages_from_your_code#3665948). diff --git a/weaknesses/MASVS-STORAGE/MASWE-0002.md b/weaknesses/MASVS-STORAGE/MASWE-0002.md index 40355c9..18206a9 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0002.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0002.md @@ -10,7 +10,7 @@ mappings: masvs-v2: [MASVS-STORAGE-2, MASVS-PRIVACY-1] cwe: [212, 313] android-risks: - - https://developer.android.com/privacy-and-security/risks/backup-best-practices + - backup-best-practices maswe-beta: [MASWE-0004, MASWE-0003] refs: - https://developer.android.com/guide/topics/data/autobackup#include-exclude-android-11 diff --git a/weaknesses/MASVS-STORAGE/MASWE-0003.md b/weaknesses/MASVS-STORAGE/MASWE-0003.md index 94332e2..672529a 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0003.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0003.md @@ -10,7 +10,7 @@ mappings: masvs-v2: [MASVS-STORAGE-1, MASVS-STORAGE-2, MASVS-CRYPTO-2, MASVS-PRIVACY-1] cwe: [200, 284, 312, 313, 732, 922] android-risks: - - https://developer.android.com/privacy-and-security/risks/file-providers + - file-providers maswe-beta: [MASWE-0006, MASWE-0002, MASWE-0118] refs: - https://developer.apple.com/documentation/uikit/protecting_the_user_s_privacy/encrypting_your_app_s_files diff --git a/weaknesses/MASVS-STORAGE/MASWE-0004.md b/weaknesses/MASVS-STORAGE/MASWE-0004.md index 1e24ca4..08e8df7 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0004.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0004.md @@ -10,7 +10,7 @@ mappings: masvs-v2: [MASVS-STORAGE-1, MASVS-STORAGE-2] cwe: [200, 284, 312, 313, 732, 921, 922] android-risks: - - https://developer.android.com/privacy-and-security/risks/sensitive-data-external-storage + - sensitive-data-external-storage android-core-app-quality: [Sensitive_Data_Storage] maswe-beta: [MASWE-0007, MASWE-0002] refs: diff --git a/weaknesses/MASVS-STORAGE/MASWE-0005.md b/weaknesses/MASVS-STORAGE/MASWE-0005.md index e1159dc..68929c4 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0005.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0005.md @@ -10,7 +10,7 @@ mappings: masvs-v2: [MASVS-STORAGE-1, MASVS-CRYPTO-2] cwe: [312, 318, 321, 322] android-risks: - - https://developer.android.com/privacy-and-security/risks/hardcoded-cryptographic-secrets + - hardcoded-cryptographic-secrets maswe-beta: [MASWE-0013, MASWE-0014, MASWE-0016] refs: - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf diff --git a/weaknesses/MASVS-STORAGE/MASWE-0006.md b/weaknesses/MASVS-STORAGE/MASWE-0006.md index 26a1e7c..b291281 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0006.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0006.md @@ -10,7 +10,7 @@ mappings: masvs-v2: [MASVS-STORAGE-1] cwe: [312, 540, 798] android-risks: - - https://developer.android.com/privacy-and-security/risks/insecure-api-usage + - insecure-api-usage maswe-beta: [MASWE-0005, MASWE-0013, MASWE-0036] refs: - https://cloud.google.com/docs/authentication/api-keys#securing From 35e1301607fbd31407ca6845df282f1f5f5faf2b Mon Sep 17 00:00:00 2001 From: Carlos Holguera Date: Tue, 21 Jul 2026 09:59:29 +0200 Subject: [PATCH 13/70] fix some attacks --- .github/instructions/impact-attacks.yaml | 14 ++++++-------- .github/instructions/maswe.instructions.md | 8 ++++++++ weaknesses/MASVS-CODE/MASWE-0040.md | 2 +- weaknesses/MASVS-CODE/MASWE-0041.md | 1 - weaknesses/MASVS-CODE/MASWE-0042.md | 5 +++-- weaknesses/MASVS-CODE/MASWE-0043.md | 2 +- weaknesses/MASVS-CODE/MASWE-0045.md | 2 +- weaknesses/MASVS-CODE/MASWE-0046.md | 2 +- weaknesses/MASVS-CODE/MASWE-0047.md | 2 +- weaknesses/MASVS-CRYPTO/MASWE-0007.md | 2 +- weaknesses/MASVS-CRYPTO/MASWE-0009.md | 3 ++- weaknesses/MASVS-CRYPTO/MASWE-0016.md | 2 +- 12 files changed, 26 insertions(+), 19 deletions(-) diff --git a/.github/instructions/impact-attacks.yaml b/.github/instructions/impact-attacks.yaml index 1d4292b..b6cc88f 100644 --- a/.github/instructions/impact-attacks.yaml +++ b/.github/instructions/impact-attacks.yaml @@ -16,7 +16,7 @@ - Obtaining a valid certificate for the target domain from a compromised, coerced, or rogue Certificate Authority (CA). - Installing an attacker-controlled CA certificate on a device they control to inspect the app's traffic. - Brute-forcing cryptographic material generated with insufficient length. -- Predicting or reproducing values generated with insufficient entropy. +- Recovering or guessing the seed used by the generator to reproduce its output. - Intercepting cryptographic keys exported in plaintext. - Performing cryptanalysis of broken algorithms, modes, or parameters. - Exploiting predictable or reused IVs or nonces to detect patterns or recover plaintext. @@ -24,7 +24,6 @@ - Observing enough outputs to recover the internal state of a non-cryptographic PRNG. - Performing offline brute-force or dictionary attacks against keys derived from low-entropy inputs. - Precomputing derived keys when salts are missing, hardcoded, or reused. -- Applying a single compromised key to all current and historical data protected with it. - Invoking keystore operations on a compromised or stolen device when key use does not require user authentication. - Crafting collisions or second preimages for broken hash functions. - Replaying previously captured valid messages or tags. @@ -51,13 +50,12 @@ - Modifying or replaying mutable PendingIntents obtained from the app. - Injecting malicious JavaScript into WebView content (e.g., via MITM on insecure connections or a compromised website). - Harvesting on-screen content through a malicious accessibility service the user was tricked into enabling. -- Exploiting known vulnerabilities in outdated app versions that users are still running. -- Exploiting platform vulnerabilities on outdated OS versions the app still supports. -- Leveraging legacy platform behaviors applied to apps targeting outdated platform versions. +- Targeting users who remain on an app version with publicly known vulnerabilities. +- Installing a malicious app on a device running an OS version affected by unpatched platform vulnerabilities. +- Running the app on a device whose OS version lacks the platform protections the app relies on. +- Accessing app data exposed by legacy compatibility behaviors that the platform still applies to apps targeting an old version. - Substituting or modifying code that the app loads at runtime from writable or unverified locations. -- Exploiting memory-corruption vulnerabilities in the app's native code. -- Exploiting known weaknesses in deprecated APIs or components the app still uses. -- Exploiting flaws in custom or unproven security implementations. +- Identifying deprecated components in the app package and using publicly documented attacks against them. - Supplying crafted input through any external interface (network, IPC, files, UI, or peripherals). - Compromising a dependency, SDK, or build tool in the app's supply chain. - Introducing malicious code through an insider or compromised developer account. diff --git a/.github/instructions/maswe.instructions.md b/.github/instructions/maswe.instructions.md index 8587545..088168c 100644 --- a/.github/instructions/maswe.instructions.md +++ b/.github/instructions/maswe.instructions.md @@ -144,8 +144,16 @@ List all relevant attack paths, using wording from `impact-attacks.yaml` wheneve - [Alternative attack path]. ``` +Each attack path must. + +- Name a concrete attacker action or a precondition the attacker needs (installing an app, accessing storage, obtaining the package, running the app in a controlled environment), never restate the outcome already given in the opening sentence. The opening sentence says *what* attackers achieve; the bullets say *how* they get there. +- Be an action someone could observe or attempt, not a property of the app. "Leveraging legacy platform behaviors applied to apps targeting outdated platform versions" describes the weakness; "Accessing app data exposed by legacy compatibility behaviors that the platform still applies to apps targeting an old version" describes the attack. +- Reuse the opening sentence's verb only when the bullet adds a distinct actor, interface, or precondition. A bullet that repeats the opener's verb and its object ("Attackers can exploit flaws in non-standard security implementations by: - Exploiting flaws in custom or unproven security implementations.") is a restatement and must be rewritten or dropped. + Do not repeat consequences for each attack path when they are the same. +If no entry in `impact-attacks.yaml` fits, add one there in the same style and reuse it, rather than inventing per-weakness wording. + Then add. ```md diff --git a/weaknesses/MASVS-CODE/MASWE-0040.md b/weaknesses/MASVS-CODE/MASWE-0040.md index 6d650b0..e24259e 100644 --- a/weaknesses/MASVS-CODE/MASWE-0040.md +++ b/weaknesses/MASVS-CODE/MASWE-0040.md @@ -33,7 +33,7 @@ When a critical vulnerability is found in a production app, the developer needs Attackers can exploit vulnerabilities that remain reachable in outdated app versions by: -- Exploiting known vulnerabilities in outdated app versions that users are still running. +- Targeting users who remain on an app version with publicly known vulnerabilities. - Patching or repackaging the app to remove or alter client-side checks. This can lead to: diff --git a/weaknesses/MASVS-CODE/MASWE-0041.md b/weaknesses/MASVS-CODE/MASWE-0041.md index 1cadf92..0b3049a 100644 --- a/weaknesses/MASVS-CODE/MASWE-0041.md +++ b/weaknesses/MASVS-CODE/MASWE-0041.md @@ -15,7 +15,6 @@ mappings: android-core-app-quality: [SDK_Maintenance, Security_Provider_Initialization] maswe-beta: [MASWE-0076] refs: -- insecure-library - https://www.cisa.gov/sites/default/files/2023-04/sbom-types-document-508c.pdf - https://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf - https://developer.android.com/guide/practices/sdk-best-practices diff --git a/weaknesses/MASVS-CODE/MASWE-0042.md b/weaknesses/MASVS-CODE/MASWE-0042.md index aaefa2c..9999eb6 100644 --- a/weaknesses/MASVS-CODE/MASWE-0042.md +++ b/weaknesses/MASVS-CODE/MASWE-0042.md @@ -30,9 +30,10 @@ Ensuring a recent minimum platform version guarantees the availability of securi ## Impact -Attackers can exploit platform-level weaknesses on the outdated OS versions the app supports by: +Attackers can exploit platform-level weaknesses that the app cannot fix on its own by: -- Exploiting platform vulnerabilities on outdated OS versions the app still supports. +- Installing a malicious app on a device running an OS version affected by unpatched platform vulnerabilities. +- Running the app on a device whose OS version lacks the platform protections the app relies on. This can lead to: diff --git a/weaknesses/MASVS-CODE/MASWE-0043.md b/weaknesses/MASVS-CODE/MASWE-0043.md index c77538c..124ce18 100644 --- a/weaknesses/MASVS-CODE/MASWE-0043.md +++ b/weaknesses/MASVS-CODE/MASWE-0043.md @@ -31,7 +31,7 @@ Targeting the latest platform version, via `targetSdkVersion` on Android or by b Attackers can exploit the absence of modern platform protections by: -- Leveraging legacy platform behaviors applied to apps targeting outdated platform versions. +- Accessing app data exposed by legacy compatibility behaviors that the platform still applies to apps targeting an old version. This can lead to: diff --git a/weaknesses/MASVS-CODE/MASWE-0045.md b/weaknesses/MASVS-CODE/MASWE-0045.md index d381185..f10c343 100644 --- a/weaknesses/MASVS-CODE/MASWE-0045.md +++ b/weaknesses/MASVS-CODE/MASWE-0045.md @@ -35,7 +35,7 @@ Mitigations such as stack canaries (stack-smashing protection), Address Space La Attackers can exploit memory-corruption bugs with substantially less effort by: -- Exploiting memory-corruption vulnerabilities in the app's native code. +- Obtaining the app package and reverse engineering it. - Supplying crafted input through any external interface (network, IPC, files, UI, or peripherals). This can lead to: diff --git a/weaknesses/MASVS-CODE/MASWE-0046.md b/weaknesses/MASVS-CODE/MASWE-0046.md index 32cdbe5..c2eda9e 100644 --- a/weaknesses/MASVS-CODE/MASWE-0046.md +++ b/weaknesses/MASVS-CODE/MASWE-0046.md @@ -33,7 +33,7 @@ Platforms deprecate APIs precisely because better-designed replacements exist, o Attackers can exploit weaknesses that maintained APIs have already addressed by: -- Exploiting known weaknesses in deprecated APIs or components the app still uses. +- Identifying deprecated components in the app package and using publicly documented attacks against them. This can lead to: diff --git a/weaknesses/MASVS-CODE/MASWE-0047.md b/weaknesses/MASVS-CODE/MASWE-0047.md index 5f516e6..3d83781 100644 --- a/weaknesses/MASVS-CODE/MASWE-0047.md +++ b/weaknesses/MASVS-CODE/MASWE-0047.md @@ -39,7 +39,7 @@ Platform APIs and vetted libraries are designed and maintained by experts, incor Attackers can exploit flaws in non-standard security implementations by: -- Exploiting flaws in custom or unproven security implementations. +- Obtaining the app package and reverse engineering it. - Performing cryptanalysis of broken algorithms, modes, or parameters. - Performing a Machine-in-the-Middle (MITM) attack, e.g., via ARP poisoning, DNS spoofing, or a rogue access point. diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0007.md b/weaknesses/MASVS-CRYPTO/MASWE-0007.md index 3b1738a..306f167 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0007.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0007.md @@ -42,7 +42,7 @@ In cryptography, security strength is heavily influenced by how keys are generat Attackers can predict or reproduce improperly generated cryptographic keys by: - Brute-forcing cryptographic material generated with insufficient length. -- Predicting or reproducing values generated with insufficient entropy. +- Recovering or guessing the seed used by the generator to reproduce its output. - Intercepting cryptographic keys exported in plaintext. This can lead to: diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0009.md b/weaknesses/MASVS-CRYPTO/MASWE-0009.md index 98c9b09..ed4aff3 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0009.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0009.md @@ -31,7 +31,8 @@ Cryptographic keys have a limited cryptoperiod, as defined in [NIST.SP.800-57pt1 Attackers can decrypt or forge all data ever protected with a compromised key by: -- Applying a single compromised key to all current and historical data protected with it. +- Obtaining the app package and reverse engineering it. +- Accessing the device storage on a compromised device. This can lead to: diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0016.md b/weaknesses/MASVS-CRYPTO/MASWE-0016.md index 32b08c8..5e4969a 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0016.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0016.md @@ -36,7 +36,7 @@ A [PRNG](https://en.wikipedia.org/wiki/Pseudorandom_number_generator) generates Attackers can predict or reproduce random values used in security contexts by: - Observing enough outputs to recover the internal state of a non-cryptographic PRNG. -- Predicting or reproducing values generated with insufficient entropy. +- Recovering or guessing the seed used by the generator to reproduce its output. - Obtaining the app package and reverse engineering it. This can lead to: From 1888cabff8cde100ac7bb3ce8d76e0522edd6211 Mon Sep 17 00:00:00 2001 From: Carlos Holguera Date: Tue, 21 Jul 2026 23:14:00 +0200 Subject: [PATCH 14/70] extract attacks and threats to yaml files and reference with IDs in the MASWE metadata --- .github/instructions/attacks.yaml | 89 +++++++++++++++++++ .github/instructions/impact-attacks.yaml | 89 ------------------- .github/instructions/impact-patterns.yaml | 23 ----- .../{impact-labels.yaml => impact.yaml} | 0 .github/instructions/index.md | 14 ++- .github/instructions/maswe.instructions.md | 89 ++++++++----------- .github/instructions/threats.yaml | 77 ++++++++++++++++ weaknesses/MASVS-AUTH/MASWE-0017.md | 9 +- weaknesses/MASVS-AUTH/MASWE-0018.md | 10 +-- weaknesses/MASVS-AUTH/MASWE-0019.md | 9 +- weaknesses/MASVS-AUTH/MASWE-0020.md | 9 +- weaknesses/MASVS-AUTH/MASWE-0021.md | 11 +-- weaknesses/MASVS-AUTH/MASWE-0022.md | 8 +- weaknesses/MASVS-AUTH/MASWE-0023.md | 8 +- weaknesses/MASVS-AUTH/MASWE-0024.md | 9 +- weaknesses/MASVS-CODE/MASWE-0040.md | 9 +- weaknesses/MASVS-CODE/MASWE-0041.md | 8 +- weaknesses/MASVS-CODE/MASWE-0042.md | 9 +- weaknesses/MASVS-CODE/MASWE-0043.md | 8 +- weaknesses/MASVS-CODE/MASWE-0044.md | 9 +- weaknesses/MASVS-CODE/MASWE-0045.md | 9 +- weaknesses/MASVS-CODE/MASWE-0046.md | 8 +- weaknesses/MASVS-CODE/MASWE-0047.md | 10 +-- weaknesses/MASVS-CODE/MASWE-0048.md | 9 +- weaknesses/MASVS-CODE/MASWE-0075.md | 9 +- weaknesses/MASVS-CODE/MASWE-0077.md | 9 +- weaknesses/MASVS-CRYPTO/MASWE-0007.md | 10 +-- weaknesses/MASVS-CRYPTO/MASWE-0008.md | 9 +- weaknesses/MASVS-CRYPTO/MASWE-0009.md | 9 +- weaknesses/MASVS-CRYPTO/MASWE-0010.md | 10 +-- weaknesses/MASVS-CRYPTO/MASWE-0011.md | 11 +-- weaknesses/MASVS-CRYPTO/MASWE-0012.md | 8 +- weaknesses/MASVS-CRYPTO/MASWE-0013.md | 10 +-- weaknesses/MASVS-CRYPTO/MASWE-0014.md | 10 +-- weaknesses/MASVS-CRYPTO/MASWE-0015.md | 8 +- weaknesses/MASVS-CRYPTO/MASWE-0016.md | 10 +-- weaknesses/MASVS-NETWORK/MASWE-0025.md | 10 +-- weaknesses/MASVS-NETWORK/MASWE-0026.md | 9 +- weaknesses/MASVS-NETWORK/MASWE-0027.md | 10 +-- weaknesses/MASVS-PLATFORM/MASWE-0028.md | 10 +-- weaknesses/MASVS-PLATFORM/MASWE-0029.md | 9 +- weaknesses/MASVS-PLATFORM/MASWE-0030.md | 10 +-- weaknesses/MASVS-PLATFORM/MASWE-0031.md | 8 +- weaknesses/MASVS-PLATFORM/MASWE-0032.md | 9 +- weaknesses/MASVS-PLATFORM/MASWE-0033.md | 8 +- weaknesses/MASVS-PLATFORM/MASWE-0034.md | 8 +- weaknesses/MASVS-PLATFORM/MASWE-0035.md | 10 +-- weaknesses/MASVS-PLATFORM/MASWE-0036.md | 9 +- weaknesses/MASVS-PLATFORM/MASWE-0037.md | 9 +- weaknesses/MASVS-PLATFORM/MASWE-0038.md | 9 +- weaknesses/MASVS-PLATFORM/MASWE-0039.md | 8 +- weaknesses/MASVS-PRIVACY/MASWE-0065.md | 9 +- weaknesses/MASVS-PRIVACY/MASWE-0066.md | 9 +- weaknesses/MASVS-PRIVACY/MASWE-0067.md | 9 +- weaknesses/MASVS-PRIVACY/MASWE-0068.md | 9 +- weaknesses/MASVS-PRIVACY/MASWE-0069.md | 8 +- weaknesses/MASVS-PRIVACY/MASWE-0070.md | 9 +- weaknesses/MASVS-PRIVACY/MASWE-0071.md | 10 +-- weaknesses/MASVS-PRIVACY/MASWE-0072.md | 9 +- weaknesses/MASVS-PRIVACY/MASWE-0073.md | 9 +- weaknesses/MASVS-PRIVACY/MASWE-0074.md | 9 +- weaknesses/MASVS-RESILIENCE/MASWE-0049.md | 8 +- weaknesses/MASVS-RESILIENCE/MASWE-0050.md | 10 +-- weaknesses/MASVS-RESILIENCE/MASWE-0051.md | 8 +- weaknesses/MASVS-RESILIENCE/MASWE-0052.md | 8 +- weaknesses/MASVS-RESILIENCE/MASWE-0053.md | 8 +- weaknesses/MASVS-RESILIENCE/MASWE-0054.md | 9 +- weaknesses/MASVS-RESILIENCE/MASWE-0055.md | 8 +- weaknesses/MASVS-RESILIENCE/MASWE-0056.md | 10 +-- weaknesses/MASVS-RESILIENCE/MASWE-0057.md | 8 +- weaknesses/MASVS-RESILIENCE/MASWE-0058.md | 9 +- weaknesses/MASVS-RESILIENCE/MASWE-0059.md | 10 +-- weaknesses/MASVS-RESILIENCE/MASWE-0060.md | 8 +- weaknesses/MASVS-RESILIENCE/MASWE-0061.md | 8 +- weaknesses/MASVS-RESILIENCE/MASWE-0062.md | 9 +- weaknesses/MASVS-RESILIENCE/MASWE-0063.md | 9 +- weaknesses/MASVS-RESILIENCE/MASWE-0064.md | 9 +- weaknesses/MASVS-RESILIENCE/MASWE-0076.md | 9 +- weaknesses/MASVS-STORAGE/MASWE-0001.md | 9 +- weaknesses/MASVS-STORAGE/MASWE-0002.md | 9 +- weaknesses/MASVS-STORAGE/MASWE-0003.md | 10 +-- weaknesses/MASVS-STORAGE/MASWE-0004.md | 9 +- weaknesses/MASVS-STORAGE/MASWE-0005.md | 10 +-- weaknesses/MASVS-STORAGE/MASWE-0006.md | 8 +- 84 files changed, 368 insertions(+), 707 deletions(-) create mode 100644 .github/instructions/attacks.yaml delete mode 100644 .github/instructions/impact-attacks.yaml delete mode 100644 .github/instructions/impact-patterns.yaml rename .github/instructions/{impact-labels.yaml => impact.yaml} (100%) create mode 100644 .github/instructions/threats.yaml diff --git a/.github/instructions/attacks.yaml b/.github/instructions/attacks.yaml new file mode 100644 index 0000000..3b91f49 --- /dev/null +++ b/.github/instructions/attacks.yaml @@ -0,0 +1,89 @@ +MAS-ATTACK-0001: Obtaining the app package and reverse engineering it. +MAS-ATTACK-0002: Debugging the app at runtime. +MAS-ATTACK-0003: Using dynamic instrumentation. +MAS-ATTACK-0004: Attaching a remote inspector to the app's debuggable web content. +MAS-ATTACK-0005: Accessing the device storage on a compromised device. +MAS-ATTACK-0006: Accessing the system logs on a compromised device or from an app holding log-access permissions. +MAS-ATTACK-0007: Accessing files exposed through incorrect file permissions or misconfigured content providers. +MAS-ATTACK-0008: Extracting local or cloud backups of the device. +MAS-ATTACK-0009: Tampering with backup contents and restoring the modified backup to a device. +MAS-ATTACK-0010: Accessing shared or external storage from any app holding the corresponding permissions. +MAS-ATTACK-0011: Physically removing and reading external storage media such as SD cards. +MAS-ATTACK-0012: Monitoring network traffic on the same network (e.g., public Wi-Fi or a compromised router). +MAS-ATTACK-0013: Monitoring local or proximity interfaces such as Bluetooth, NFC, or USB. +MAS-ATTACK-0014: Performing a Machine-in-the-Middle (MITM) attack, e.g., via ARP poisoning, DNS spoofing, or a rogue access point. +MAS-ATTACK-0015: Presenting a fraudulent or otherwise invalid certificate that the app accepts. +MAS-ATTACK-0016: Obtaining a valid certificate for the target domain from a compromised, coerced, or rogue Certificate Authority (CA). +MAS-ATTACK-0017: Installing an attacker-controlled CA certificate on a device they control to inspect the app's traffic. +MAS-ATTACK-0018: Brute-forcing cryptographic material generated with insufficient length. +MAS-ATTACK-0019: Recovering or guessing the seed used by the generator to reproduce its output. +MAS-ATTACK-0020: Intercepting cryptographic keys exported in plaintext. +MAS-ATTACK-0021: Performing cryptanalysis of broken algorithms, modes, or parameters. +MAS-ATTACK-0022: Exploiting predictable or reused IVs or nonces to detect patterns or recover plaintext. +MAS-ATTACK-0023: Exploiting padding oracles exposed through observable error signals or timing differences. +MAS-ATTACK-0024: Observing enough outputs to recover the internal state of a non-cryptographic PRNG. +MAS-ATTACK-0025: Performing offline brute-force or dictionary attacks against keys derived from low-entropy inputs. +MAS-ATTACK-0026: Precomputing derived keys when salts are missing, hardcoded, or reused. +MAS-ATTACK-0027: Invoking keystore operations on a compromised or stolen device when key use does not require user authentication. +MAS-ATTACK-0028: Crafting collisions or second preimages for broken hash functions. +MAS-ATTACK-0029: Replaying previously captured valid messages or tags. +MAS-ATTACK-0030: Recovering private keys from predictable or reused signature nonces. +MAS-ATTACK-0031: Presenting data with invalid, stripped, or attacker-signed signatures that the app accepts. +MAS-ATTACK-0032: Using a victim's device with an active session (e.g., an unlocked or stolen device). +MAS-ATTACK-0033: Reusing stolen session tokens obtained through other attacks. +MAS-ATTACK-0034: Using a known, guessed, or shoulder-surfed device credential (PIN, pattern, or password). +MAS-ATTACK-0035: Enrolling additional biometrics on the device after obtaining the device credential. +MAS-ATTACK-0036: Displaying overlays or tampering with the UI to alter what the user sees while approving an action. +MAS-ATTACK-0037: Manipulating a compromised OS to alter or fabricate the confirmation flow. +MAS-ATTACK-0038: Invoking exported or unprotected app components from another app installed on the device. +MAS-ATTACK-0039: Connecting to open ports or local services exposed by the app. +MAS-ATTACK-0040: Patching or repackaging the app to remove or alter client-side checks. +MAS-ATTACK-0041: Reading sensitive data from the clipboard when users copy it between apps. +MAS-ATTACK-0042: Phishing credentials through lookalike apps or pages when users must type them manually. +MAS-ATTACK-0043: Observing the device screen while sensitive data is displayed or entered (shoulder surfing). +MAS-ATTACK-0044: Reading notification content shown on the lock screen without unlocking the device. +MAS-ATTACK-0045: Reading notification content from another app holding notification-access permissions. +MAS-ATTACK-0046: Registering the same custom URL scheme to intercept links intended for the app. +MAS-ATTACK-0047: Delivering crafted deep links or intents from a malicious app or web page. +MAS-ATTACK-0048: Capturing user input through a malicious custom keyboard or app extension. +MAS-ATTACK-0049: Registering intent filters to intercept implicit intents sent by the app. +MAS-ATTACK-0050: Modifying or replaying mutable PendingIntents obtained from the app. +MAS-ATTACK-0051: Injecting malicious JavaScript into WebView content (e.g., via MITM on insecure connections or a compromised website). +MAS-ATTACK-0052: Harvesting on-screen content through a malicious accessibility service the user was tricked into enabling. +MAS-ATTACK-0053: Targeting users who remain on an app version with publicly known vulnerabilities. +MAS-ATTACK-0054: Installing a malicious app on a device running an OS version affected by unpatched platform vulnerabilities. +MAS-ATTACK-0055: Running the app on a device whose OS version lacks the platform protections the app relies on. +MAS-ATTACK-0056: Accessing app data exposed by legacy compatibility behaviors that the platform still applies to apps targeting an old version. +MAS-ATTACK-0057: Substituting or modifying code that the app loads at runtime from writable or unverified locations. +MAS-ATTACK-0058: Identifying deprecated components in the app package and using publicly documented attacks against them. +MAS-ATTACK-0059: Supplying crafted input through any external interface (network, IPC, files, UI, or peripherals). +MAS-ATTACK-0060: Compromising a dependency, SDK, or build tool in the app's supply chain. +MAS-ATTACK-0061: Introducing malicious code through an insider or compromised developer account. +MAS-ATTACK-0062: Distributing tampered builds that cannot be distinguished from legitimate ones. +MAS-ATTACK-0063: Accessing a lost or stolen device that has no secure lock screen configured. +MAS-ATTACK-0064: Inspecting or modifying app traffic on a device they control after bypassing transport protections (e.g., pinning). +MAS-ATTACK-0065: Running the app on a rooted or jailbroken device they control. +MAS-ATTACK-0066: Running the app in an emulator or virtual device. +MAS-ATTACK-0067: Running the app inside an app-virtualization or cloning framework. +MAS-ATTACK-0068: Impersonating the app with scripts, bots, or tampered clients when interacting with the backend. +MAS-ATTACK-0069: Installing a repackaged version of the app on victim devices. +MAS-ATTACK-0070: Modifying the app's files or resources on a compromised device. +MAS-ATTACK-0071: Capturing or recording the screen from another app or an external tool. +MAS-ATTACK-0072: Accessing screenshots automatically taken by the system, e.g., when the app moves to the background. +MAS-ATTACK-0073: Identifying vulnerable dependency versions in the app package and using public advisories or exploits. +MAS-ATTACK-0074: Collecting and correlating identifiers and usage data across apps, devices, and services. +MAS-ATTACK-0075: Contacting undeclared tracking domains that platform enforcement cannot block. +MAS-ATTACK-0076: Handling credentials and browsing state inside the app instead of isolated system flows. +MAS-ATTACK-0077: Collecting non-resettable identifiers or misusing resettable ones. +MAS-ATTACK-0078: Linking directly identifiable data to real-world identities. +MAS-ATTACK-0079: Operating without a privacy policy or under a vague, generic, or inaccessible one. +MAS-ATTACK-0080: Deviating from the practices stated in the published privacy policy. +MAS-ATTACK-0081: Collecting or sharing data categories that are not declared in the platform's privacy labels. +MAS-ATTACK-0082: Transmitting undeclared identifiers or analytics data to first- or third-party services over the network. +MAS-ATTACK-0083: Providing no way for users to delete, export, modify, or opt out of the collection of their data. +MAS-ATTACK-0084: Making profile details, activity status, or discoverability visible to other users or third parties by default. +MAS-ATTACK-0085: Collecting data under consent that is bundled, implied, or otherwise not freely and specifically given. +MAS-ATTACK-0086: Continuing to collect data under an outdated consent after practices have changed. +MAS-ATTACK-0087: Exporting or sharing data through flows whose privacy consequences are not evident to the user. +MAS-ATTACK-0088: Holding excessive or no-longer-needed permissions granted to the app. +MAS-ATTACK-0089: Inheriting the app's permissions in third-party SDKs, whose data collection is difficult to audit and control. diff --git a/.github/instructions/impact-attacks.yaml b/.github/instructions/impact-attacks.yaml deleted file mode 100644 index b6cc88f..0000000 --- a/.github/instructions/impact-attacks.yaml +++ /dev/null @@ -1,89 +0,0 @@ -- Obtaining the app package and reverse engineering it. -- Debugging the app at runtime. -- Using dynamic instrumentation. -- Attaching a remote inspector to the app's debuggable web content. -- Accessing the device storage on a compromised device. -- Accessing the system logs on a compromised device or from an app holding log-access permissions. -- Accessing files exposed through incorrect file permissions or misconfigured content providers. -- Extracting local or cloud backups of the device. -- Tampering with backup contents and restoring the modified backup to a device. -- Accessing shared or external storage from any app holding the corresponding permissions. -- Physically removing and reading external storage media such as SD cards. -- Monitoring network traffic on the same network (e.g., public Wi-Fi or a compromised router). -- Monitoring local or proximity interfaces such as Bluetooth, NFC, or USB. -- Performing a Machine-in-the-Middle (MITM) attack, e.g., via ARP poisoning, DNS spoofing, or a rogue access point. -- Presenting a fraudulent or otherwise invalid certificate that the app accepts. -- Obtaining a valid certificate for the target domain from a compromised, coerced, or rogue Certificate Authority (CA). -- Installing an attacker-controlled CA certificate on a device they control to inspect the app's traffic. -- Brute-forcing cryptographic material generated with insufficient length. -- Recovering or guessing the seed used by the generator to reproduce its output. -- Intercepting cryptographic keys exported in plaintext. -- Performing cryptanalysis of broken algorithms, modes, or parameters. -- Exploiting predictable or reused IVs or nonces to detect patterns or recover plaintext. -- Exploiting padding oracles exposed through observable error signals or timing differences. -- Observing enough outputs to recover the internal state of a non-cryptographic PRNG. -- Performing offline brute-force or dictionary attacks against keys derived from low-entropy inputs. -- Precomputing derived keys when salts are missing, hardcoded, or reused. -- Invoking keystore operations on a compromised or stolen device when key use does not require user authentication. -- Crafting collisions or second preimages for broken hash functions. -- Replaying previously captured valid messages or tags. -- Recovering private keys from predictable or reused signature nonces. -- Presenting data with invalid, stripped, or attacker-signed signatures that the app accepts. -- Using a victim's device with an active session (e.g., an unlocked or stolen device). -- Reusing stolen session tokens obtained through other attacks. -- Using a known, guessed, or shoulder-surfed device credential (PIN, pattern, or password). -- Enrolling additional biometrics on the device after obtaining the device credential. -- Displaying overlays or tampering with the UI to alter what the user sees while approving an action. -- Manipulating a compromised OS to alter or fabricate the confirmation flow. -- Invoking exported or unprotected app components from another app installed on the device. -- Connecting to open ports or local services exposed by the app. -- Patching or repackaging the app to remove or alter client-side checks. -- Reading sensitive data from the clipboard when users copy it between apps. -- Phishing credentials through lookalike apps or pages when users must type them manually. -- Observing the device screen while sensitive data is displayed or entered (shoulder surfing). -- Reading notification content shown on the lock screen without unlocking the device. -- Reading notification content from another app holding notification-access permissions. -- Registering the same custom URL scheme to intercept links intended for the app. -- Delivering crafted deep links or intents from a malicious app or web page. -- Capturing user input through a malicious custom keyboard or app extension. -- Registering intent filters to intercept implicit intents sent by the app. -- Modifying or replaying mutable PendingIntents obtained from the app. -- Injecting malicious JavaScript into WebView content (e.g., via MITM on insecure connections or a compromised website). -- Harvesting on-screen content through a malicious accessibility service the user was tricked into enabling. -- Targeting users who remain on an app version with publicly known vulnerabilities. -- Installing a malicious app on a device running an OS version affected by unpatched platform vulnerabilities. -- Running the app on a device whose OS version lacks the platform protections the app relies on. -- Accessing app data exposed by legacy compatibility behaviors that the platform still applies to apps targeting an old version. -- Substituting or modifying code that the app loads at runtime from writable or unverified locations. -- Identifying deprecated components in the app package and using publicly documented attacks against them. -- Supplying crafted input through any external interface (network, IPC, files, UI, or peripherals). -- Compromising a dependency, SDK, or build tool in the app's supply chain. -- Introducing malicious code through an insider or compromised developer account. -- Distributing tampered builds that cannot be distinguished from legitimate ones. -- Accessing a lost or stolen device that has no secure lock screen configured. -- Inspecting or modifying app traffic on a device they control after bypassing transport protections (e.g., pinning). -- Running the app on a rooted or jailbroken device they control. -- Running the app in an emulator or virtual device. -- Running the app inside an app-virtualization or cloning framework. -- Impersonating the app with scripts, bots, or tampered clients when interacting with the backend. -- Installing a repackaged version of the app on victim devices. -- Modifying the app's files or resources on a compromised device. -- Capturing or recording the screen from another app or an external tool. -- Accessing screenshots automatically taken by the system, e.g., when the app moves to the background. -- Identifying vulnerable dependency versions in the app package and using public advisories or exploits. -- Collecting and correlating identifiers and usage data across apps, devices, and services. -- Contacting undeclared tracking domains that platform enforcement cannot block. -- Handling credentials and browsing state inside the app instead of isolated system flows. -- Collecting non-resettable identifiers or misusing resettable ones. -- Linking directly identifiable data to real-world identities. -- Operating without a privacy policy or under a vague, generic, or inaccessible one. -- Deviating from the practices stated in the published privacy policy. -- Collecting or sharing data categories that are not declared in the platform's privacy labels. -- Transmitting undeclared identifiers or analytics data to first- or third-party services over the network. -- Providing no way for users to delete, export, modify, or opt out of the collection of their data. -- Making profile details, activity status, or discoverability visible to other users or third parties by default. -- Collecting data under consent that is bundled, implied, or otherwise not freely and specifically given. -- Continuing to collect data under an outdated consent after practices have changed. -- Exporting or sharing data through flows whose privacy consequences are not evident to the user. -- Holding excessive or no-longer-needed permissions granted to the app. -- Inheriting the app's permissions in third-party SDKs, whose data collection is difficult to audit and control. diff --git a/.github/instructions/impact-patterns.yaml b/.github/instructions/impact-patterns.yaml deleted file mode 100644 index c67ec94..0000000 --- a/.github/instructions/impact-patterns.yaml +++ /dev/null @@ -1,23 +0,0 @@ -- Attackers can extract [...] by -- Attackers can obtain [...] while they are in use by -- Attackers can access [...] by -- Attackers can extract or tamper with [...] by -- Attackers can intercept or modify [...] by -- Attackers can predict or reproduce [...] by -- Attackers can decrypt or forge [...] by -- Attackers can inspect and manipulate [...] by -- Attackers can exploit [...] by -- Attackers can use [...] without authorization by -- Attackers can forge or replay [...] by -- Attackers can present [...] as authentic by -- Attackers can obtain [...] by -- Attackers can perform [...] by -- Attackers can bypass [...] by -- Attackers can capture [...] by -- Attackers can hijack [...] by -- Attackers can invoke [...] by -- Attackers can execute [...] by -- Attackers can conceal [...] by -- Attackers can analyze [...] by -- Attackers can target [...] by -- Apps and embedded third-party components can [...] by diff --git a/.github/instructions/impact-labels.yaml b/.github/instructions/impact.yaml similarity index 100% rename from .github/instructions/impact-labels.yaml rename to .github/instructions/impact.yaml diff --git a/.github/instructions/index.md b/.github/instructions/index.md index 93207f8..c4208e8 100644 --- a/.github/instructions/index.md +++ b/.github/instructions/index.md @@ -9,10 +9,22 @@ The MASWE project includes specific requirements and formatting guidelines. Use The following writing guidelines are available. | File | Applies to | Purpose | -|------|-----------|---------| +| ---- | ---------- | ------- | | [markdown.instructions.md](markdown.instructions.md) | `**/*.md` | Shared writing style, cross-references, and LLM disclosure policy | | [maswe.instructions.md](maswe.instructions.md) | `weaknesses/**/*.md` | MASWE weakness file structure, front matter, sections, and template | +## Shared Vocabularies + +MASWE files reference these controlled vocabularies instead of restating their content. + +| File | Referenced from | Purpose | +| ---- | --------------- | ------- | +| [threats.yaml](threats.yaml) | `threat:` front matter | `MAS-THREAT-XXXX` outcomes attackers can achieve | +| [attacks.yaml](attacks.yaml) | `attacks:` front matter | `MAS-ATTACK-XXXX` paths through which a threat is realized | +| [impact.yaml](impact.yaml) | `## Impact` bullets | Canonical consequence labels (no IDs) | + +Entries in `threats.yaml` and `attacks.yaml` are append-only. Never reuse or renumber an existing ID. + ## Before You Start Before contributing content: diff --git a/.github/instructions/maswe.instructions.md b/.github/instructions/maswe.instructions.md index 088168c..6a22e4a 100644 --- a/.github/instructions/maswe.instructions.md +++ b/.github/instructions/maswe.instructions.md @@ -50,6 +50,8 @@ alias: " platform: [android, ios] profiles: [L1, L2] +threat: MAS-THREAT-XXXX +attacks: [MAS-ATTACK-XXXX, MAS-ATTACK-YYYY] mappings: masvs-v1: [MSTG--] masvs-v2: [MASVS--] @@ -72,6 +74,8 @@ Field rules: - **requirement**: A single sentence, in quotes, stating the positive security requirement that the app must fulfill (the inverse of the weakness). Example: `"The app encrypts all network traffic."` - **platform**: List of affected platforms. Use `[android, ios]` if the weakness applies to both. Use a single-item list if it is platform-specific (e.g. `[android]` for StrandHogg). - **profiles**: MAS Testing Profiles that the weakness is relevant for. Most weaknesses apply to `L1` and `L2`. Resilience weaknesses apply to `R` and Privacy to `P`. Use the current profile values defined in +- **threat**: Exactly one threat ID from `.github/instructions/threats.yaml`. The threat states the immediate outcome attackers (or, for privacy weaknesses, apps and third-party components) can achieve when the weakness is present. Each MASWE references exactly one threat. If no existing threat fits, add a new one at the end of `threats.yaml` with the next free `MAS-THREAT-XXXX` ID and reference it here. Never reuse or renumber an existing ID. +- **attacks**: List of attack IDs from `.github/instructions/attacks.yaml`, describing the paths through which the threat can be realized. List them in ascending ID order, e.g. `attacks: [MAS-ATTACK-0005, MAS-ATTACK-0006]`. At least one entry is required. If no existing attack fits, add a new one at the end of `attacks.yaml` with the next free `MAS-ATTACK-XXXX` ID and reuse it, rather than inventing per-weakness wording. Never reuse or renumber an existing ID. - **mappings**: Cross-references to related controls and weaknesses in other standards. At least one MASVS v2 control is required. Mappings to MASVS v1, CWE, and Android risks are optional but encouraged when applicable. - **masvs-v1**: One or more MSTG v1 controls that covered this topic. This helps identify content to port from MASTG v1. - **masvs-v2**: One or more MASVS v2 controls this weakness helps verify. At least one entry is required. Example: `masvs-v2: [MASVS-STORAGE-1]` which will be rendered as @@ -119,88 +123,65 @@ For example: ### `## Impact` -The Impact section describes what attackers can achieve, how they can achieve it, and the consequences that may follow. +What attackers can achieve and how they get there is **not** written in this section. It lives in the front matter. -Use these files. +- The immediate outcome is the `threat:` field, referencing `.github/instructions/threats.yaml`. +- The paths to that outcome are the `attacks:` field, referencing `.github/instructions/attacks.yaml`. -- `.github/instructions/impact-patterns.yaml`, reusable patterns for the opening sentence. -- `.github/instructions/impact-attacks.yaml`, reusable descriptions of attack paths. -- `.github/instructions/impact-labels.yaml`, canonical labels for consequences. +The `## Impact` section therefore contains **only** the consequences that follow, as a bulleted list. Do not add an opening sentence, do not repeat the threat or the attack paths, and do not add a `This can lead to:` line. -Reuse the same language and terms across MASWEs whenever the outcome, attack path, or consequence is equivalent. +Use `.github/instructions/impact.yaml` for the canonical consequence labels. Reuse the same language and terms across MASWEs whenever a consequence is equivalent. #### Structure -Start with the immediate outcome attackers can achieve, using a pattern from `impact-patterns.yaml`. - -```md -Attackers can [obtain, expose, modify, bypass, or disrupt something] by: -``` - -List all relevant attack paths, using wording from `impact-attacks.yaml` whenever applicable. - -```md -- [Attack path]. -- [Alternative attack path]. -``` - -Each attack path must. - -- Name a concrete attacker action or a precondition the attacker needs (installing an app, accessing storage, obtaining the package, running the app in a controlled environment), never restate the outcome already given in the opening sentence. The opening sentence says *what* attackers achieve; the bullets say *how* they get there. -- Be an action someone could observe or attempt, not a property of the app. "Leveraging legacy platform behaviors applied to apps targeting outdated platform versions" describes the weakness; "Accessing app data exposed by legacy compatibility behaviors that the platform still applies to apps targeting an old version" describes the attack. -- Reuse the opening sentence's verb only when the bullet adds a distinct actor, interface, or precondition. A bullet that repeats the opener's verb and its object ("Attackers can exploit flaws in non-standard security implementations by: - Exploiting flaws in custom or unproven security implementations.") is a restatement and must be rewritten or dropped. - -Do not repeat consequences for each attack path when they are the same. - -If no entry in `impact-attacks.yaml` fits, add one there in the same style and reuse it, rather than inventing per-weakness wording. - -Then add. - -```md -This can lead to: -``` - -List the consequences using this pattern. - ```md - **[Canonical Impact Label]**: [Concrete attacker action or consequence], resulting in [specific harm]. ``` Each consequence must. -- Use an exact label from `impact-labels.yaml`. -- Explain what attackers can do after achieving the stated outcome. +- Use an exact label from `impact.yaml`. +- Explain what attackers can do after achieving the outcome stated by the weakness's `threat:`. - Include a `resulting in` clause. - Be specific to the affected user, app, service, or organization. - Avoid unsupported, duplicate, or generic consequences. #### Example 1 -```md -Attackers can extract hardcoded secrets, credentials, and internal information by: +For a weakness with `threat: MAS-THREAT-0006` ("Attackers can extract hardcoded secrets, credentials, and internal information.") and `attacks: [MAS-ATTACK-0001]`: -- Obtaining the app package and reverse engineering it. - -This can lead to: +```md +## Impact -- **Financial Loss**: Attackers can abuse compromised API keys to make unauthorized billed API calls, resulting in unexpected charges to the app owner. -- **Compromise of System Integrity and Business Operations**: Attackers can use extracted credentials to access backend services, resulting in service disruption, account suspension, or denial of service. +- **Financial Loss**: Attackers can abuse compromised API keys to make unauthorized billed API calls (e.g., AI/ML services), resulting in unexpected charges to the app owner. +- **Compromise of System Integrity and Business Operations**: Attackers can use extracted credentials to access backend services, resulting in service disruption, policy-violation suspensions, or denial of service. ``` #### Example 2 +For a weakness with `threat: MAS-THREAT-0010` ("Attackers can use the app's cryptographic keys without authorization.") and `attacks: [MAS-ATTACK-0002, MAS-ATTACK-0003, MAS-ATTACK-0027]`: + ```md -Attackers can obtain cryptographic keys while they are in use by: +## Impact -- Using a debugger. -- Using dynamic instrumentation. -- Accessing the device storage on a compromised device. +- **Compromise of Sensitive Data**: Attackers can decrypt protected information or forge encrypted data without ever extracting the key, resulting in unauthorized disclosure or modification of sensitive data. +- **Authentication or Authorization Bypass**: Attackers can perform signing or authentication operations reserved for the legitimate user, resulting in unauthorized transactions or access to protected functionality. +``` -This can lead to: +### Writing threats and attacks -- **Compromise of Sensitive Data**: Attackers can decrypt protected information or forge encrypted data, resulting in unauthorized disclosure or modification of sensitive data. -- **Authentication or Authorization Bypass**: Attackers can create valid cryptographic values or impersonate trusted parties, resulting in unauthorized access to protected accounts, data, or functionality. -``` +New entries in `threats.yaml` and `attacks.yaml` are appended, never renumbered. Keep them reusable and platform-agnostic. + +A threat states _what_ the actor achieves, as a full sentence ending in a period. + +- Attacker-driven weaknesses: `Attackers can [obtain, expose, modify, bypass, or disrupt something].` +- Privacy weaknesses, where the app itself is the actor: `Apps and embedded third-party components can [collect, share, or track something].` + +An attack states _how_ they get there, as a gerund phrase ending in a period. Each attack must. + +- Name a concrete actor action or a precondition the actor needs (installing an app, accessing storage, obtaining the package, running the app in a controlled environment), never restate the outcome already given by the threat. The threat says _what_; the attack says _how_. +- Be an action someone could observe or attempt, not a property of the app. "Leveraging legacy platform behaviors applied to apps targeting outdated platform versions" describes the weakness; "Accessing app data exposed by legacy compatibility behaviors that the platform still applies to apps targeting an old version" describes the attack. +- Reuse the threat's verb only when the attack adds a distinct actor, interface, or precondition. An attack that repeats the threat's verb and its object (threat "Attackers can exploit flaws in non-standard security implementations." with attack "Exploiting flaws in custom or unproven security implementations.") is a restatement and must be rewritten or dropped. ### `## Mitigations` diff --git a/.github/instructions/threats.yaml b/.github/instructions/threats.yaml new file mode 100644 index 0000000..49acbf7 --- /dev/null +++ b/.github/instructions/threats.yaml @@ -0,0 +1,77 @@ +MAS-THREAT-0001: Attackers can access sensitive data written to logs. +MAS-THREAT-0002: Attackers can extract or tamper with sensitive data included in backups. +MAS-THREAT-0003: Attackers can access sensitive data stored unencrypted in private storage. +MAS-THREAT-0004: Attackers can access or tamper with sensitive data stored in shared or external storage. +MAS-THREAT-0005: Attackers can extract cryptographic keys stored outside the platform keystore. +MAS-THREAT-0006: Attackers can extract hardcoded secrets, credentials, and internal information. +MAS-THREAT-0007: Attackers can predict or reproduce improperly generated cryptographic keys. +MAS-THREAT-0008: Attackers can predict or reproduce improperly derived cryptographic keys. +MAS-THREAT-0009: Attackers can decrypt or forge all data ever protected with a compromised key. +MAS-THREAT-0010: Attackers can use the app's cryptographic keys without authorization. +MAS-THREAT-0011: Attackers can decrypt or forge improperly encrypted data. +MAS-THREAT-0012: Attackers can forge or replay data that passes hash-based integrity or authenticity checks. +MAS-THREAT-0013: Attackers can forge or replay messages that the app or its backend accepts as authentic. +MAS-THREAT-0014: Attackers can forge signatures or recover signing keys. +MAS-THREAT-0015: Attackers can present forged or tampered data as authentic. +MAS-THREAT-0016: Attackers can predict or reproduce random values used in security contexts. +MAS-THREAT-0017: Attackers can perform sensitive actions in a victim's authenticated session. +MAS-THREAT-0018: Attackers can access sensitive data or resume a session after it should have ended. +MAS-THREAT-0019: Attackers can obtain user approval for actions different from what the user intended. +MAS-THREAT-0020: Attackers can access sensitive data and functionality exposed by app components. +MAS-THREAT-0021: Attackers can bypass local authentication and access protected data or functionality. +MAS-THREAT-0022: Attackers can authenticate sensitive transactions without the user's biometrics. +MAS-THREAT-0023: Attackers can use biometric-protected keys without the legitimate user's biometrics. +MAS-THREAT-0024: Attackers can capture credentials that users handle manually. +MAS-THREAT-0025: Attackers can intercept or modify cleartext network traffic. +MAS-THREAT-0026: Attackers can intercept or modify TLS-protected network traffic. +MAS-THREAT-0027: Attackers can intercept or modify TLS-protected traffic even when standard certificate validation succeeds. +MAS-THREAT-0028: Attackers can capture sensitive data displayed or entered in the user interface. +MAS-THREAT-0029: Attackers can access sensitive data shown in notifications. +MAS-THREAT-0030: Attackers can access sensitive data displayed on the screen. +MAS-THREAT-0031: Attackers can hijack user interactions with the app. +MAS-THREAT-0032: Attackers can hijack deep links or inject malicious input into the app. +MAS-THREAT-0033: Attackers can capture sensitive data placed on the clipboard. +MAS-THREAT-0034: Attackers can capture sensitive user input and content. +MAS-THREAT-0035: Attackers can intercept or manipulate the app's intents. +MAS-THREAT-0036: Attackers can invoke exposed native functionality from web content. +MAS-THREAT-0037: Attackers can access local files and app-private data from web content. +MAS-THREAT-0038: Attackers can execute malicious web content inside the app's WebView. +MAS-THREAT-0039: Attackers can capture sensitive data displayed or entered in the app. +MAS-THREAT-0040: Attackers can exploit vulnerabilities that remain reachable in outdated app versions. +MAS-THREAT-0041: Attackers can exploit publicly known vulnerabilities in the app's dependencies. +MAS-THREAT-0042: Attackers can exploit platform-level weaknesses that the app cannot fix on its own. +MAS-THREAT-0043: Attackers can exploit the absence of modern platform protections. +MAS-THREAT-0044: Attackers can execute arbitrary code within the app's context. +MAS-THREAT-0045: Attackers can exploit memory-corruption bugs with substantially less effort. +MAS-THREAT-0046: Attackers can exploit weaknesses that maintained APIs have already addressed. +MAS-THREAT-0047: Attackers can exploit flaws in non-standard security implementations. +MAS-THREAT-0048: Attackers can execute injection attacks against the app. +MAS-THREAT-0049: Attackers can access sensitive data and functionality on unprotected devices. +MAS-THREAT-0050: Attackers can inspect and manipulate a debuggable app at runtime, even on non-rooted or non-jailbroken devices. +MAS-THREAT-0051: Attackers can analyze the app's logic and security controls with minimal effort. +MAS-THREAT-0052: Attackers can analyze the app's inner workings through its resources. +MAS-THREAT-0053: Attackers can undo the app's obfuscation with automated tooling. +MAS-THREAT-0054: Attackers can analyze the app's internals and disable its security controls. +MAS-THREAT-0055: Attackers can inspect and manipulate the app's API payloads. +MAS-THREAT-0056: Attackers can run and manipulate the app in a privileged environment without resistance. +MAS-THREAT-0057: Attackers can observe and manipulate the app from a hosting process. +MAS-THREAT-0058: Attackers can analyze and automate the app in a fully controlled environment. +MAS-THREAT-0059: Attackers can interact with the backend from untrusted environments. +MAS-THREAT-0060: Attackers can inspect and manipulate the running app without resistance. +MAS-THREAT-0061: Attackers can observe and modify the running app without resistance. +MAS-THREAT-0062: Attackers can distribute and run modified copies of the app. +MAS-THREAT-0063: Attackers can alter the app's behavior through its resources. +MAS-THREAT-0064: Attackers can modify the app's code while it runs. +MAS-THREAT-0065: Apps and embedded third-party components, as well as any party that later obtains the collected data, can identify and track users. +MAS-THREAT-0066: Apps and embedded third-party components can track users across apps, devices, and services. +MAS-THREAT-0067: Apps and embedded third-party components can collect, process, or share personal data in ways users cannot anticipate. +MAS-THREAT-0068: Apps and embedded third-party components can collect or share more data than users were led to expect. +MAS-THREAT-0069: Apps and their backend services can retain and process personal data beyond the user's control. +MAS-THREAT-0070: Apps and their users' counterparts can expose personal information beyond the user's intent. +MAS-THREAT-0071: Apps and embedded third-party components can process personal data without valid user consent. +MAS-THREAT-0072: Apps and embedded third-party components can access more sensitive device resources and data than needed. +MAS-THREAT-0073: Apps and embedded third-party components can track users against their expressed preferences. +MAS-THREAT-0074: Apps and embedded third-party components can access more user data than the feature requires. +MAS-THREAT-0075: Attackers can run malicious functionality inside the trusted app. +MAS-THREAT-0076: Attackers can target the app with malware running on the same device. +MAS-THREAT-0077: Attackers can conceal tampering with the app's released binaries. diff --git a/weaknesses/MASVS-AUTH/MASWE-0017.md b/weaknesses/MASVS-AUTH/MASWE-0017.md index 70674ce..f0c31b2 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0017.md +++ b/weaknesses/MASVS-AUTH/MASWE-0017.md @@ -5,6 +5,8 @@ alias: step-up-auth requirement: "The app enforces step-up authentication before granting access to sensitive functionality." platform: [android, ios] profiles: [L2] +threat: MAS-THREAT-0017 +attacks: [MAS-ATTACK-0032, MAS-ATTACK-0033] mappings: masvs-v1: [MSTG-AUTH-10] masvs-v2: [MASVS-AUTH-3, MASVS-PLATFORM-3] @@ -34,13 +36,6 @@ Step-up authentication requires the user to re-authenticate or provide an additi ## Impact -Attackers can perform sensitive actions in a victim's authenticated session by: - -- Using a victim's device with an active session (e.g., an unlocked or stolen device). -- Reusing stolen session tokens obtained through other attacks. - -This can lead to: - - **Financial Loss**: Attackers can initiate transfers or purchases in the victim's session, resulting in direct financial harm to the user. - **Compromise of Sensitive Data**: Attackers can view or export sensitive personal data available in the session, resulting in unauthorized disclosure of user information. - **Authentication or Authorization Bypass**: Attackers can change the account's credentials or security settings without any additional challenge, resulting in persistent account takeover. diff --git a/weaknesses/MASVS-AUTH/MASWE-0018.md b/weaknesses/MASVS-AUTH/MASWE-0018.md index 669e504..6bbdae6 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0018.md +++ b/weaknesses/MASVS-AUTH/MASWE-0018.md @@ -5,6 +5,8 @@ alias: reauth-state-changes requirement: "The app makes sensitive data inaccessible after session termination." platform: [android, ios] profiles: [L2] +threat: MAS-THREAT-0018 +attacks: [MAS-ATTACK-0005, MAS-ATTACK-0032, MAS-ATTACK-0033] mappings: masvs-v2: [MASVS-AUTH-3] cwe: [285, 287, 613] @@ -30,14 +32,6 @@ Session termination is not limited to the user tapping "log out": inactivity tim ## Impact -Attackers can access sensitive data or resume a session after it should have ended by: - -- Using a victim's device with an active session (e.g., an unlocked or stolen device). -- Reusing stolen session tokens obtained through other attacks. -- Accessing the device storage on a compromised device. - -This can lead to: - - **Authentication or Authorization Bypass**: Attackers can resume the victim's session and act as the user without authenticating, resulting in unauthorized access to the account and its functionality. - **Compromise of Sensitive Data**: Attackers can read cached or leftover personal data from a terminated session, resulting in unauthorized disclosure of user information. diff --git a/weaknesses/MASVS-AUTH/MASWE-0019.md b/weaknesses/MASVS-AUTH/MASWE-0019.md index 44055af..d3fd0f7 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0019.md +++ b/weaknesses/MASVS-AUTH/MASWE-0019.md @@ -5,6 +5,8 @@ alias: insecure-android-confirmation requirement: "The app ensures non-repudiation for critical actions." platform: [android, ios] profiles: [L2] +threat: MAS-THREAT-0019 +attacks: [MAS-ATTACK-0036, MAS-ATTACK-0037] mappings: masvs-v2: [MASVS-AUTH-3] cwe: [287, 778] @@ -31,13 +33,6 @@ Beyond the technical aspect, non-repudiation has a legal dimension: a signed, us ## Impact -Attackers can obtain user approval for actions different from what the user intended by: - -- Displaying overlays or tampering with the UI to alter what the user sees while approving an action. -- Manipulating a compromised OS to alter or fabricate the confirmation flow. - -This can lead to: - - **Financial Loss**: Attackers can trick users into approving altered payments or transactions, resulting in funds being transferred to attacker-controlled destinations. - **Compromise of System Integrity and Business Operations**: Users can plausibly repudiate transactions when the app owner holds no cryptographic proof of what was approved, resulting in disputes, chargebacks, and legal exposure for the app owner. diff --git a/weaknesses/MASVS-AUTH/MASWE-0020.md b/weaknesses/MASVS-AUTH/MASWE-0020.md index 0abba77..aedd867 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0020.md +++ b/weaknesses/MASVS-AUTH/MASWE-0020.md @@ -5,6 +5,8 @@ alias: missing-auth-app-components requirement: "The app enforces authentication and authorization on its components." platform: [android, ios] profiles: [L1, L2] +threat: MAS-THREAT-0020 +attacks: [MAS-ATTACK-0038, MAS-ATTACK-0039] mappings: masvs-v1: [MSTG-PLATFORM-4, MSTG-AUTH-3, MSTG-NETWORK-2, MSTG-STORAGE-6] masvs-v2: [MASVS-AUTH-1, MASVS-PLATFORM-1, MASVS-STORAGE-2] @@ -45,13 +47,6 @@ It covers any component reachable by other apps or processes without adequate ac ## Impact -Attackers can access sensitive data and functionality exposed by app components by: - -- Invoking exported or unprotected app components from another app installed on the device. -- Connecting to open ports or local services exposed by the app. - -This can lead to: - - **Compromise of Sensitive Data**: Attackers can query unprotected content providers or receive broadcast data, resulting in unauthorized disclosure of user or app data to other apps on the device. - **Authentication or Authorization Bypass**: Attackers can invoke privileged functionality, such as internal services or unvalidated token flows, without authenticating, resulting in actions being executed on behalf of the user. - **Bypass of Protection Mechanisms**: Attackers can launch internal activities directly, resulting in the circumvention of intended flows such as authentication screens or paywalls. diff --git a/weaknesses/MASVS-AUTH/MASWE-0021.md b/weaknesses/MASVS-AUTH/MASWE-0021.md index 397c5bb..575e36b 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0021.md +++ b/weaknesses/MASVS-AUTH/MASWE-0021.md @@ -5,6 +5,8 @@ alias: event-bound-biometric-auth requirement: "The app implements local authentication securely." platform: [android, ios] profiles: [L2] +threat: MAS-THREAT-0021 +attacks: [MAS-ATTACK-0002, MAS-ATTACK-0003, MAS-ATTACK-0027, MAS-ATTACK-0040] mappings: masvs-v1: [MSTG-AUTH-8, MSTG-AUTH-1, MSTG-AUTH-12] masvs-v2: [MASVS-AUTH-2, MASVS-CRYPTO-2] @@ -37,15 +39,6 @@ Local authentication is only as strong as what it unlocks. When the app merely r ## Impact -Attackers can bypass local authentication and access protected data or functionality by: - -- Using dynamic instrumentation. -- Debugging the app at runtime. -- Patching or repackaging the app to remove or alter client-side checks. -- Invoking keystore operations on a compromised or stolen device when key use does not require user authentication. - -This can lead to: - - **Authentication or Authorization Bypass**: Attackers can trigger the protected functionality without valid biometrics or credentials, resulting in unauthorized access to the user's account and sensitive operations. - **Compromise of Sensitive Data**: Attackers can retrieve data that was supposed to be gated by local authentication, resulting in unauthorized disclosure of sensitive user information. diff --git a/weaknesses/MASVS-AUTH/MASWE-0022.md b/weaknesses/MASVS-AUTH/MASWE-0022.md index af8f7b5..b3834e7 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0022.md +++ b/weaknesses/MASVS-AUTH/MASWE-0022.md @@ -5,6 +5,8 @@ alias: no-biometric-fallback requirement: "The app does not allow fallback to non-biometric credentials for sensitive transactions." platform: [android, ios] profiles: [L2] +threat: MAS-THREAT-0022 +attacks: [MAS-ATTACK-0034] mappings: masvs-v2: [MASVS-AUTH-2] cwe: [288, 287] @@ -31,12 +33,6 @@ Device credentials are typically short, reusable, and observable, so allowing th ## Impact -Attackers can authenticate sensitive transactions without the user's biometrics by: - -- Using a known, guessed, or shoulder-surfed device credential (PIN, pattern, or password). - -This can lead to: - - **Authentication or Authorization Bypass**: Attackers can complete authentication challenges intended to require the user's biometrics, resulting in unauthorized approval of sensitive operations. - **Financial Loss**: Attackers can authorize payments or transfers with a stolen device and its credential, resulting in direct financial harm to the user. diff --git a/weaknesses/MASVS-AUTH/MASWE-0023.md b/weaknesses/MASVS-AUTH/MASWE-0023.md index bb4bda1..0b9d47d 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0023.md +++ b/weaknesses/MASVS-AUTH/MASWE-0023.md @@ -5,6 +5,8 @@ alias: crypto-keys-biometric-enrollment requirement: "The app invalidates keys after any enrollment of new biometric data." platform: [android, ios] profiles: [L2] +threat: MAS-THREAT-0023 +attacks: [MAS-ATTACK-0035] mappings: masvs-v2: [MASVS-AUTH-2, MASVS-CRYPTO-2] cwe: [287, 522] @@ -29,12 +31,6 @@ Biometric-bound keys are meant to be usable only by the person whose biometrics ## Impact -Attackers can use biometric-protected keys without the legitimate user's biometrics by: - -- Enrolling additional biometrics on the device after obtaining the device credential. - -This can lead to: - - **Authentication or Authorization Bypass**: Attackers can pass biometric prompts with their own newly enrolled biometrics, resulting in unauthorized approval of operations bound to the victim's identity. - **Compromise of Sensitive Data**: Attackers can unlock data protected by biometric-bound keys, resulting in unauthorized disclosure of sensitive user information. diff --git a/weaknesses/MASVS-AUTH/MASWE-0024.md b/weaknesses/MASVS-AUTH/MASWE-0024.md index abc1848..1757a74 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0024.md +++ b/weaknesses/MASVS-AUTH/MASWE-0024.md @@ -5,6 +5,8 @@ alias: autofill-authenticators requirement: "The app enables auto-fill support for authenticators." platform: [android, ios] profiles: [L2] +threat: MAS-THREAT-0024 +attacks: [MAS-ATTACK-0041, MAS-ATTACK-0042] mappings: masvs-v1: [MSTG-AUTH-9] masvs-v2: [MASVS-AUTH-1, MASVS-AUTH-3] @@ -35,13 +37,6 @@ Platforms provide secure flows for supplying credentials, one-time codes, and pa ## Impact -Attackers can capture credentials that users handle manually by: - -- Reading sensitive data from the clipboard when users copy it between apps. -- Phishing credentials through lookalike apps or pages when users must type them manually. - -This can lead to: - - **Authentication or Authorization Bypass**: Attackers can reuse captured credentials or one-time codes, resulting in account takeover and unauthorized access to the user's data and functionality. - **Compromise of Sensitive Data**: Attackers can read credentials exposed through clipboard-based workarounds, resulting in disclosure of authentication material that protects sensitive information. diff --git a/weaknesses/MASVS-CODE/MASWE-0040.md b/weaknesses/MASVS-CODE/MASWE-0040.md index e24259e..d1d5f28 100644 --- a/weaknesses/MASVS-CODE/MASWE-0040.md +++ b/weaknesses/MASVS-CODE/MASWE-0040.md @@ -5,6 +5,8 @@ alias: enforced-updating requirement: "The app terminates if an outdated app version is detected." platform: [android, ios] profiles: [L2] +threat: MAS-THREAT-0040 +attacks: [MAS-ATTACK-0040, MAS-ATTACK-0053] mappings: masvs-v1: [MSTG-ARCH-9] masvs-v2: [MASVS-CODE-2] @@ -31,13 +33,6 @@ When a critical vulnerability is found in a production app, the developer needs ## Impact -Attackers can exploit vulnerabilities that remain reachable in outdated app versions by: - -- Targeting users who remain on an app version with publicly known vulnerabilities. -- Patching or repackaging the app to remove or alter client-side checks. - -This can lead to: - - **Compromise of Sensitive Data**: Attackers can exploit already-fixed vulnerabilities against users stuck on old versions, resulting in exposure of user data long after a patch was published. - **Compromise of System Integrity and Business Operations**: The app owner cannot retire vulnerable versions from the installed base, resulting in a prolonged attack window, extended incident response, and continued abuse of backend services. diff --git a/weaknesses/MASVS-CODE/MASWE-0041.md b/weaknesses/MASVS-CODE/MASWE-0041.md index 0b3049a..e1a22ec 100644 --- a/weaknesses/MASVS-CODE/MASWE-0041.md +++ b/weaknesses/MASVS-CODE/MASWE-0041.md @@ -5,6 +5,8 @@ alias: dependencies-with-known-vulnerabilities requirement: "The app's third-party components are regularly checked for known vulnerabilities." platform: [android, ios] profiles: [L1, L2] +threat: MAS-THREAT-0041 +attacks: [MAS-ATTACK-0073] mappings: masvs-v1: [MSTG-CODE-5] masvs-v2: [MASVS-CODE-3] @@ -66,12 +68,6 @@ For more information on privacy and data collection declarations, see @MASWE-006 ## Impact -Attackers can exploit publicly known vulnerabilities in the app's dependencies by: - -- Identifying vulnerable dependency versions in the app package and using public advisories or exploits. - -This can lead to: - - **Compromise of Sensitive Data**: Attackers can exploit vulnerable components to bypass access controls or cryptographic protections and expose credentials, session tokens, or personally identifiable information (PII), resulting in data breaches with legal, financial, and reputational consequences for the app owner. - **Execution of Unauthorized Code**: Attackers can exploit vulnerabilities in embedded dependencies to execute arbitrary code within the app's context (e.g., through code injection), escalate privileges, or manipulate app behavior, resulting in compromised user accounts, abuse of backend services, or persistent access to protected resources. - **Legal and Regulatory Non-Compliance**: Shipping dependencies with publicly known CVEs can violate regulatory requirements (e.g., GDPR, HIPAA, PCI-DSS) or platform security policies (e.g., Google Play or App Store guidelines), resulting in app rejection, fines, or mandatory disclosures for the app owner. diff --git a/weaknesses/MASVS-CODE/MASWE-0042.md b/weaknesses/MASVS-CODE/MASWE-0042.md index 9999eb6..c1d032a 100644 --- a/weaknesses/MASVS-CODE/MASWE-0042.md +++ b/weaknesses/MASVS-CODE/MASWE-0042.md @@ -5,6 +5,8 @@ alias: run-on-recent-platform-version requirement: "The app terminates if an unsupported OS version is detected." platform: [android, ios] profiles: [L2] +threat: MAS-THREAT-0042 +attacks: [MAS-ATTACK-0054, MAS-ATTACK-0055] mappings: masvs-v2: [MASVS-CODE-1] cwe: [451, 693, 1104, 1357] @@ -30,13 +32,6 @@ Ensuring a recent minimum platform version guarantees the availability of securi ## Impact -Attackers can exploit platform-level weaknesses that the app cannot fix on its own by: - -- Installing a malicious app on a device running an OS version affected by unpatched platform vulnerabilities. -- Running the app on a device whose OS version lacks the platform protections the app relies on. - -This can lead to: - - **Compromise of Sensitive Data**: Attackers can leverage missing platform protections or unpatched OS vulnerabilities to reach the app's data, resulting in exposure of user data on outdated devices. - **Authentication or Authorization Bypass**: Attackers can abuse platform flaws such as task hijacking to phish credentials from the app's users on affected versions, resulting in account takeover. diff --git a/weaknesses/MASVS-CODE/MASWE-0043.md b/weaknesses/MASVS-CODE/MASWE-0043.md index 124ce18..ed08cf2 100644 --- a/weaknesses/MASVS-CODE/MASWE-0043.md +++ b/weaknesses/MASVS-CODE/MASWE-0043.md @@ -5,6 +5,8 @@ alias: target-latest-platform-version requirement: "The app targets a recent OS version." platform: [android, ios] profiles: [L2] +threat: MAS-THREAT-0043 +attacks: [MAS-ATTACK-0056] mappings: masvs-v2: [MASVS-CODE-1] cwe: [693, 1357] @@ -29,12 +31,6 @@ Targeting the latest platform version, via `targetSdkVersion` on Android or by b ## Impact -Attackers can exploit the absence of modern platform protections by: - -- Accessing app data exposed by legacy compatibility behaviors that the platform still applies to apps targeting an old version. - -This can lead to: - - **Compromise of Sensitive Data**: Attackers can take advantage of legacy behaviors, such as broader file-system or permission access, resulting in exposure of user data that current platform defaults would have protected. - **Compromise of System Integrity and Business Operations**: The app can fall below app-store target-version requirements, resulting in blocked updates or removal from distribution for the app owner. diff --git a/weaknesses/MASVS-CODE/MASWE-0044.md b/weaknesses/MASVS-CODE/MASWE-0044.md index e9fd154..bfbed0c 100644 --- a/weaknesses/MASVS-CODE/MASWE-0044.md +++ b/weaknesses/MASVS-CODE/MASWE-0044.md @@ -5,6 +5,8 @@ alias: unsafe-code-loading requirement: "The app loads dynamic code safely from trusted sources." platform: [android, ios] profiles: [L2] +threat: MAS-THREAT-0044 +attacks: [MAS-ATTACK-0014, MAS-ATTACK-0057] mappings: masvs-v2: [MASVS-CODE-4] cwe: [494] @@ -32,13 +34,6 @@ Dynamic code loading includes loading native libraries via `dlopen`, loading DEX ## Impact -Attackers can execute arbitrary code within the app's context by: - -- Substituting or modifying code that the app loads at runtime from writable or unverified locations. -- Performing a Machine-in-the-Middle (MITM) attack, e.g., via ARP poisoning, DNS spoofing, or a rogue access point. - -This can lead to: - - **Execution of Unauthorized Code**: Attackers can run attacker-controlled code with the app's identity, permissions, and data access, resulting in full compromise of the app's functionality on the device. - **Compromise of Sensitive Data**: Attackers can use the injected code to read the app's private data and credentials, resulting in unauthorized disclosure of user and app data. diff --git a/weaknesses/MASVS-CODE/MASWE-0045.md b/weaknesses/MASVS-CODE/MASWE-0045.md index f10c343..e985a33 100644 --- a/weaknesses/MASVS-CODE/MASWE-0045.md +++ b/weaknesses/MASVS-CODE/MASWE-0045.md @@ -5,6 +5,8 @@ alias: compiler-provided-security-features-not-implemented requirement: "The app uses the compiler-provided security features of the platform." platform: [android, ios] profiles: [L2] +threat: MAS-THREAT-0045 +attacks: [MAS-ATTACK-0001, MAS-ATTACK-0059] mappings: masvs-v2: [MASVS-CODE-3, MASVS-CODE-4] cwe: [693] @@ -33,13 +35,6 @@ Mitigations such as stack canaries (stack-smashing protection), Address Space La ## Impact -Attackers can exploit memory-corruption bugs with substantially less effort by: - -- Obtaining the app package and reverse engineering it. -- Supplying crafted input through any external interface (network, IPC, files, UI, or peripherals). - -This can lead to: - - **Execution of Unauthorized Code**: Attackers can convert memory-corruption bugs into reliable code execution in the app's context, resulting in full compromise of the app and its data. - **Compromise of Sensitive Data**: Attackers can read process memory through exploited native bugs, resulting in exposure of credentials, keys, and user data held in memory. diff --git a/weaknesses/MASVS-CODE/MASWE-0046.md b/weaknesses/MASVS-CODE/MASWE-0046.md index c2eda9e..0848f0b 100644 --- a/weaknesses/MASVS-CODE/MASWE-0046.md +++ b/weaknesses/MASVS-CODE/MASWE-0046.md @@ -5,6 +5,8 @@ alias: deprecated-apis requirement: "The app does not use deprecated APIs or functionality." platform: [android, ios] profiles: [L2] +threat: MAS-THREAT-0046 +attacks: [MAS-ATTACK-0058] mappings: masvs-v1: [MSTG-CRYPTO-4] masvs-v2: [MASVS-CODE-3, MASVS-CRYPTO-2] @@ -31,12 +33,6 @@ Platforms deprecate APIs precisely because better-designed replacements exist, o ## Impact -Attackers can exploit weaknesses that maintained APIs have already addressed by: - -- Identifying deprecated components in the app package and using publicly documented attacks against them. - -This can lead to: - - **Compromise of Sensitive Data**: Attackers can exploit the known shortcomings of deprecated implementations, resulting in exposure of data those APIs were supposed to protect. - **Authentication or Authorization Bypass**: Attackers can abuse weaknesses in deprecated authentication- or keystore-related APIs, resulting in unauthorized access to protected keys or functionality. diff --git a/weaknesses/MASVS-CODE/MASWE-0047.md b/weaknesses/MASVS-CODE/MASWE-0047.md index 3d83781..551557f 100644 --- a/weaknesses/MASVS-CODE/MASWE-0047.md +++ b/weaknesses/MASVS-CODE/MASWE-0047.md @@ -5,6 +5,8 @@ alias: non-standard-security-apis requirement: "The app does not use non-standard APIs for security-critical functionality." platform: [android, ios] profiles: [L2] +threat: MAS-THREAT-0047 +attacks: [MAS-ATTACK-0001, MAS-ATTACK-0014, MAS-ATTACK-0021] mappings: masvs-v1: [MSTG-CRYPTO-2, MSTG-NETWORK-6] masvs-v2: [MASVS-CODE-3, MASVS-AUTH-1, MASVS-CRYPTO-1, MASVS-NETWORK-1] @@ -37,14 +39,6 @@ Platform APIs and vetted libraries are designed and maintained by experts, incor ## Impact -Attackers can exploit flaws in non-standard security implementations by: - -- Obtaining the app package and reverse engineering it. -- Performing cryptanalysis of broken algorithms, modes, or parameters. -- Performing a Machine-in-the-Middle (MITM) attack, e.g., via ARP poisoning, DNS spoofing, or a rogue access point. - -This can lead to: - - **Compromise of Sensitive Data**: Attackers can break weak custom cryptography or intercept traffic handled by flawed custom stacks, resulting in unauthorized disclosure or modification of sensitive data. - **Authentication or Authorization Bypass**: Attackers can exploit logic flaws in custom authentication implementations, resulting in unauthorized access to user accounts and protected functionality. diff --git a/weaknesses/MASVS-CODE/MASWE-0048.md b/weaknesses/MASVS-CODE/MASWE-0048.md index 5085923..dd30fb4 100644 --- a/weaknesses/MASVS-CODE/MASWE-0048.md +++ b/weaknesses/MASVS-CODE/MASWE-0048.md @@ -5,6 +5,8 @@ alias: unsafe-untrusted-data requirement: "The app securely handles untrusted data." platform: [android, ios] profiles: [L1, L2] +threat: MAS-THREAT-0048 +attacks: [MAS-ATTACK-0047, MAS-ATTACK-0059] mappings: masvs-v1: [MSTG-PLATFORM-2] masvs-v2: [MASVS-CODE-4] @@ -43,13 +45,6 @@ Untrusted data is any data the app did not create itself, regardless of how it a ## Impact -Attackers can execute injection attacks against the app by: - -- Supplying crafted input through any external interface (network, IPC, files, UI, or peripherals). -- Delivering crafted deep links or intents from a malicious app or web page. - -This can lead to: - - **Compromise of Sensitive Data**: Attackers can extract or overwrite private files and database contents through path traversal, SQL injection, or XXE, resulting in unauthorized disclosure or modification of user and app data. - **Execution of Unauthorized Code**: Attackers can exploit insecure deserialization or memory corruption in parsers, resulting in attacker-controlled code running in the app's context. - **Authentication or Authorization Bypass**: Attackers can manipulate queries or logic through injected input, resulting in access to data or functionality beyond what the caller is authorized for. diff --git a/weaknesses/MASVS-CODE/MASWE-0075.md b/weaknesses/MASVS-CODE/MASWE-0075.md index eb60d05..3ff3f3e 100644 --- a/weaknesses/MASVS-CODE/MASWE-0075.md +++ b/weaknesses/MASVS-CODE/MASWE-0075.md @@ -5,6 +5,8 @@ alias: malicious-code-included requirement: "The app package does not contain malicious code." platform: [android, ios] profiles: [L2] +threat: MAS-THREAT-0075 +attacks: [MAS-ATTACK-0060, MAS-ATTACK-0061] mappings: masvs-v2: [MASVS-CODE-3] cwe: [506, 507, 511] @@ -30,13 +32,6 @@ Malicious code can exfiltrate data, execute hidden or backdoored functionality, ## Impact -Attackers can run malicious functionality inside the trusted app by: - -- Compromising a dependency, SDK, or build tool in the app's supply chain. -- Introducing malicious code through an insider or compromised developer account. - -This can lead to: - - **Compromise of Sensitive Data**: Attackers can exfiltrate user data and credentials from inside the app's trust boundary, resulting in large-scale disclosure across the entire user base. - **Execution of Unauthorized Code**: Attackers can trigger backdoored or hidden functionality at will, resulting in attacker-controlled behavior running with the app's identity and permissions. - **Compromise of System Integrity and Business Operations**: The app owner distributes malware to their own users, resulting in app-store removal, incident response costs, and severe reputational damage. diff --git a/weaknesses/MASVS-CODE/MASWE-0077.md b/weaknesses/MASVS-CODE/MASWE-0077.md index ff73893..3d9d7b1 100644 --- a/weaknesses/MASVS-CODE/MASWE-0077.md +++ b/weaknesses/MASVS-CODE/MASWE-0077.md @@ -5,6 +5,8 @@ alias: non-reproducible-builds requirement: "The app offers reproducible builds." platform: [android, ios] profiles: [L2] +threat: MAS-THREAT-0077 +attacks: [MAS-ATTACK-0060, MAS-ATTACK-0062] mappings: masvs-v2: [MASVS-CODE-3] cwe: [1357, 494] @@ -29,13 +31,6 @@ Reproducible builds allow third parties, and the developers themselves, to detec ## Impact -Attackers can conceal tampering with the app's released binaries by: - -- Distributing tampered builds that cannot be distinguished from legitimate ones. -- Compromising a dependency, SDK, or build tool in the app's supply chain. - -This can lead to: - - **Execution of Unauthorized Code**: Attackers can inject code during the build or distribution process without detection, since no independent party can verify the binary against the source, resulting in malicious code shipping to the entire user base. - **Loss of User Trust**: Users and auditors cannot verify that the shipped app matches the published source, resulting in weakened trust in the app, particularly for security- and privacy-sensitive apps. diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0007.md b/weaknesses/MASVS-CRYPTO/MASWE-0007.md index 306f167..f2f17d8 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0007.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0007.md @@ -5,6 +5,8 @@ alias: weak-crypto-key-generation requirement: "The app securely generates cryptographic keys." platform: [android, ios] profiles: [L1, L2] +threat: MAS-THREAT-0007 +attacks: [MAS-ATTACK-0018, MAS-ATTACK-0019, MAS-ATTACK-0020] mappings: masvs-v1: [MSTG-CRYPTO-2] masvs-v2: [MASVS-CRYPTO-2] @@ -39,14 +41,6 @@ In cryptography, security strength is heavily influenced by how keys are generat ## Impact -Attackers can predict or reproduce improperly generated cryptographic keys by: - -- Brute-forcing cryptographic material generated with insufficient length. -- Recovering or guessing the seed used by the generator to reproduce its output. -- Intercepting cryptographic keys exported in plaintext. - -This can lead to: - - **Compromise of Sensitive Data**: Attackers can decrypt protected information or forge encrypted data, resulting in unauthorized disclosure or modification of sensitive data. - **Authentication or Authorization Bypass**: Attackers can create valid cryptographic values or impersonate trusted parties, resulting in unauthorized access to protected accounts, data, or functionality. diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0008.md b/weaknesses/MASVS-CRYPTO/MASWE-0008.md index 355c6e6..3a64935 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0008.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0008.md @@ -5,6 +5,8 @@ alias: weak-crypto-key-derivation requirement: "The app derives cryptographic keys using approved key derivation functions." platform: [android, ios] profiles: [L1, L2] +threat: MAS-THREAT-0008 +attacks: [MAS-ATTACK-0025, MAS-ATTACK-0026] mappings: masvs-v1: [MSTG-CRYPTO-2] masvs-v2: [MASVS-CRYPTO-2] @@ -32,13 +34,6 @@ Dedicated password-based KDFs, such as PBKDF2, scrypt, or Argon2, are deliberate ## Impact -Attackers can predict or reproduce improperly derived cryptographic keys by: - -- Performing offline brute-force or dictionary attacks against keys derived from low-entropy inputs. -- Precomputing derived keys when salts are missing, hardcoded, or reused. - -This can lead to: - - **Compromise of Sensitive Data**: Attackers can decrypt protected information or forge encrypted data, resulting in unauthorized disclosure or modification of sensitive data. - **Authentication or Authorization Bypass**: Attackers can recover passwords or derived credentials, resulting in unauthorized access to protected accounts, data, or functionality. diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0009.md b/weaknesses/MASVS-CRYPTO/MASWE-0009.md index ed4aff3..623a39d 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0009.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0009.md @@ -5,6 +5,8 @@ alias: no-key-rotation requirement: "The app rotates cryptographic keys regularly." platform: [android, ios] profiles: [L2] +threat: MAS-THREAT-0009 +attacks: [MAS-ATTACK-0001, MAS-ATTACK-0005] mappings: masvs-v2: [MASVS-CRYPTO-2] cwe: [262, 324] @@ -29,13 +31,6 @@ Cryptographic keys have a limited cryptoperiod, as defined in [NIST.SP.800-57pt1 ## Impact -Attackers can decrypt or forge all data ever protected with a compromised key by: - -- Obtaining the app package and reverse engineering it. -- Accessing the device storage on a compromised device. - -This can lead to: - - **Compromise of Sensitive Data**: Attackers can decrypt the entire history of data protected with the compromised key, resulting in a much larger disclosure than a rotation-bounded compromise would allow. - **Authentication or Authorization Bypass**: Attackers can keep forging valid cryptographic values indefinitely with a long-lived compromised key, resulting in persistent unauthorized access that is not curtailed by key expiry. diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0010.md b/weaknesses/MASVS-CRYPTO/MASWE-0010.md index e8a3351..d728dac 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0010.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0010.md @@ -5,6 +5,8 @@ alias: crypto-key-access-not-restricted requirement: "The app restricts access to cryptographic keys." platform: [android, ios] profiles: [L2] +threat: MAS-THREAT-0010 +attacks: [MAS-ATTACK-0002, MAS-ATTACK-0003, MAS-ATTACK-0027] mappings: masvs-v2: [MASVS-CRYPTO-2, MASVS-AUTH-2, MASVS-AUTH-3] cwe: [284] @@ -35,14 +37,6 @@ Platform keystores allow developers to bind key usage to strict conditions, such ## Impact -Attackers can use the app's cryptographic keys without authorization by: - -- Invoking keystore operations on a compromised or stolen device when key use does not require user authentication. -- Using dynamic instrumentation. -- Debugging the app at runtime. - -This can lead to: - - **Compromise of Sensitive Data**: Attackers can decrypt protected information or forge encrypted data without ever extracting the key, resulting in unauthorized disclosure or modification of sensitive data. - **Authentication or Authorization Bypass**: Attackers can perform signing or authentication operations reserved for the legitimate user, resulting in unauthorized transactions or access to protected functionality. diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0011.md b/weaknesses/MASVS-CRYPTO/MASWE-0011.md index 2be38ab..58fe581 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0011.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0011.md @@ -5,6 +5,8 @@ alias: weak-encryption requirement: "The app properly encrypts sensitive data." platform: [android, ios] profiles: [L1, L2] +threat: MAS-THREAT-0011 +attacks: [MAS-ATTACK-0018, MAS-ATTACK-0021, MAS-ATTACK-0022, MAS-ATTACK-0023] mappings: masvs-v1: [MSTG-CRYPTO-4, MSTG-CRYPTO-5] masvs-v2: [MASVS-CRYPTO-1, MASVS-CRYPTO-2] @@ -42,15 +44,6 @@ Encryption is only as strong as its weakest component: the algorithm, the mode o ## Impact -Attackers can decrypt or forge improperly encrypted data by: - -- Performing cryptanalysis of broken algorithms, modes, or parameters. -- Exploiting predictable or reused IVs or nonces to detect patterns or recover plaintext. -- Exploiting padding oracles exposed through observable error signals or timing differences. -- Brute-forcing cryptographic material generated with insufficient length. - -This can lead to: - - **Compromise of Sensitive Data**: Attackers can decipher protected information or alter it without detection, resulting in unauthorized disclosure or manipulation of sensitive data. - **Authentication or Authorization Bypass**: Attackers can forge ciphertexts, tokens, or signatures accepted by the app or its backend, resulting in unauthorized access to protected accounts, data, or functionality. diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0012.md b/weaknesses/MASVS-CRYPTO/MASWE-0012.md index 935671a..aeade09 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0012.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0012.md @@ -5,6 +5,8 @@ alias: improper-hashing requirement: "The app properly hashes sensitive data." platform: [android, ios] profiles: [L1, L2] +threat: MAS-THREAT-0012 +attacks: [MAS-ATTACK-0028] mappings: masvs-v1: [MSTG-CRYPTO-4] masvs-v2: [MASVS-CRYPTO-1] @@ -33,12 +35,6 @@ Broken algorithms such as MD5 and SHA-1 are vulnerable to collision attacks and ## Impact -Attackers can forge or replay data that passes hash-based integrity or authenticity checks by: - -- Crafting collisions or second preimages for broken hash functions. - -This can lead to: - - **Compromise of Sensitive Data**: Attackers can substitute or modify data without invalidating its hash, resulting in undetected manipulation of sensitive information. - **Authentication or Authorization Bypass**: Attackers can forge artifacts whose authenticity is established via hashes, such as signed payloads or fingerprinted certificates, resulting in impersonation or unauthorized access. diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0013.md b/weaknesses/MASVS-CRYPTO/MASWE-0013.md index 5b5c2a7..faa4b4e 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0013.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0013.md @@ -5,6 +5,8 @@ alias: improper-mac requirement: "The app properly uses Message Authentication Codes (MACs)." platform: [android, ios] profiles: [L1, L2] +threat: MAS-THREAT-0013 +attacks: [MAS-ATTACK-0018, MAS-ATTACK-0021, MAS-ATTACK-0029] mappings: masvs-v1: [MSTG-CRYPTO-4, MSTG-CRYPTO-5] masvs-v2: [MASVS-CRYPTO-1, MASVS-CRYPTO-2] @@ -38,14 +40,6 @@ A MAC provides integrity and authenticity for a message using a shared secret ke ## Impact -Attackers can forge or replay messages that the app or its backend accepts as authentic by: - -- Replaying previously captured valid messages or tags. -- Performing cryptanalysis of broken algorithms, modes, or parameters. -- Brute-forcing cryptographic material generated with insufficient length. - -This can lead to: - - **Compromise of Sensitive Data**: Attackers can modify protected messages or stored data without detection, resulting in undetected manipulation of sensitive information. - **Authentication or Authorization Bypass**: Attackers can forge or replay authenticated messages, such as commands or transactions, resulting in unauthorized actions being executed on behalf of the user. diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0014.md b/weaknesses/MASVS-CRYPTO/MASWE-0014.md index 6b54a70..cb03cde 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0014.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0014.md @@ -5,6 +5,8 @@ alias: improper-signature-generation requirement: "The app properly generates cryptographic signatures." platform: [android, ios] profiles: [L1, L2] +threat: MAS-THREAT-0014 +attacks: [MAS-ATTACK-0018, MAS-ATTACK-0021, MAS-ATTACK-0030] mappings: masvs-v1: [MSTG-CRYPTO-4, MSTG-CRYPTO-5] masvs-v2: [MASVS-CRYPTO-1, MASVS-CRYPTO-2] @@ -33,14 +35,6 @@ Signatures are only as strong as the scheme and parameters behind them: deprecat ## Impact -Attackers can forge signatures or recover signing keys by: - -- Recovering private keys from predictable or reused signature nonces. -- Performing cryptanalysis of broken algorithms, modes, or parameters. -- Brute-forcing cryptographic material generated with insufficient length. - -This can lead to: - - **Authentication or Authorization Bypass**: Attackers can sign arbitrary data as the app or user, resulting in impersonation and unauthorized transactions or API calls accepted by peers that trust the signature. - **Compromise of Sensitive Data**: Attackers can tamper with signed data while producing valid signatures for it, resulting in undetected manipulation of information whose integrity depends on the signature. diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0015.md b/weaknesses/MASVS-CRYPTO/MASWE-0015.md index 50c6336..5156ed4 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0015.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0015.md @@ -5,6 +5,8 @@ alias: improper-signature-verification requirement: "The app properly verifies cryptographic signatures." platform: [android, ios] profiles: [L1, L2] +threat: MAS-THREAT-0015 +attacks: [MAS-ATTACK-0031] mappings: masvs-v1: [MSTG-CRYPTO-4] masvs-v2: [MASVS-CRYPTO-1] @@ -30,12 +32,6 @@ Signature verification protects the integrity and authenticity of data such as u ## Impact -Attackers can present forged or tampered data as authentic by: - -- Presenting data with invalid, stripped, or attacker-signed signatures that the app accepts. - -This can lead to: - - **Execution of Unauthorized Code**: Attackers can deliver tampered updates, plugins, or configuration that the app accepts as genuine, resulting in attacker-controlled code or behavior running within the app. - **Authentication or Authorization Bypass**: Attackers can forge signed tokens or assertions (e.g. session or license tokens), resulting in unauthorized access to protected accounts, data, or functionality. - **Compromise of Sensitive Data**: Attackers can substitute tampered data for authentic data without detection, resulting in the app processing or displaying manipulated information. diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0016.md b/weaknesses/MASVS-CRYPTO/MASWE-0016.md index 5e4969a..345ccfb 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0016.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0016.md @@ -5,6 +5,8 @@ alias: improper-random-number-generation requirement: "The app properly generates random numbers." platform: [android, ios] profiles: [L1, L2] +threat: MAS-THREAT-0016 +attacks: [MAS-ATTACK-0001, MAS-ATTACK-0019, MAS-ATTACK-0024] mappings: masvs-v1: [MSTG-CRYPTO-6] masvs-v2: [MASVS-CRYPTO-1] @@ -33,14 +35,6 @@ A [PRNG](https://en.wikipedia.org/wiki/Pseudorandom_number_generator) generates ## Impact -Attackers can predict or reproduce random values used in security contexts by: - -- Observing enough outputs to recover the internal state of a non-cryptographic PRNG. -- Recovering or guessing the seed used by the generator to reproduce its output. -- Obtaining the app package and reverse engineering it. - -This can lead to: - - **Authentication or Authorization Bypass**: Attackers can predict session tokens, one-time passwords, or password-reset codes, resulting in unauthorized access to user accounts or privileged functionality. - **Compromise of Sensitive Data**: Attackers can reproduce cryptographic material derived from predictable values and decrypt protected information, resulting in unauthorized disclosure of sensitive data. diff --git a/weaknesses/MASVS-NETWORK/MASWE-0025.md b/weaknesses/MASVS-NETWORK/MASWE-0025.md index 4623eed..db75773 100644 --- a/weaknesses/MASVS-NETWORK/MASWE-0025.md +++ b/weaknesses/MASVS-NETWORK/MASWE-0025.md @@ -5,6 +5,8 @@ alias: cleartext-traffic requirement: "The app encrypts all network traffic." platform: [android, ios] profiles: [L1, L2] +threat: MAS-THREAT-0025 +attacks: [MAS-ATTACK-0012, MAS-ATTACK-0013, MAS-ATTACK-0014] mappings: masvs-v1: [MSTG-NETWORK-2, MSTG-NETWORK-1] masvs-v2: [MASVS-NETWORK-1] @@ -55,14 +57,6 @@ Secure network protocols not only provide confidentiality but also ensure data i ## Impact -Attackers can intercept or modify cleartext network traffic by: - -- Monitoring network traffic on the same network (e.g., public Wi-Fi or a compromised router). -- Performing a Machine-in-the-Middle (MITM) attack, e.g., via ARP poisoning, DNS spoofing, or a rogue access point. -- Monitoring local or proximity interfaces such as Bluetooth, NFC, or USB. - -This can lead to: - - **Compromise of Sensitive Data**: Attackers can capture, read, or alter sensitive information transmitted over the network, resulting in unauthorized disclosure or manipulation of user data. - **Authentication or Authorization Bypass**: Attackers can capture session tokens or credentials sent over cleartext channels, resulting in user impersonation and unauthorized access to accounts or backend systems. - **Compromise of System Integrity and Business Operations**: Attackers can inject malicious content or redirect users to impersonated services, resulting in altered app behavior, phishing, and reputational damage for the app owner. diff --git a/weaknesses/MASVS-NETWORK/MASWE-0026.md b/weaknesses/MASVS-NETWORK/MASWE-0026.md index 024efd1..119461a 100644 --- a/weaknesses/MASVS-NETWORK/MASWE-0026.md +++ b/weaknesses/MASVS-NETWORK/MASWE-0026.md @@ -5,6 +5,8 @@ alias: insecure-cert-val requirement: "The app validates certificates for all network traffic." platform: [android, ios] profiles: [L1, L2] +threat: MAS-THREAT-0026 +attacks: [MAS-ATTACK-0014, MAS-ATTACK-0015] mappings: masvs-v1: [MSTG-NETWORK-3] masvs-v2: [MASVS-NETWORK-1] @@ -45,13 +47,6 @@ Certificate validation is the mechanism through which a TLS client establishes t ## Impact -Attackers can intercept or modify TLS-protected network traffic by: - -- Performing a Machine-in-the-Middle (MITM) attack, e.g., via ARP poisoning, DNS spoofing, or a rogue access point. -- Presenting a fraudulent or otherwise invalid certificate that the app accepts. - -This can lead to: - - **Compromise of Sensitive Data**: Attackers can capture, read, or alter sensitive information transmitted over the network, resulting in unauthorized disclosure or manipulation of user data. - **Authentication or Authorization Bypass**: Attackers can capture credentials or session tokens in transit, resulting in user impersonation and unauthorized access to accounts or backend systems. - **Compromise of System Integrity and Business Operations**: Attackers can impersonate legitimate servers and feed altered or malicious data to the app, resulting in unreliable or malicious app behavior and reputational damage for the app owner. diff --git a/weaknesses/MASVS-NETWORK/MASWE-0027.md b/weaknesses/MASVS-NETWORK/MASWE-0027.md index 724f9b5..71f3a84 100644 --- a/weaknesses/MASVS-NETWORK/MASWE-0027.md +++ b/weaknesses/MASVS-NETWORK/MASWE-0027.md @@ -5,6 +5,8 @@ alias: insecure-pinning requirement: "The app correctly implements identity pinning." platform: [android, ios] profiles: [L2] +threat: MAS-THREAT-0027 +attacks: [MAS-ATTACK-0014, MAS-ATTACK-0016, MAS-ATTACK-0017] mappings: masvs-v1: [MSTG-NETWORK-4] masvs-v2: [MASVS-NETWORK-2] @@ -35,14 +37,6 @@ Pinning is not foolproof: attackers who can reverse-engineer the app may remove ## Impact -Attackers can intercept or modify TLS-protected traffic even when standard certificate validation succeeds by: - -- Performing a Machine-in-the-Middle (MITM) attack, e.g., via ARP poisoning, DNS spoofing, or a rogue access point. -- Obtaining a valid certificate for the target domain from a compromised, coerced, or rogue Certificate Authority (CA). -- Installing an attacker-controlled CA certificate on a device they control to inspect the app's traffic. - -This can lead to: - - **Compromise of Sensitive Data**: Attackers can capture, read, or alter sensitive information transmitted over the network, resulting in unauthorized disclosure or manipulation of user data. - **Authentication or Authorization Bypass**: Attackers can capture credentials or session tokens in transit, resulting in user impersonation and unauthorized access to accounts or backend systems. - **Compromise of System Integrity and Business Operations**: Attackers can inspect and reverse engineer the app's API traffic to abuse backend services, resulting in fraud, scraping, or service abuse against the app owner. diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0028.md b/weaknesses/MASVS-PLATFORM/MASWE-0028.md index 5e43c7c..f60da54 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0028.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0028.md @@ -5,6 +5,8 @@ alias: data-leak-ui requirement: "The app does not unnecessarily expose sensitive data through the app user interface." platform: [android, ios] profiles: [L2] +threat: MAS-THREAT-0028 +attacks: [MAS-ATTACK-0005, MAS-ATTACK-0041, MAS-ATTACK-0043] mappings: masvs-v1: [MSTG-STORAGE-7] masvs-v2: [MASVS-PLATFORM-3, MASVS-STORAGE-2] @@ -31,14 +33,6 @@ Typical exposure paths include displaying values in cleartext when masking would ## Impact -Attackers can capture sensitive data displayed or entered in the user interface by: - -- Observing the device screen while sensitive data is displayed or entered (shoulder surfing). -- Reading sensitive data from the clipboard when users copy it between apps. -- Accessing the device storage on a compromised device. - -This can lead to: - - **Compromise of Sensitive Data**: Attackers can read personal or financial information from the screen, the clipboard, or keyboard cache files, resulting in unauthorized disclosure of user data. - **Authentication or Authorization Bypass**: Attackers can capture credentials, PINs, or one-time codes exposed through the UI, resulting in unauthorized access to the user's accounts. diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0029.md b/weaknesses/MASVS-PLATFORM/MASWE-0029.md index c33a34f..50147fe 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0029.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0029.md @@ -5,6 +5,8 @@ alias: data-leak-notifications requirement: "The app does not unnecessarily expose sensitive data through system notifications." platform: [android, ios] profiles: [L2] +threat: MAS-THREAT-0029 +attacks: [MAS-ATTACK-0044, MAS-ATTACK-0045] mappings: masvs-v2: [MASVS-PLATFORM-3, MASVS-STORAGE-2] cwe: [200, 359] @@ -28,13 +30,6 @@ Notifications are rendered on the lock screen, where anyone holding the device c ## Impact -Attackers can access sensitive data shown in notifications by: - -- Reading notification content shown on the lock screen without unlocking the device. -- Reading notification content from another app holding notification-access permissions. - -This can lead to: - - **Compromise of Sensitive Data**: Attackers can read message contents or account details from notifications, resulting in unauthorized disclosure of user data. - **Authentication or Authorization Bypass**: Attackers can capture one-time codes delivered via notifications, resulting in the defeat of SMS- or push-based authentication factors and unauthorized account access. diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0030.md b/weaknesses/MASVS-PLATFORM/MASWE-0030.md index e9fbdc8..de34c94 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0030.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0030.md @@ -5,6 +5,8 @@ alias: data-leak-screenshots requirement: "The app removes sensitive data from views when moved to the background or when being recorded." platform: [android, ios] profiles: [L2] +threat: MAS-THREAT-0030 +attacks: [MAS-ATTACK-0010, MAS-ATTACK-0071, MAS-ATTACK-0072] mappings: masvs-v1: [MSTG-STORAGE-9] masvs-v2: [MASVS-PLATFORM-3, MASVS-STORAGE-2] @@ -28,14 +30,6 @@ Mobile platforms allow users, other apps, and external tools to capture screensh ## Impact -Attackers can access sensitive data displayed on the screen by: - -- Capturing or recording the screen from another app or an external tool. -- Accessing shared or external storage from any app holding the corresponding permissions. -- Accessing screenshots automatically taken by the system, e.g., when the app moves to the background. - -This can lead to: - - **Compromise of Sensitive Data**: Attackers can obtain sensitive data previously displayed on the screen, such as account details, personal information, or one-time codes, resulting in unauthorized disclosure and enabling further attacks such as identity theft or account takeover. ## Mitigations diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0031.md b/weaknesses/MASVS-PLATFORM/MASWE-0031.md index d5c78c5..d2db489 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0031.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0031.md @@ -5,6 +5,8 @@ alias: tapjacking-attacks requirement: "The app protects its sensitive screens against overlay attacks." platform: [android, ios] profiles: [L2] +threat: MAS-THREAT-0031 +attacks: [MAS-ATTACK-0036] mappings: masvs-v1: [MSTG-PLATFORM-9] masvs-v2: [MASVS-PLATFORM-3, MASVS-CODE-1] @@ -30,12 +32,6 @@ In an overlay attack, a malicious app draws content on top of the target app to ## Impact -Attackers can hijack user interactions with the app by: - -- Displaying overlays or tampering with the UI to alter what the user sees while approving an action. - -This can lead to: - - **Financial Loss**: Attackers can trick users into confirming payments or transfers they believe to be something else, resulting in direct financial harm to the user. - **Authentication or Authorization Bypass**: Attackers can trick users into granting permissions or approving security prompts, resulting in unauthorized access to protected data or functionality. - **Compromise of Sensitive Data**: Attackers can capture input entered into overlay-mimicked fields, resulting in the disclosure of credentials or other sensitive user input. diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0032.md b/weaknesses/MASVS-PLATFORM/MASWE-0032.md index 321b103..30a46d2 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0032.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0032.md @@ -5,6 +5,8 @@ alias: insecure-deep-links requirement: "The app securely handles deep links." platform: [android, ios] profiles: [L1, L2] +threat: MAS-THREAT-0032 +attacks: [MAS-ATTACK-0046, MAS-ATTACK-0047] mappings: masvs-v1: [MSTG-PLATFORM-3] masvs-v2: [MASVS-PLATFORM-1, MASVS-STORAGE-2, MASVS-CODE-4] @@ -32,13 +34,6 @@ Deep links (Android App Links and custom URL schemes, iOS Universal Links and cu ## Impact -Attackers can hijack deep links or inject malicious input into the app by: - -- Registering the same custom URL scheme to intercept links intended for the app. -- Delivering crafted deep links or intents from a malicious app or web page. - -This can lead to: - - **Compromise of Sensitive Data**: Attackers can intercept tokens or personal data carried in deep links, or exfiltrate data through injected parameters, resulting in unauthorized disclosure of user data. - **Authentication or Authorization Bypass**: Attackers can capture authentication material delivered via hijacked links (e.g. login or password-reset links), resulting in account takeover. - **Execution of Unauthorized Code**: Attackers can inject expressions or script through unsanitized deep-link parameters that reach interpreters or WebViews, resulting in attacker-controlled behavior inside the app. diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0033.md b/weaknesses/MASVS-PLATFORM/MASWE-0033.md index 5e96272..6eb99da 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0033.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0033.md @@ -5,6 +5,8 @@ alias: improper-clipboard requirement: "The app avoids placing sensitive data on the system clipboard." platform: [android, ios] profiles: [L1, L2] +threat: MAS-THREAT-0033 +attacks: [MAS-ATTACK-0041] mappings: masvs-v2: [MASVS-PLATFORM-1, MASVS-STORAGE-2] cwe: [200, 668] @@ -33,12 +35,6 @@ The clipboard is a shared resource: other apps can read its contents, and on som ## Impact -Attackers can capture sensitive data placed on the clipboard by: - -- Reading sensitive data from the clipboard when users copy it between apps. - -This can lead to: - - **Compromise of Sensitive Data**: Attackers can read personal or financial data from the clipboard, resulting in unauthorized disclosure of user data. - **Authentication or Authorization Bypass**: Attackers can capture copied credentials or one-time codes, resulting in unauthorized access to the user's accounts. diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0034.md b/weaknesses/MASVS-PLATFORM/MASWE-0034.md index 99584fe..ebcca0c 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0034.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0034.md @@ -5,6 +5,8 @@ alias: insecure-app-extensions requirement: "The app only permits trusted app extensions to interact with it." platform: [ios] profiles: [L1, L2] +threat: MAS-THREAT-0034 +attacks: [MAS-ATTACK-0048] mappings: masvs-v1: [MSTG-PLATFORM-11] masvs-v2: [MASVS-PLATFORM-1, MASVS-STORAGE-2] @@ -30,12 +32,6 @@ On iOS, app extensions run third-party code that can interact with the host app ## Impact -Attackers can capture sensitive user input and content by: - -- Capturing user input through a malicious custom keyboard or app extension. - -This can lead to: - - **Compromise of Sensitive Data**: Attackers can log keystrokes or read content handed to a malicious extension, resulting in unauthorized disclosure of personal data typed into or shared from the app. - **Authentication or Authorization Bypass**: Attackers can capture credentials or one-time codes typed on a malicious keyboard, resulting in unauthorized access to the user's accounts. diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0035.md b/weaknesses/MASVS-PLATFORM/MASWE-0035.md index 8718708..06094c5 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0035.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0035.md @@ -5,6 +5,8 @@ alias: insecure-intents requirement: "The app securely handles intents." platform: [android] profiles: [L1, L2] +threat: MAS-THREAT-0035 +attacks: [MAS-ATTACK-0047, MAS-ATTACK-0049, MAS-ATTACK-0050] mappings: masvs-v2: [MASVS-PLATFORM-1, MASVS-STORAGE-2] cwe: [927, 940] @@ -42,14 +44,6 @@ Intents are Android's primary inter- and intra-app messaging mechanism. Insecure ## Impact -Attackers can intercept or manipulate the app's intents by: - -- Registering intent filters to intercept implicit intents sent by the app. -- Modifying or replaying mutable PendingIntents obtained from the app. -- Delivering crafted deep links or intents from a malicious app or web page. - -This can lead to: - - **Compromise of Sensitive Data**: Attackers can receive sensitive extras carried in implicit intents or broadcasts, resulting in unauthorized disclosure of user or app data to other apps. - **Authentication or Authorization Bypass**: Attackers can reach non-exported components through intent redirection or execute actions with the app's identity through manipulated PendingIntents, resulting in privileged operations performed on the attacker's behalf. diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0036.md b/weaknesses/MASVS-PLATFORM/MASWE-0036.md index 0e64cb4..89eadde 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0036.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0036.md @@ -5,6 +5,8 @@ alias: js-bridges-webviews requirement: "The app does not expose sensitive native functionality to WebView content." platform: [android, ios] profiles: [L1, L2] +threat: MAS-THREAT-0036 +attacks: [MAS-ATTACK-0047, MAS-ATTACK-0051] mappings: masvs-v1: [MSTG-PLATFORM-7] masvs-v2: [MASVS-PLATFORM-2, MASVS-STORAGE-2] @@ -32,13 +34,6 @@ Bridges such as `addJavascriptInterface` on Android or script message handlers a ## Impact -Attackers can invoke exposed native functionality from web content by: - -- Injecting malicious JavaScript into WebView content (e.g., via MITM on insecure connections or a compromised website). -- Delivering crafted deep links or intents from a malicious app or web page. - -This can lead to: - - **Compromise of Sensitive Data**: Attackers can call bridge methods that return user or app data, resulting in exfiltration of sensitive information to attacker-controlled servers. - **Execution of Unauthorized Code**: Attackers can drive native functionality exposed through the bridge, resulting in privileged actions performed within the app's context. diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0037.md b/weaknesses/MASVS-PLATFORM/MASWE-0037.md index 8d09bfa..0e0369d 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0037.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0037.md @@ -5,6 +5,8 @@ alias: webviews-local-resources requirement: "The app does not allow WebViews loading untrusted content to access local resources." platform: [android, ios] profiles: [L1, L2] +threat: MAS-THREAT-0037 +attacks: [MAS-ATTACK-0047, MAS-ATTACK-0051] mappings: masvs-v1: [MSTG-PLATFORM-6] masvs-v2: [MASVS-PLATFORM-2, MASVS-STORAGE-2, MASVS-CODE-4] @@ -33,13 +35,6 @@ Settings that enable file or content access (e.g. `setAllowFileAccess`, `setAllo ## Impact -Attackers can access local files and app-private data from web content by: - -- Injecting malicious JavaScript into WebView content (e.g., via MITM on insecure connections or a compromised website). -- Delivering crafted deep links or intents from a malicious app or web page. - -This can lead to: - - **Compromise of Sensitive Data**: Attackers can read and exfiltrate app-private files, such as databases, preferences, or cached tokens, resulting in unauthorized disclosure of user and app data. - **Authentication or Authorization Bypass**: Attackers can steal session material stored in reachable files or WebView storage, resulting in account takeover. diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0038.md b/weaknesses/MASVS-PLATFORM/MASWE-0038.md index 8db8829..c408aef 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0038.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0038.md @@ -5,6 +5,8 @@ alias: webviews-untrusted-content requirement: "The app does not allow WebViews to load untrusted content." platform: [android, ios] profiles: [L1, L2] +threat: MAS-THREAT-0038 +attacks: [MAS-ATTACK-0047, MAS-ATTACK-0051] mappings: masvs-v2: [MASVS-PLATFORM-2, MASVS-CODE-4] cwe: [79, 601, 829] @@ -33,13 +35,6 @@ WebViews often run with app-specific privileges, such as JavaScript bridges, coo ## Impact -Attackers can execute malicious web content inside the app's WebView by: - -- Delivering crafted deep links or intents from a malicious app or web page. -- Injecting malicious JavaScript into WebView content (e.g., via MITM on insecure connections or a compromised website). - -This can lead to: - - **Compromise of Sensitive Data**: Attackers can steal cookies, tokens, or displayed data from any origin via cross-site scripting in the privileged WebView, resulting in unauthorized disclosure of session material and user data. - **Authentication or Authorization Bypass**: Attackers can reuse stolen session cookies or tokens, resulting in account takeover across the sites the WebView had sessions with. - **Loss of User Trust**: Attackers can render phishing pages or trigger unwanted downloads inside the app's own UI, resulting in users being deceived under the app's identity and reputational damage for the app owner. diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0039.md b/weaknesses/MASVS-PLATFORM/MASWE-0039.md index c9b30d7..d52f5e9 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0039.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0039.md @@ -5,6 +5,8 @@ alias: data-leak-accessibility requirement: "The app prevents sensitive data from being exposed to, or captured by, accessibility services." platform: [android, ios] profiles: [L2] +threat: MAS-THREAT-0039 +attacks: [MAS-ATTACK-0052] mappings: masvs-v2: [MASVS-PLATFORM-3, MASVS-STORAGE-2] cwe: [200, 359] @@ -29,12 +31,6 @@ Accessibility services (e.g. Android's `AccessibilityService`) can observe scree ## Impact -Attackers can capture sensitive data displayed or entered in the app by: - -- Harvesting on-screen content through a malicious accessibility service the user was tricked into enabling. - -This can lead to: - - **Compromise of Sensitive Data**: Attackers can read messages, personal data, and financial details from on-screen content, resulting in unauthorized disclosure of user data. - **Authentication or Authorization Bypass**: Attackers can harvest credentials and one-time codes as they are displayed or entered, resulting in account takeover. - **Financial Loss**: Attackers can combine harvested data with accessibility-driven UI automation to initiate fraudulent transactions, resulting in direct financial harm to the user. diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0065.md b/weaknesses/MASVS-PRIVACY/MASWE-0065.md index 319cfff..31a7a05 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0065.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0065.md @@ -5,6 +5,8 @@ alias: anonymization-pseudonymization-measures requirement: "The app uses anonymization or pseudonymisation measures." platform: [android, ios] profiles: [P] +threat: MAS-THREAT-0065 +attacks: [MAS-ATTACK-0074, MAS-ATTACK-0078] mappings: masvs-v2: [MASVS-PRIVACY-2] cwe: [359] @@ -32,13 +34,6 @@ Anonymization, through methods like randomization or generalization, irreversibl ## Impact -Apps and embedded third-party components, as well as any party that later obtains the collected data, can identify and track users by: - -- Linking directly identifiable data to real-world identities. -- Collecting and correlating identifiers and usage data across apps, devices, and services. - -This can lead to: - - **Violation of User Privacy**: Third parties can profile users and target them with advertising without consent, resulting in the loss of users' control over their personal information and its unforeseen use, e.g. to train AI models. - **Legal and Regulatory Non-Compliance**: Processing personal data without de-identification safeguards can violate data protection laws and regulations (like GDPR), resulting in legal consequences and fines for the app owner. diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0066.md b/weaknesses/MASVS-PRIVACY/MASWE-0066.md index 5117ed6..100be4f 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0066.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0066.md @@ -5,6 +5,8 @@ alias: unique-identifiers-user-tracking requirement: "The app does not use persistent or unique identifiers in a way that enables user tracking." platform: [android, ios] profiles: [P] +threat: MAS-THREAT-0066 +attacks: [MAS-ATTACK-0074, MAS-ATTACK-0077] mappings: masvs-v2: [MASVS-PRIVACY-2] cwe: [359] @@ -45,13 +47,6 @@ Unique identifiers, especially those that cannot be reset, are a key enabler of ## Impact -Apps and embedded third-party components can track users across apps, devices, and services by: - -- Collecting non-resettable identifiers or misusing resettable ones. -- Collecting and correlating identifiers and usage data across apps, devices, and services. - -This can lead to: - - **Violation of User Privacy**: Third parties can build detailed profiles of individuals, estimating interests, health status, sexual orientation, and other personal attributes, resulting in users losing control over their personal information and being subject to unwanted targeting or profiling. - **Loss of User Trust**: Users can discover undisclosed tracking, resulting in negative reviews, decreased engagement, and reduced retention for the app owner. - **Legal and Regulatory Non-Compliance**: Tracking users without valid consent can violate data protection laws (like GDPR) and platform guidelines, resulting in fines, legal action, or app store removal for the app owner. diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0067.md b/weaknesses/MASVS-PRIVACY/MASWE-0067.md index b93ab2d..3613f5d 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0067.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0067.md @@ -5,6 +5,8 @@ alias: privacy-policy requirement: "The app provides an adequate privacy policy." platform: [android, ios] profiles: [P] +threat: MAS-THREAT-0067 +attacks: [MAS-ATTACK-0079, MAS-ATTACK-0080] mappings: masvs-v1: [MSTG-STORAGE-12] masvs-v2: [MASVS-PRIVACY-3] @@ -30,13 +32,6 @@ Privacy policies should be easily accessible, tailored specifically to the app i ## Impact -Apps and embedded third-party components can collect, process, or share personal data in ways users cannot anticipate by: - -- Operating without a privacy policy or under a vague, generic, or inaccessible one. -- Deviating from the practices stated in the published privacy policy. - -This can lead to: - - **Violation of User Privacy**: Users can unknowingly provide data that is shared with third parties, used for profiling, or used for targeted advertising without explicit consent, resulting in the loss of control over their personal information. - **Loss of User Trust**: Users can perceive the app as non-transparent, resulting in negative reviews, decreased user engagement, and reduced retention for the app owner. - **Legal and Regulatory Non-Compliance**: Failing to provide an adequate privacy policy can violate privacy laws and regulations, such as GDPR or CCPA, resulting in fines, legal action, or removal from app stores for the app owner. diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0068.md b/weaknesses/MASVS-PRIVACY/MASWE-0068.md index 2b8b465..98632d0 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0068.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0068.md @@ -5,6 +5,8 @@ alias: data-collection-declarations requirement: "The app adequately declares all user collected data." platform: [android, ios] profiles: [P] +threat: MAS-THREAT-0068 +attacks: [MAS-ATTACK-0081, MAS-ATTACK-0082] mappings: masvs-v1: [MSTG-STORAGE-12, MSTG-NETWORK-1] masvs-v2: [MASVS-PRIVACY-3, MASVS-PRIVACY-1] @@ -39,13 +41,6 @@ These declarations must clearly outline what data is collected, how it is used, ## Impact -Apps and embedded third-party components can collect or share more data than users were led to expect by: - -- Collecting or sharing data categories that are not declared in the platform's privacy labels. -- Transmitting undeclared identifiers or analytics data to first- or third-party services over the network. - -This can lead to: - - **Violation of User Privacy**: Users can unknowingly share data whose purpose they do not understand, resulting in unauthorized sharing, profiling, or targeted advertising. - **Loss of User Trust**: Users can discover the inconsistent declarations, resulting in negative reviews, lower user engagement, and reduced retention for the app owner. - **Legal and Regulatory Non-Compliance**: Inaccurate or inconsistent data declarations can violate regulations like GDPR or CCPA and platform policies, resulting in fines, legal action, or removal from app stores for the app owner. diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0069.md b/weaknesses/MASVS-PRIVACY/MASWE-0069.md index b2da55d..d7962de 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0069.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0069.md @@ -5,6 +5,8 @@ alias: data-management-controls requirement: "The app provides adequate controls to manage user data." platform: [android, ios] profiles: [P] +threat: MAS-THREAT-0069 +attacks: [MAS-ATTACK-0083] mappings: masvs-v2: [MASVS-PRIVACY-4] cwe: [359] @@ -26,12 +28,6 @@ These mechanisms typically include the ability for users to delete, export, modi ## Impact -Apps and their backend services can retain and process personal data beyond the user's control by: - -- Providing no way for users to delete, export, modify, or opt out of the collection of their data. - -This can lead to: - - **Violation of User Privacy**: Users cannot exercise their rights to manage their personal data, such as deleting or exporting their information, resulting in the loss of control over their data and an increased amount of exposed data if a breach occurs. - **Loss of User Trust**: Users can perceive that they have no control over their personal data, resulting in negative reviews, decreased user engagement, and reduced retention for the app owner. - **Legal and Regulatory Non-Compliance**: Failing to provide data management capabilities can violate regulations like GDPR and CCPA, resulting in fines, legal action, and other consequences for the app owner. diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0070.md b/weaknesses/MASVS-PRIVACY/MASWE-0070.md index dbdb6d0..6c586f7 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0070.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0070.md @@ -5,6 +5,8 @@ alias: data-visibility-control requirement: "The app provides adequate controls over the visibility of user data." platform: [android, ios] profiles: [P] +threat: MAS-THREAT-0070 +attacks: [MAS-ATTACK-0084, MAS-ATTACK-0087] mappings: masvs-v2: [MASVS-PRIVACY-4] cwe: [359] @@ -28,13 +30,6 @@ Examples of such information include last connection status, read receipts, birt ## Impact -Apps and their users' counterparts can expose personal information beyond the user's intent by: - -- Making profile details, activity status, or discoverability visible to other users or third parties by default. -- Exporting or sharing data through flows whose privacy consequences are not evident to the user. - -This can lead to: - - **Violation of User Privacy**: Users can unintentionally expose personal information, such as their email address, birthday, or online status, to others without their consent, resulting in an increased risk of harassment, stalking, or identity theft. - **Loss of User Trust**: Users can feel they have inadequate control over what information is shared and with whom, resulting in negative reviews and decreased app engagement for the app owner. - **Legal and Regulatory Non-Compliance**: Failing to offer sufficient privacy controls can violate regulations like GDPR or CCPA, which require user control over data visibility and sharing, resulting in fines or legal action for the app owner. diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0071.md b/weaknesses/MASVS-PRIVACY/MASWE-0071.md index e61bbcd..adfd594 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0071.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0071.md @@ -5,6 +5,8 @@ alias: ambiguous-consent-mechanisms requirement: "The app requests user consent prior to any data processing." platform: [android, ios] profiles: [P] +threat: MAS-THREAT-0071 +attacks: [MAS-ATTACK-0085, MAS-ATTACK-0086, MAS-ATTACK-0087] mappings: masvs-v2: [MASVS-PRIVACY-4] cwe: [200, 285, 358, 359] @@ -32,14 +34,6 @@ In addition, users must be able to easily withdraw their consent at any time and ## Impact -Apps and embedded third-party components can process personal data without valid user consent by: - -- Collecting data under consent that is bundled, implied, or otherwise not freely and specifically given. -- Continuing to collect data under an outdated consent after practices have changed. -- Exporting or sharing data through flows whose privacy consequences are not evident to the user. - -This can lead to: - - **Violation of User Privacy**: Users can unknowingly give up control over their data, resulting in its use for purposes they may find objectionable or harmful, such as targeted advertising, profiling, discrimination, or even identity theft. - **Loss of User Trust**: Users can lose trust in the app and abandon it, share negative reviews, or discourage others from using it, resulting in reputational damage and potential loss of business for the app owner. - **Legal and Regulatory Non-Compliance**: Processing data without valid consent can violate laws and platform requirements, resulting in legal consequences, fines, or removal from app stores for the app owner. diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0072.md b/weaknesses/MASVS-PRIVACY/MASWE-0072.md index cfff8fc..6678efd 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0072.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0072.md @@ -5,6 +5,8 @@ alias: inadequate-permission-management requirement: "The app adequately manages permissions." platform: [android, ios] profiles: [P] +threat: MAS-THREAT-0072 +attacks: [MAS-ATTACK-0088, MAS-ATTACK-0089] mappings: masvs-v2: [MASVS-PRIVACY-1] cwe: [250] @@ -43,13 +45,6 @@ Third-party libraries (SDKs) further complicate permission management by inherit ## Impact -Apps and embedded third-party components can access more sensitive device resources and data than needed by: - -- Holding excessive or no-longer-needed permissions granted to the app. -- Inheriting the app's permissions in third-party SDKs, whose data collection is difficult to audit and control. - -This can lead to: - - **Violation of User Privacy**: Apps and embedded components can unnecessarily access personal data such as location, contacts, or media, resulting in misuse, surveillance, or profiling of the user. - **Compromise of Sensitive Data**: Third-party services can collect and retain data obtained through inherited permissions; once that data leaves the app its security can no longer be guaranteed, resulting in an increased risk of large-scale exposure via data breaches. - **Loss of User Trust**: Users can perceive permission requests as unjustified, resulting in refused permissions, negative reviews, lower user engagement, and reduced retention for the app owner. diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0073.md b/weaknesses/MASVS-PRIVACY/MASWE-0073.md index 0048e54..64bca18 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0073.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0073.md @@ -5,6 +5,8 @@ alias: tracking-domains-declarations requirement: "The app adequately declares all tracking domains it connects to." platform: [android, ios] profiles: [P] +threat: MAS-THREAT-0073 +attacks: [MAS-ATTACK-0074, MAS-ATTACK-0075] mappings: masvs-v2: [MASVS-PRIVACY-3] cwe: [359] @@ -31,13 +33,6 @@ Platforms increasingly require apps to declare their tracking domains so the sys ## Impact -Apps and embedded third-party components can track users against their expressed preferences by: - -- Contacting undeclared tracking domains that platform enforcement cannot block. -- Collecting and correlating identifiers and usage data across apps, devices, and services. - -This can lead to: - - **Violation of User Privacy**: Tracking traffic can bypass the platform's enforcement of the user's tracking choice, resulting in users being tracked despite having refused permission. - **Loss of User Trust**: Users and researchers can discover undeclared tracking connections, resulting in negative publicity and reduced trust in the app. - **Legal and Regulatory Non-Compliance**: Inaccurate tracking declarations can violate platform policies and privacy regulations, resulting in app-review rejection, removal, or fines for the app owner. diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0074.md b/weaknesses/MASVS-PRIVACY/MASWE-0074.md index 3f545bf..d905cc2 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0074.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0074.md @@ -5,6 +5,8 @@ alias: non-privacy-preserving-functionality requirement: "The app uses privacy-preserving functionality." platform: [android, ios] profiles: [P] +threat: MAS-THREAT-0074 +attacks: [MAS-ATTACK-0076, MAS-ATTACK-0088] mappings: masvs-v2: [MASVS-PRIVACY-2] cwe: [359] @@ -31,13 +33,6 @@ Platforms increasingly offer least-exposing APIs for common tasks: system authen ## Impact -Apps and embedded third-party components can access more user data than the feature requires by: - -- Handling credentials and browsing state inside the app instead of isolated system flows. -- Holding excessive or no-longer-needed permissions granted to the app. - -This can lead to: - - **Violation of User Privacy**: The app and its embedded components can observe credentials, browsing state, or whole data collections (e.g. the entire photo library) that a privacy-preserving alternative would never have exposed, resulting in avoidable over-collection of personal data. - **Compromise of Sensitive Data**: Data unnecessarily accessible to the app can be leaked through any other weakness or through embedded third parties, resulting in exposure of user data that the app never needed to hold. - **Loss of User Trust**: Users can perceive unnecessary permission prompts and embedded login flows as invasive, resulting in refused permissions, abandoned logins, and reduced retention. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0049.md b/weaknesses/MASVS-RESILIENCE/MASWE-0049.md index 6de9350..ff4a091 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0049.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0049.md @@ -5,6 +5,8 @@ alias: secured-device-detection-not-implemented requirement: "The app verifies that the device has a secure lock screen configured before enabling sensitive functionality." platform: [android, ios] profiles: [L2] +threat: MAS-THREAT-0049 +attacks: [MAS-ATTACK-0063] mappings: masvs-v1: [MSTG-STORAGE-11] masvs-v2: [MASVS-RESILIENCE-1] @@ -29,12 +31,6 @@ Many of the platform's data-protection guarantees assume a device credential exi ## Impact -Attackers can access sensitive data and functionality on unprotected devices by: - -- Accessing a lost or stolen device that has no secure lock screen configured. - -This can lead to: - - **Compromise of Sensitive Data**: Attackers can open the app and read its data on a device with no lock, resulting in unauthorized disclosure of user data whose protection assumed a device credential. - **Authentication or Authorization Bypass**: Attackers can act within the app's active sessions on an unprotected device, resulting in unauthorized use of the victim's accounts. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0050.md b/weaknesses/MASVS-RESILIENCE/MASWE-0050.md index 5ee51c8..df72c8c 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0050.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0050.md @@ -5,6 +5,8 @@ alias: debuggable-flag requirement: "The app disables debug mechanisms." platform: [android, ios] profiles: [R] +threat: MAS-THREAT-0050 +attacks: [MAS-ATTACK-0002, MAS-ATTACK-0003, MAS-ATTACK-0004] mappings: masvs-v1: [MSTG-RESILIENCE-2] masvs-v2: [MASVS-RESILIENCE-4, MASVS-PLATFORM-2] @@ -34,14 +36,6 @@ Beyond the application-level debuggable flag, this weakness also covers WebView ## Impact -Attackers can inspect and manipulate a debuggable app at runtime, even on non-rooted or non-jailbroken devices, by: - -- Debugging the app at runtime. -- Attaching a remote inspector to the app's debuggable web content. -- Using dynamic instrumentation. - -This can lead to: - - **Compromise of Sensitive Data**: Attackers can read the app's memory and logs to obtain encryption keys, API keys, user credentials, or tokens that are never written to the app's code or disk, resulting in unauthorized disclosure of secrets and user data. - **Authentication or Authorization Bypass**: Attackers can manipulate the app's execution flow to skip authentication and authorization checks, resulting in unauthorized access to protected functionality. - **Execution of Unauthorized Code**: Attackers can inject and execute arbitrary code within the app's context, e.g. by injecting reverse engineering tools like Frida, resulting in further exploitation of the app or the device. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0051.md b/weaknesses/MASVS-RESILIENCE/MASWE-0051.md index d8fbfec..a94297a 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0051.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0051.md @@ -5,6 +5,8 @@ alias: code-obfuscation requirement: "The app applies code obfuscation to hinder reverse engineering." platform: [android, ios] profiles: [R] +threat: MAS-THREAT-0051 +attacks: [MAS-ATTACK-0001] mappings: masvs-v1: [MSTG-RESILIENCE-9] masvs-v2: [MASVS-RESILIENCE-3] @@ -29,12 +31,6 @@ Obfuscation does not prevent reverse engineering, but it raises its cost. Effect ## Impact -Attackers can analyze the app's logic and security controls with minimal effort by: - -- Obtaining the app package and reverse engineering it. - -This can lead to: - - **Bypass of Protection Mechanisms**: Attackers can quickly locate and defeat client-side checks such as root detection, licensing, or anti-tampering logic, resulting in the circumvention of the app's defenses. - **Compromise of Sensitive Data**: Attackers can recover proprietary algorithms and embedded secrets from readable code, resulting in intellectual property theft and easier planning of further attacks. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0052.md b/weaknesses/MASVS-RESILIENCE/MASWE-0052.md index a962ba9..0be888a 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0052.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0052.md @@ -5,6 +5,8 @@ alias: resource-obfuscation requirement: "The app applies resource obfuscation to hinder reverse engineering." platform: [android, ios] profiles: [R] +threat: MAS-THREAT-0052 +attacks: [MAS-ATTACK-0001] mappings: masvs-v1: [MSTG-RESILIENCE-11] masvs-v2: [MASVS-RESILIENCE-3] @@ -28,12 +30,6 @@ Beyond code, strings, layouts, configuration files, bundled data, and native bin ## Impact -Attackers can analyze the app's inner workings through its resources by: - -- Obtaining the app package and reverse engineering it. - -This can lead to: - - **Bypass of Protection Mechanisms**: Attackers can locate security-relevant configuration and assets and use them to target the app's defenses, resulting in easier circumvention of its protections. - **Compromise of Sensitive Data**: Attackers can extract proprietary content and internal information from clear resources, resulting in intellectual property exposure. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0053.md b/weaknesses/MASVS-RESILIENCE/MASWE-0053.md index 7c06a69..7ca2f32 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0053.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0053.md @@ -5,6 +5,8 @@ alias: anti-deobfuscation requirement: "The app implements anti-deobfuscation techniques to protect its obfuscation." platform: [android, ios] profiles: [R] +threat: MAS-THREAT-0053 +attacks: [MAS-ATTACK-0001] mappings: masvs-v1: [MSTG-RESILIENCE-12] masvs-v2: [MASVS-RESILIENCE-3] @@ -28,12 +30,6 @@ Obfuscation alone is a moving target: publicly available deobfuscators, decompil ## Impact -Attackers can undo the app's obfuscation with automated tooling by: - -- Obtaining the app package and reverse engineering it. - -This can lead to: - - **Bypass of Protection Mechanisms**: Attackers can recover near-original code and then locate and defeat the app's client-side defenses, resulting in the circumvention of protections the obfuscation was meant to shield. - **Compromise of Sensitive Data**: Attackers can recover proprietary algorithms and embedded secrets despite the obfuscation, resulting in intellectual property exposure. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0054.md b/weaknesses/MASVS-RESILIENCE/MASWE-0054.md index a5eb462..72cff43 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0054.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0054.md @@ -5,6 +5,8 @@ alias: non-production-resources requirement: "The app removes debug artifacts." platform: [android, ios] profiles: [R] +threat: MAS-THREAT-0054 +attacks: [MAS-ATTACK-0001, MAS-ATTACK-0006] mappings: masvs-v1: [MSTG-CODE-3, MSTG-CODE-4] masvs-v2: [MASVS-RESILIENCE-3] @@ -31,13 +33,6 @@ Such artifacts help adversaries understand the app's behavior and internals, may ## Impact -Attackers can analyze the app's internals and disable its security controls by: - -- Obtaining the app package and reverse engineering it. -- Accessing the system logs on a compromised device or from an app holding log-access permissions. - -This can lead to: - - **Bypass of Protection Mechanisms**: Attackers can activate leftover debug switches or code paths that disable security controls such as certificate validation, resulting in the defeat of protections the production app is supposed to enforce. - **Compromise of Sensitive Data**: Attackers can use verbose logs, symbols, and debug flows to learn implementation details and extract sensitive values, resulting in information disclosure that enables further attacks. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0055.md b/weaknesses/MASVS-RESILIENCE/MASWE-0055.md index dcacd54..78f3831 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0055.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0055.md @@ -5,6 +5,8 @@ alias: data-unencrypted requirement: "The app applies application-level payload encryption in addition to transport-layer encryption." platform: [android, ios] profiles: [R] +threat: MAS-THREAT-0055 +attacks: [MAS-ATTACK-0064] mappings: masvs-v1: [MSTG-RESILIENCE-13] masvs-v2: [MASVS-RESILIENCE-3, MASVS-NETWORK-1] @@ -26,12 +28,6 @@ Even when the connection uses HTTPS, an attacker who controls the device can byp ## Impact -Attackers can inspect and manipulate the app's API payloads by: - -- Inspecting or modifying app traffic on a device they control after bypassing transport protections (e.g., pinning). - -This can lead to: - - **Compromise of System Integrity and Business Operations**: Attackers can map the app's API and craft or tamper with requests, resulting in fraud, scraping, and abuse of backend services at the app owner's expense. - **Bypass of Protection Mechanisms**: Attackers can modify payloads that carry security-relevant state, resulting in the circumvention of client-reported controls and business logic. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0056.md b/weaknesses/MASVS-RESILIENCE/MASWE-0056.md index 6ce0dad..1a661df 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0056.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0056.md @@ -5,6 +5,8 @@ alias: root-jailbreak-detection requirement: "The app terminates if a rooted/jailbroken device is detected." platform: [android, ios] profiles: [R] +threat: MAS-THREAT-0056 +attacks: [MAS-ATTACK-0003, MAS-ATTACK-0005, MAS-ATTACK-0065] mappings: masvs-v1: [MSTG-RESILIENCE-1, MSTG-RESILIENCE-8] masvs-v2: [MASVS-RESILIENCE-1, MASVS-RESILIENCE-4] @@ -27,14 +29,6 @@ On a rooted or jailbroken device, the platform's sandboxing and permission guara ## Impact -Attackers can run and manipulate the app in a privileged environment without resistance by: - -- Running the app on a rooted or jailbroken device they control. -- Using dynamic instrumentation. -- Accessing the device storage on a compromised device. - -This can lead to: - - **Bypass of Protection Mechanisms**: Attackers can use elevated privileges to defeat the app's client-side security controls, resulting in the circumvention of protections such as anti-tampering, licensing, or fraud controls. - **Compromise of Sensitive Data**: Attackers can read the app's private data and intercept its runtime state without sandbox restrictions, resulting in exposure of user data, keys, and tokens. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0057.md b/weaknesses/MASVS-RESILIENCE/MASWE-0057.md index 8356217..e6545bc 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0057.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0057.md @@ -5,6 +5,8 @@ alias: app-virtualization-detection requirement: "The app detects when it is running inside an app-virtualization environment." platform: [android, ios] profiles: [R] +threat: MAS-THREAT-0057 +attacks: [MAS-ATTACK-0067] mappings: masvs-v2: [MASVS-RESILIENCE-1] cwe: [693] @@ -26,12 +28,6 @@ App virtualization and "dual-app" container frameworks run an app inside another ## Impact -Attackers can observe and manipulate the app from a hosting process by: - -- Running the app inside an app-virtualization or cloning framework. - -This can lead to: - - **Compromise of Sensitive Data**: Attackers can intercept the virtualized app's files, credentials, and API calls from the hosting app, resulting in exposure of user data without requiring root access. - **Bypass of Protection Mechanisms**: Attackers can instrument the app inside the container to defeat its client-side controls, resulting in the circumvention of its defenses on unrooted devices. - **Compromise of System Integrity and Business Operations**: Attackers can run multiple cloned instances to abuse promotions or multi-account limits, resulting in fraud against the app owner. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0058.md b/weaknesses/MASVS-RESILIENCE/MASWE-0058.md index e7d8774..fd23e56 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0058.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0058.md @@ -5,6 +5,8 @@ alias: emulator-detection requirement: "The app detects when it is running on an emulator." platform: [android, ios] profiles: [R] +threat: MAS-THREAT-0058 +attacks: [MAS-ATTACK-0003, MAS-ATTACK-0066] mappings: masvs-v1: [MSTG-RESILIENCE-5, MSTG-RESILIENCE-8] masvs-v2: [MASVS-RESILIENCE-1, MASVS-RESILIENCE-4] @@ -27,13 +29,6 @@ Emulators give attackers a fully controlled, snapshottable environment for analy ## Impact -Attackers can analyze and automate the app in a fully controlled environment by: - -- Running the app in an emulator or virtual device. -- Using dynamic instrumentation. - -This can lead to: - - **Bypass of Protection Mechanisms**: Attackers can iterate on bypasses of the app's defenses with snapshots and full inspection, resulting in faster and cheaper circumvention of its protections. - **Compromise of System Integrity and Business Operations**: Attackers can run automated fleets of emulated instances, resulting in bot-driven fraud, fake accounts, and abuse of the app owner's services. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0059.md b/weaknesses/MASVS-RESILIENCE/MASWE-0059.md index a187513..3b49de4 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0059.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0059.md @@ -5,6 +5,8 @@ alias: device-attestation requirement: "The app implements device attestation." platform: [android, ios] profiles: [R] +threat: MAS-THREAT-0059 +attacks: [MAS-ATTACK-0065, MAS-ATTACK-0066, MAS-ATTACK-0068] mappings: masvs-v1: [MSTG-RESILIENCE-10] masvs-v2: [MASVS-RESILIENCE-1] @@ -38,14 +40,6 @@ Device attestation uses platform services, such as the Android Play Integrity AP ## Impact -Attackers can interact with the backend from untrusted environments by: - -- Impersonating the app with scripts, bots, or tampered clients when interacting with the backend. -- Running the app on a rooted or jailbroken device they control. -- Running the app in an emulator or virtual device. - -This can lead to: - - **Compromise of System Integrity and Business Operations**: Attackers can drive the backend with automated or tampered clients, resulting in fraud, scraping, fake accounts, and abuse of the app owner's services. - **Financial Loss**: Attackers can abuse promotions, premium features, or transaction flows from unattested environments, resulting in direct monetary loss to the app owner. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0060.md b/weaknesses/MASVS-RESILIENCE/MASWE-0060.md index 2ef2972..d6ca615 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0060.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0060.md @@ -5,6 +5,8 @@ alias: debugger-detection requirement: "The app terminates if a debugger is detected." platform: [android, ios] profiles: [R] +threat: MAS-THREAT-0060 +attacks: [MAS-ATTACK-0002] mappings: masvs-v1: [MSTG-RESILIENCE-2] masvs-v2: [MASVS-RESILIENCE-4] @@ -27,12 +29,6 @@ A debugger lets an attacker inspect memory, set breakpoints, and alter control f ## Impact -Attackers can inspect and manipulate the running app without resistance by: - -- Debugging the app at runtime. - -This can lead to: - - **Bypass of Protection Mechanisms**: Attackers can alter control flow at breakpoints to skip the app's client-side checks, resulting in the circumvention of its defenses. - **Compromise of Sensitive Data**: Attackers can read secrets and user data from process memory during debugging, resulting in exposure of credentials, keys, and tokens. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0061.md b/weaknesses/MASVS-RESILIENCE/MASWE-0061.md index 24f2e30..0934e38 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0061.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0061.md @@ -5,6 +5,8 @@ alias: dynamic-analysis-tools requirement: "The app detects dynamic analysis tools." platform: [android, ios] profiles: [R] +threat: MAS-THREAT-0061 +attacks: [MAS-ATTACK-0003] mappings: masvs-v1: [MSTG-RESILIENCE-4] masvs-v2: [MASVS-RESILIENCE-4] @@ -27,12 +29,6 @@ Tools such as Frida, Xposed/LSPosed, and ElleKit/Cydia Substrate let attackers o ## Impact -Attackers can observe and modify the running app without resistance by: - -- Using dynamic instrumentation. - -This can lead to: - - **Bypass of Protection Mechanisms**: Attackers can hook and replace the app's security checks at runtime, resulting in the circumvention of its client-side defenses, including root, debugger, and integrity checks. - **Compromise of Sensitive Data**: Attackers can intercept function arguments and memory contents during instrumentation, resulting in exposure of credentials, keys, and user data. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0062.md b/weaknesses/MASVS-RESILIENCE/MASWE-0062.md index f1e0a41..2974906 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0062.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0062.md @@ -5,6 +5,8 @@ alias: app-integrity requirement: "The app implements app attestation." platform: [android, ios] profiles: [R] +threat: MAS-THREAT-0062 +attacks: [MAS-ATTACK-0040, MAS-ATTACK-0069] mappings: masvs-v1: [MSTG-CODE-1] masvs-v2: [MASVS-RESILIENCE-2] @@ -30,13 +32,6 @@ App attestation includes verifying the app's signature and binaries at runtime, ## Impact -Attackers can distribute and run modified copies of the app by: - -- Patching or repackaging the app to remove or alter client-side checks. -- Installing a repackaged version of the app on victim devices. - -This can lead to: - - **Bypass of Protection Mechanisms**: Attackers can strip security controls from a repackaged copy that still works against the backend, resulting in the circumvention of the app's defenses at scale. - **Compromise of Sensitive Data**: Attackers can distribute trojanized versions of the app that harvest credentials and data from the users they deceive, resulting in account compromise attributed to the app. - **Compromise of System Integrity and Business Operations**: Modified clients, cracked features, and clone apps circulate under the app's brand, resulting in revenue loss and reputational damage for the app owner. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0063.md b/weaknesses/MASVS-RESILIENCE/MASWE-0063.md index ef14c2e..d232e9c 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0063.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0063.md @@ -5,6 +5,8 @@ alias: app-resources-integrity requirement: "The app verifies the integrity of its resources." platform: [android, ios] profiles: [R] +threat: MAS-THREAT-0063 +attacks: [MAS-ATTACK-0009, MAS-ATTACK-0070] mappings: masvs-v1: [MSTG-RESILIENCE-3] masvs-v2: [MASVS-RESILIENCE-2, MASVS-CODE-4] @@ -28,13 +30,6 @@ Beyond executable code, apps depend on resources whose integrity matters: files ## Impact -Attackers can alter the app's behavior through its resources by: - -- Modifying the app's files or resources on a compromised device. -- Tampering with backup contents and restoring the modified backup to a device. - -This can lead to: - - **Bypass of Protection Mechanisms**: Attackers can modify configuration or state files that drive security-relevant behavior, resulting in the circumvention of controls without modifying any code. - **Execution of Unauthorized Code**: Attackers can inject malicious content into resources the app renders or interprets (e.g. scripts or templates), resulting in attacker-controlled behavior inside the app. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0064.md b/weaknesses/MASVS-RESILIENCE/MASWE-0064.md index 0a3cc6b..3a9f517 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0064.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0064.md @@ -5,6 +5,8 @@ alias: runtime-code-integrity requirement: "The app verifies the integrity of its code." platform: [android, ios] profiles: [R] +threat: MAS-THREAT-0064 +attacks: [MAS-ATTACK-0002, MAS-ATTACK-0003] mappings: masvs-v1: [MSTG-RESILIENCE-6] masvs-v2: [MASVS-RESILIENCE-2] @@ -28,13 +30,6 @@ Even a correctly signed app can be modified while it runs: attackers can patch i ## Impact -Attackers can modify the app's code while it runs by: - -- Using dynamic instrumentation. -- Debugging the app at runtime. - -This can lead to: - - **Bypass of Protection Mechanisms**: Attackers can patch or hook the functions implementing the app's security checks, resulting in the circumvention of its client-side defenses. - **Compromise of Sensitive Data**: Attackers can redirect or wrap data-handling functions to siphon their inputs and outputs, resulting in exposure of credentials and user data processed by the app. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0076.md b/weaknesses/MASVS-RESILIENCE/MASWE-0076.md index d4efa6b..afacef8 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0076.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0076.md @@ -5,6 +5,8 @@ alias: malware-detection requirement: "The app detects attacks by malware." platform: [android, ios] profiles: [R] +threat: MAS-THREAT-0076 +attacks: [MAS-ATTACK-0036, MAS-ATTACK-0052] mappings: masvs-v2: [MASVS-RESILIENCE-2] cwe: [693] @@ -28,13 +30,6 @@ Mobile malware commonly attacks other apps indirectly: abusing accessibility ser ## Impact -Attackers can target the app with malware running on the same device by: - -- Harvesting on-screen content through a malicious accessibility service the user was tricked into enabling. -- Displaying overlays or tampering with the UI to alter what the user sees while approving an action. - -This can lead to: - - **Compromise of Sensitive Data**: Malware can capture credentials, one-time codes, and displayed content while the app takes no protective action, resulting in exposure of user data the app could have defended. - **Financial Loss**: Malware can automate or manipulate transactions against the unprotected app, resulting in direct financial harm to users and fraud losses for the app owner. diff --git a/weaknesses/MASVS-STORAGE/MASWE-0001.md b/weaknesses/MASVS-STORAGE/MASWE-0001.md index 4b5794f..5227f8e 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0001.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0001.md @@ -5,6 +5,8 @@ alias: data-in-logs requirement: "The app excludes sensitive data from application logs." platform: [android, ios] profiles: [L1, L2, P] +threat: MAS-THREAT-0001 +attacks: [MAS-ATTACK-0005, MAS-ATTACK-0006] mappings: masvs-v1: [MSTG-STORAGE-7] masvs-v2: [MASVS-STORAGE-2, MASVS-PRIVACY-1] @@ -33,13 +35,6 @@ Logging all possible information is very useful at development time, especially ## Impact -Attackers can access sensitive data written to logs by: - -- Accessing the system logs on a compromised device or from an app holding log-access permissions. -- Accessing the device storage on a compromised device. - -This can lead to: - - **Compromise of Sensitive Data**: Attackers can read passwords, credit card numbers, or PII from log output, resulting in unauthorized disclosure of user data and enabling further attacks such as identity theft. - **Authentication or Authorization Bypass**: Attackers can reuse leaked credentials or session tokens, resulting in unauthorized access to the user's account and the app's backend services. diff --git a/weaknesses/MASVS-STORAGE/MASWE-0002.md b/weaknesses/MASVS-STORAGE/MASWE-0002.md index 18206a9..69b8eb2 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0002.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0002.md @@ -5,6 +5,8 @@ alias: data-not-excluded-backup requirement: "The app excludes sensitive data from backups." platform: [android, ios] profiles: [L1, L2, P] +threat: MAS-THREAT-0002 +attacks: [MAS-ATTACK-0008, MAS-ATTACK-0009] mappings: masvs-v1: [MSTG-STORAGE-8] masvs-v2: [MASVS-STORAGE-2, MASVS-PRIVACY-1] @@ -34,13 +36,6 @@ iOS and Android automatically back up app data to cloud services, users can crea ## Impact -Attackers can extract or tamper with sensitive data included in backups by: - -- Extracting local or cloud backups of the device. -- Tampering with backup contents and restoring the modified backup to a device. - -This can lead to: - - **Compromise of Sensitive Data**: Attackers can extract personal information, photos, documents, or audio files from backups, resulting in unauthorized disclosure of user data. - **Authentication or Authorization Bypass**: Attackers can extract passwords, cryptographic keys, and session tokens from backups, resulting in identity theft, account takeover, or unauthorized access to backend services. - **Bypass of Protection Mechanisms**: Attackers can modify backed-up app state, e.g. a database tracking premium features, or restore a pre-redemption backup to reuse one-time coupons, resulting in circumvention of business logic and revenue loss for the app owner. diff --git a/weaknesses/MASVS-STORAGE/MASWE-0003.md b/weaknesses/MASVS-STORAGE/MASWE-0003.md index 672529a..6c38580 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0003.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0003.md @@ -5,6 +5,8 @@ alias: data-unencrypted-private-storage requirement: "The app encrypts sensitive data stored in private storage." platform: [android, ios] profiles: [L2] +threat: MAS-THREAT-0003 +attacks: [MAS-ATTACK-0005, MAS-ATTACK-0007, MAS-ATTACK-0008] mappings: masvs-v1: [MSTG-STORAGE-2] masvs-v2: [MASVS-STORAGE-1, MASVS-STORAGE-2, MASVS-CRYPTO-2, MASVS-PRIVACY-1] @@ -36,14 +38,6 @@ Sensitive data may include personally identifiable information (PII), passwords, ## Impact -Attackers can access sensitive data stored unencrypted in private storage by: - -- Accessing the device storage on a compromised device. -- Accessing files exposed through incorrect file permissions or misconfigured content providers. -- Extracting local or cloud backups of the device. - -This can lead to: - - **Compromise of Sensitive Data**: Attackers can extract PII and other user data from the application sandbox, resulting in unauthorized disclosure and enabling further attacks such as identity theft. - **Authentication or Authorization Bypass**: Attackers can extract passwords, cryptographic keys, or session tokens, resulting in account takeover or unauthorized access to protected functionality. diff --git a/weaknesses/MASVS-STORAGE/MASWE-0004.md b/weaknesses/MASVS-STORAGE/MASWE-0004.md index 08e8df7..3d4b755 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0004.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0004.md @@ -5,6 +5,8 @@ alias: data-unencrypted-shared-storage-no-user-interaction requirement: "The app encrypts sensitive data stored outside of private storage." platform: [android] profiles: [L1, L2] +threat: MAS-THREAT-0004 +attacks: [MAS-ATTACK-0010, MAS-ATTACK-0011] mappings: masvs-v1: [MSTG-STORAGE-2] masvs-v2: [MASVS-STORAGE-1, MASVS-STORAGE-2] @@ -37,13 +39,6 @@ This weakness primarily concerns Android, which permits the use of shared and ex ## Impact -Attackers can access or tamper with sensitive data stored in shared or external storage by: - -- Accessing shared or external storage from any app holding the corresponding permissions. -- Physically removing and reading external storage media such as SD cards. - -This can lead to: - - **Compromise of Sensitive Data**: Attackers can extract personal information and media such as photos, documents, and audio files, resulting in unauthorized disclosure of user data. - **Authentication or Authorization Bypass**: Attackers can extract passwords, cryptographic keys, and session tokens, resulting in identity theft or account takeover. - **Bypass of Protection Mechanisms**: Attackers can tamper with data used by the app, e.g. a database describing the state of premium features, resulting in circumvention of business logic and revenue loss for the app owner. diff --git a/weaknesses/MASVS-STORAGE/MASWE-0005.md b/weaknesses/MASVS-STORAGE/MASWE-0005.md index 68929c4..d9cd2a4 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0005.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0005.md @@ -5,6 +5,8 @@ alias: crypto-keys-not-protected-at-rest requirement: "The app stores cryptographic keys inside the platform-provided secure keystore." platform: [android, ios] profiles: [L1, L2] +threat: MAS-THREAT-0005 +attacks: [MAS-ATTACK-0001, MAS-ATTACK-0005, MAS-ATTACK-0008] mappings: masvs-v1: [MSTG-STORAGE-1, MSTG-CRYPTO-1] masvs-v2: [MASVS-STORAGE-1, MASVS-CRYPTO-2] @@ -34,14 +36,6 @@ Cryptographic keys are essential for securing sensitive data in mobile applicati ## Impact -Attackers can extract cryptographic keys stored outside the platform keystore by: - -- Obtaining the app package and reverse engineering it. -- Accessing the device storage on a compromised device. -- Extracting local or cloud backups of the device. - -This can lead to: - - **Compromise of Sensitive Data**: Attackers can decrypt protected information or forge encrypted data, resulting in unauthorized disclosure or modification of sensitive data. - **Authentication or Authorization Bypass**: Attackers can create valid cryptographic values or impersonate trusted parties, resulting in unauthorized access to protected accounts, data, or functionality. diff --git a/weaknesses/MASVS-STORAGE/MASWE-0006.md b/weaknesses/MASVS-STORAGE/MASWE-0006.md index b291281..b8f7408 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0006.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0006.md @@ -5,6 +5,8 @@ alias: data-hardcoded-app-package requirement: "The app does not hardcode sensitive data in the application package." platform: [android, ios] profiles: [L1, L2] +threat: MAS-THREAT-0006 +attacks: [MAS-ATTACK-0001] mappings: masvs-v1: [MSTG-STORAGE-1, MSTG-CODE-2] masvs-v2: [MASVS-STORAGE-1] @@ -36,12 +38,6 @@ Note that developer _debug_ artifacts (verbose logging, backdoors, testing utili ## Impact -Attackers can extract hardcoded secrets, credentials, and internal information by: - -- Obtaining the app package and reverse engineering it. - -This can lead to: - - **Financial Loss**: Attackers can abuse compromised API keys to make unauthorized billed API calls (e.g., AI/ML services), resulting in unexpected charges to the app owner. - **Compromise of System Integrity and Business Operations**: Attackers can use extracted credentials to access backend services, resulting in service disruption, policy-violation suspensions, or denial of service. - **Compromise of Sensitive Data**: Attackers can use extracted cryptographic material to decrypt protected data, resulting in unauthorized disclosure of user or app data. From 7ba662cd9612c73fffa01251917e1c882b7f2ae2 Mon Sep 17 00:00:00 2001 From: Carlos Holguera Date: Wed, 22 Jul 2026 19:11:40 +0200 Subject: [PATCH 15/70] Apply suggestions from code review Co-authored-by: Carlos Holguera --- weaknesses/MASVS-PRIVACY/MASWE-0073.md | 5 ----- 1 file changed, 5 deletions(-) diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0073.md b/weaknesses/MASVS-PRIVACY/MASWE-0073.md index 64bca18..181b924 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0073.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0073.md @@ -28,8 +28,6 @@ Platforms increasingly require apps to declare their tracking domains so the sys ## Modes of Introduction - **Missing or Incomplete Declarations**: Not declaring tracking domains at all, or declaring only a subset of the domains the app actually contacts for tracking purposes. -- **Undeclared Third-Party SDK Domains**: Omitting tracking domains contacted by embedded third-party SDKs, whose network behavior the developer may not have audited. -- **Declarations Inconsistent with Behavior**: Declaring domains that do not match the app's observed network connections, e.g. after adding new tracking endpoints without updating the manifest. ## Impact @@ -40,6 +38,3 @@ Platforms increasingly require apps to declare their tracking domains so the sys ## Mitigations - **Declare All Tracking Domains**: Enumerate every domain used for tracking, including those contacted by third-party SDKs, in the platform's declaration mechanism (e.g. the privacy manifest's `NSPrivacyTrackingDomains`). -- **Audit Network Behavior**: Regularly capture and review the app's network traffic to verify that its actual connections match the declared tracking domains. -- **Track SDK Changes**: Re-review declarations when adding or updating SDKs, using the SDKs' own privacy manifests where provided. -- **Respect the User's Tracking Choice**: Gate all tracking activity on the user's platform-level tracking permission rather than relying on enforcement alone (see @MASWE-0066). From 584fe051dcaa94b842b507d3d5f23156e73438f4 Mon Sep 17 00:00:00 2001 From: Carlos Holguera Date: Wed, 22 Jul 2026 19:40:10 +0200 Subject: [PATCH 16/70] Apply suggestions from code review Co-authored-by: Carlos Holguera --- weaknesses/MASVS-PRIVACY/MASWE-0065.md | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0065.md b/weaknesses/MASVS-PRIVACY/MASWE-0065.md index 31a7a05..a7d9882 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0065.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0065.md @@ -16,6 +16,8 @@ refs: - https://gdpr-info.eu/recitals/no-26/ - https://gdpr-info.eu/recitals/no-28/ - https://gdpr-info.eu/art-4-gdpr/ +- +https://www.edpb.europa.eu/topics/ai-and-technology/anonymisation-pseudonymisation_en - https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2014/wp216_en.pdf - https://www.statista.com/topics/9460/app-tracking-and-mobile-privacy/ status: new @@ -25,12 +27,15 @@ status: new This weakness occurs when an app processes or shares user data without applying unlinkability techniques such as data abstraction, anonymization, or pseudonymization, allowing individuals to be identified and tracked across different services and over time. -Anonymization, through methods like randomization or generalization, irreversibly de-identifies individuals by removing or altering data, such as obfuscating location or scrambling sensitive attributes. In contrast, pseudonymization replaces identifiable data with tokens or hashed values, making it more secure but still technically reversible under certain conditions. +This weakness occurs when an app processes or shares user data without applying privacy measures such as data abstraction, anonymization, pseudonymization, or unlinkability protocols. This can allow individuals to be identified and tracked across services and over time. + +Anonymization uses techniques such as randomization or generalization to irreversibly prevent identification. Pseudonymization replaces identifiable data with tokens or hashed values, but may remain reversible when additional information is available. Privacy preserving protocols can provide further unlinkability. [Private Information Retrieval (PIR)](https://en.wikipedia.org/wiki/Private_information_retrieval) hides which data a user retrieves, while [Oblivious HTTP (OHTTP)](https://www.ietf.org/rfc/rfc9458.html) separates the user identity from the request content. ## Modes of Introduction -- **Direct Identifiers Not Removed**: Failing to remove or transform direct identifiers, such as user ID or name, before server-side collection, or to manipulate the data to prevent linkage to real-world identities. This also includes not implementing protocols like Private Information Retrieval or Oblivious HTTP (OHTTP) to enhance privacy. -- **Sensitive Data Not Redacted Before Passing to AI**: Sending unredacted sensitive or personal data to AI/ML services (on-device or cloud) without first removing or masking identifiers, where it may also be retained and used to train models. +- **Direct Identifiers Not Removed**: Failing to remove or transform direct identifiers, such as user ID or name, before server-side collection, or to manipulate the data to prevent linkage to real-world identities. +- **Not Implementing Privacy-Preserving Protocols**: Failing to use protocols such as PIR or OHTTP. +- **Sensitive Data Not Redacted Before Passing to AI**: Sending unredacted sensitive or personal data to AI services without first removing or masking identifiers, where it may also be retained and used to train models. ## Impact @@ -40,4 +45,5 @@ Anonymization, through methods like randomization or generalization, irreversibl ## Mitigations - **Use Anonymisation and Pseudonymisation**: Ensure techniques like anonymisation and pseudonymisation are implemented to prevent user identification. -- **Redact Sensitive Data Before Passing to AI**: Before sending data to AI/ML services, redact or mask sensitive fields and identifiers so that personal data is not exposed to (or used to train) third-party models. +- **Implement Privacy-Preserving Protocols**: Use protocols such as PIR or OHTTP. +- **Redact Sensitive Data Before Passing to AI**: Before sending data to AI services, redact or mask sensitive fields and identifiers so that personal data is not exposed to (or used to train) third-party models. From 1af7ac50b6e469f728c1acd02722523976d951e4 Mon Sep 17 00:00:00 2001 From: Carlos Holguera Date: Wed, 22 Jul 2026 19:51:42 +0200 Subject: [PATCH 17/70] Apply suggestion from @cpholguera --- weaknesses/MASVS-PRIVACY/MASWE-0067.md | 1 - 1 file changed, 1 deletion(-) diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0067.md b/weaknesses/MASVS-PRIVACY/MASWE-0067.md index 3613f5d..4fa747a 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0067.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0067.md @@ -40,4 +40,3 @@ Privacy policies should be easily accessible, tailored specifically to the app i - **Provide a Clear Privacy Policy**: Make sure a comprehensive and understandable privacy policy is readily accessible to users. Tailor it to the specific data practices of your app and write it in clear, understandable language as stated in Article 12 of the GDPR. - **Ensure Consistency in Policy vs Behavior**: Keep your data collection practices documented and up to date in privacy policies, privacy labels, and app store listings. Ensure that these documents match the app's actual behavior to avoid discrepancies that could mislead users or violate platform policies. -- **Regularly Review and Update Privacy Policy**: Regularly review and update the privacy policy to reflect any changes in data collection practices, new features, or modifications to existing features that may impact how user data is handled. From ed5a21a57482f344641e736ea8973781cea9c7a4 Mon Sep 17 00:00:00 2001 From: Carlos Holguera Date: Thu, 23 Jul 2026 09:40:08 +0200 Subject: [PATCH 18/70] Apply suggestion from @cpholguera --- weaknesses/MASVS-PRIVACY/MASWE-0066.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0066.md b/weaknesses/MASVS-PRIVACY/MASWE-0066.md index 100be4f..b5c68ae 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0066.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0066.md @@ -40,7 +40,7 @@ Unique identifiers, especially those that cannot be reset, are a key enabler of ## Modes of Introduction -- **Use of Non-Resettable Identifiers**: Utilizing identifiers that cannot be reset by the user, such as device IDs, hardware serial numbers, or MAC addresses. For example, the [ANDROID_ID](https://developer.android.com/reference/android/provider/Settings.Secure#ANDROID_ID) before Android 8.0 (API level 26) was a non-resettable identifier randomly generated at first boot, while in recent versions it's unique to each combination of app-signing key, user, and device. +- **Use of Non-Resettable Identifiers**: Utilizing identifiers that cannot be reset by the user, such as device IDs, hardware serial numbers, or MAC addresses. For example, the [`ANDROID_ID`](https://developer.android.com/reference/android/provider/Settings.Secure#ANDROID_ID) before Android 8.0 (API level 26) was a non-resettable identifier randomly generated at first boot, while in recent versions it's unique to each combination of app-signing key, user, and device. - **Misuse of Resettable Identifiers**: Using [resettable identifiers](https://developer.android.com/privacy-and-security/about#resettable-identifiers) like the [Advertising ID](https://developer.android.com/identity/user-data-ids#advertising-ids) on Android or the [Advertising Identifier (aka. Identifier for Advertisers or IDFA)](https://developer.apple.com/documentation/adsupport/asidentifiermanager/advertisingidentifier) on iOS without respecting user preferences or obtaining proper consent. - **Linking Identifiers Across Services**: Combining identifiers from different sources, such as device IDs, advertising IDs, or other unique identifiers as well as behavioral data, to create a unified profile of a user, even after a reset or reinstall. - **Tracking Without User Consent**: Tracking users across services or apps without their explicit consent or without providing the ability to opt out or reset identifiers. For instance, on iOS, access to the IDFA requires explicit user consent under the [App Tracking Transparency (ATT) framework](https://developer.apple.com/documentation/AppTrackingTransparency). The IDFV can track users across apps by the same vendor without explicit consent but resets when all of the vendor's apps are removed from the device. From 58f765f211c81ab52bed01aa197085e4ba25f19d Mon Sep 17 00:00:00 2001 From: Carlos Holguera Date: Thu, 23 Jul 2026 09:46:54 +0200 Subject: [PATCH 19/70] Apply suggestions from code review Co-authored-by: Carlos Holguera --- weaknesses/MASVS-PRIVACY/MASWE-0068.md | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0068.md b/weaknesses/MASVS-PRIVACY/MASWE-0068.md index 98632d0..09fbc9d 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0068.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0068.md @@ -36,8 +36,7 @@ These declarations must clearly outline what data is collected, how it is used, ## Modes of Introduction - **Undeclared Data Collection and Purpose**: Failing to declare what data is being collected (e.g., location, contacts, identifiers) and for what purposes (e.g., analytics, personalization). -- **Discrepancies in Declarations vs Behavior**: Publishing privacy label declarations (such as Apple's Privacy Nutrition Labels or Google's Data Safety Section) that differ from the app's actual behavior, including undeclared data collection, sharing with third parties not mentioned in privacy labels, or using data for purposes not disclosed, which are against both Apple and Google guidelines. -- **Undeclared Data Sent in Network Traffic**: Transmitting data over the network, even over HTTPS, that goes beyond what is declared, such as over-collection beyond functional needs, detailed location/behavior analytics, unnecessary identifiers (e.g. IMEI, email, phone number), or sharing with third-party analytics/advertising services not reflected in the declarations. +- **Discrepancies in Declarations vs Behavior**: Publishing declarations that differ from the app's actual behavior by using data for purposes other than those disclosed. ## Impact @@ -47,5 +46,4 @@ These declarations must clearly outline what data is collected, how it is used, ## Mitigations -- **Maintain Accurate Privacy Labels**: Comply with Apple's Privacy Nutrition Labels and Google's Data Safety Section requirements by providing accurate and transparent information about your data practices, including data collection and sharing with third parties. -- **Ensure Consistency in Declarations vs Behavior**: Keep your data collection practices documented and up to date in privacy policies, privacy labels, and app store listings. Ensure that these documents match the app's actual behavior to avoid discrepancies that could mislead users or violate platform policies. +- **Maintain Accurate Privacy Labels**: Comply with Apple's Privacy Nutrition Labels and Google's Data Safety Section requirements by providing accurate, up to date and transparent information about your data practices, including data collection and sharing with third parties. From 22c7e27b3b31d4d0e03d20b8746d55aec493a31e Mon Sep 17 00:00:00 2001 From: Carlos Holguera Date: Sun, 26 Jul 2026 10:09:17 +0200 Subject: [PATCH 20/70] Apply suggestions from code review Co-authored-by: Stefan Co-authored-by: Carlos Holguera --- weaknesses/MASVS-AUTH/MASWE-0017.md | 18 +++++++++++++----- weaknesses/MASVS-AUTH/MASWE-0018.md | 9 +++++---- 2 files changed, 18 insertions(+), 9 deletions(-) diff --git a/weaknesses/MASVS-AUTH/MASWE-0017.md b/weaknesses/MASVS-AUTH/MASWE-0017.md index f0c31b2..0993de4 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0017.md +++ b/weaknesses/MASVS-AUTH/MASWE-0017.md @@ -16,9 +16,7 @@ mappings: refs: - https://developer.apple.com/documentation/localauthentication - https://auth0.com/blog/what-is-step-up-authentication-when-to-use-it/ -- https://tdcolvin.medium.com/is-firebase-auth-secure-dace0563d41b -- https://github.com/WICG/trust-token-api -- https://blog.cloudflare.com/eliminating-captchas-on-iphones-and-macs-using-new-standard/ +- https://pages.nist.gov/800-63-4/sp800-63b.html status: new --- @@ -26,12 +24,22 @@ status: new This weakness occurs when an app allows sensitive actions to be performed within an already authenticated session without requiring the user to re-confirm their identity. -Step-up authentication requires the user to re-authenticate or provide an additional authentication factor before performing a sensitive action, even within an active session. For example, a user logged into their bank account who requests a large transfer should be required to re-confirm their identity (e.g. via biometrics or a second factor) so that only the legitimate user can complete the action. Without it, whoever holds the active session, not necessarily the legitimate user, can perform every operation the account allows. +Step-up authentication requires the user to re-authenticate or provide an additional authentication factor before performing a sensitive action, even within an active session. + +For example, a user logged into their bank account who requests a large transfer to an unknown payee should be required to re-confirm their identity (e.g. via biometrics or a second factor) so that only the legitimate user can complete the action. Without it, whoever holds the active session, not necessarily the legitimate user, can perform every operation the account allows. + +Depending on the context, other sensitive actions may include: + +- Changing account data such as password, email address or phone number +- Elevating a user role +- Disabling security features such as multifactor authentication (MFA) +- Displaying sensitive data such as credit card number / PAN ## Modes of Introduction - **No Re-Authentication for Sensitive Actions**: Allowing high-risk operations, such as payments, credential or profile changes, or the display of sensitive personal data, with only the assurance of the initial login. - **Step-Up Not Bound to the Action**: Implementing a re-authentication challenge that is not tied to the specific transaction being approved, so a single approval can be reused for a different or modified action. +- **Step-Up Not Enforced Server-Side**: Step-up authentication is only performed by app and not by the server. - **Uniform Assurance Level**: Designing all functionality behind a single login assurance level without classifying operations by risk. ## Impact @@ -42,7 +50,7 @@ Step-up authentication requires the user to re-authenticate or provide an additi ## Mitigations +- **Classify Actions by Risk**: Define which operations require step-up authentication and match the required assurance level to the sensitivity of each action. - **Require Step-Up for Sensitive Actions**: Re-authenticate the user, e.g. with biometrics bound to a keystore-protected key or an additional factor, before executing high-risk operations or displaying highly sensitive data. - **Bind the Challenge to the Action**: Tie the step-up challenge cryptographically to the specific transaction (e.g. transaction signing), so an approval cannot be replayed or applied to a different action. -- **Classify Actions by Risk**: Define which operations require step-up authentication and match the required assurance level to the sensitivity of each action. - **Enforce Step-Up Server-Side**: Have the server require and verify step-up evidence before executing the action, rather than trusting a client-side check. diff --git a/weaknesses/MASVS-AUTH/MASWE-0018.md b/weaknesses/MASVS-AUTH/MASWE-0018.md index 6bbdae6..1e73cd2 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0018.md +++ b/weaknesses/MASVS-AUTH/MASWE-0018.md @@ -1,7 +1,7 @@ --- title: Sensitive Data Accessible After Session Termination id: MASWE-0018 -alias: reauth-state-changes +alias: session-termination requirement: "The app makes sensitive data inaccessible after session termination." platform: [android, ios] profiles: [L2] @@ -12,7 +12,7 @@ mappings: cwe: [285, 287, 613] maswe-beta: [MASWE-0030] refs: -- https://developers.google.com/identity/sign-in/android/disconnect +- https://developer.android.com/identity/sign-in/credential-manager-siwg-implementation#handle-sign-out - https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html status: new --- @@ -25,8 +25,9 @@ Session termination is not limited to the user tapping "log out": inactivity tim ## Modes of Introduction -- **Sessions Not Invalidated**: Terminating sessions only client-side, leaving session tokens valid on the server after logout or timeout. -- **No Re-Authentication on State Changes**: Resuming the app from the background or continuing after remarkable context changes (e.g. a significant change in the user's location or profile) without requiring re-authentication. +- **Sessions Not Invalidated Server-Side**: Terminating sessions only client-side, leaving session tokens valid on the server after logout or timeout. +- **Missing Client-Side Session Termination**: The app provides no way to terminate user sessions (e.g. no logout button or timeout). +- **No Re-Authentication on State Changes**: Resuming the app from the background or continuing after remarkable context changes (e.g. a significant change in the user's location or profile) without invalidating the current session and requiring re-authentication. - **Cached Data Not Cleared**: Retaining session tokens, cached personal data, in-memory state, or on-screen content after the session ends. - **Missing Inactivity Timeout**: Allowing sessions to remain valid indefinitely without inactivity or absolute expiration limits. From 4ea9a482a1e61adca19c8c5b504b9d639fd394f0 Mon Sep 17 00:00:00 2001 From: Carlos Holguera Date: Sun, 26 Jul 2026 10:22:17 +0200 Subject: [PATCH 21/70] Apply suggestions from code review Co-authored-by: Sven --- weaknesses/MASVS-NETWORK/MASWE-0025.md | 15 ++++++--------- weaknesses/MASVS-NETWORK/MASWE-0026.md | 6 +++--- weaknesses/MASVS-NETWORK/MASWE-0027.md | 4 ++-- 3 files changed, 11 insertions(+), 14 deletions(-) diff --git a/weaknesses/MASVS-NETWORK/MASWE-0025.md b/weaknesses/MASVS-NETWORK/MASWE-0025.md index db75773..24fc542 100644 --- a/weaknesses/MASVS-NETWORK/MASWE-0025.md +++ b/weaknesses/MASVS-NETWORK/MASWE-0025.md @@ -8,9 +8,9 @@ profiles: [L1, L2] threat: MAS-THREAT-0025 attacks: [MAS-ATTACK-0012, MAS-ATTACK-0013, MAS-ATTACK-0014] mappings: - masvs-v1: [MSTG-NETWORK-2, MSTG-NETWORK-1] + masvs-v1: [MSTG-NETWORK-1, MSTG-NETWORK-2] masvs-v2: [MASVS-NETWORK-1] - cwe: [311, 319] + cwe: [319] android-risks: - cleartext-communications - insecure-machine-to-machine @@ -25,14 +25,12 @@ refs: - https://developer.apple.com/forums/thread/707320 - https://developer.android.com/privacy-and-security/security-best-practices#secure-communication - https://developer.android.com/privacy-and-security/security-tips#networking -- https://developer.android.com/privacy-and-security/security-config#CleartextTrafficPermitted +- https://developer.android.com/privacy-and-security/security-config#CleartextTraffic - https://developer.android.com/reference/javax/net/ssl/SSLSocket - https://developer.android.com/reference/android/security/NetworkSecurityPolicy#isCleartextTrafficPermitted() - https://developer.android.com/reference/java/net/Socket - https://developer.android.com/reference/android/webkit/WebView - https://developer.android.com/reference/javax/net/ssl/HttpsURLConnection -- https://github.com/MicrosoftDocs/xamarin-docs/blob/live/docs/android/app-fundamentals/http-stack.md -- https://github.com/MicrosoftDocs/xamarin-docs/blob/live/docs/ios/app-fundamentals/ats.md status: new --- @@ -49,9 +47,8 @@ Secure network protocols not only provide confidentiality but also ensure data i - **Cleartext Traffic Allowed in Platform-Provided Settings**: Configuring platform-provided settings (e.g. Network Security Configuration on Android or App Transport Security on iOS) to explicitly allow cleartext traffic (globally or per-domain), making it the default behavior for all network connections managed by those settings. - **Usage of HTTP**: Using HTTP instead of HTTPS for communication, which does not encrypt data in transit. - **Usage of Non-HTTP Insecure Protocols**: Using insecure protocols such as FTP, SMTP without TLS, TCP sockets, or custom protocols which do not encrypt data in transit. -- **Unencrypted Non-IP Interfaces**: Transferring data over local/proximity interfaces such as Bluetooth/BLE, NFC, USB, or Wi-Fi Direct without encryption. These machine-to-machine channels are often overlooked. -- **Authentication Material over Insecure Channels**: Sending session IDs, tokens, passwords, or API keys over any of the above unencrypted channels. -- **Usage of Low-Level Network APIs**: Using low-level network APIs that do not enforce encryption and do not honor the platform's network security settings, such as `Socket` on Android or `NSURLConnection` on iOS. +- **Unencrypted Machine-to-Machine Channels**: Transferring data over local/proximity interfaces such as Bluetooth/BLE, NFC, USB, or Wi-Fi Direct without encryption, or relying solely on link-layer protection such as BLE "Just Works" pairing instead of application-layer encryption. +- **Usage of Low-Level Network APIs**: Using low-level network APIs that do not enforce encryption and do not honor the platform's network security settings, such as [`Socket`](https://developer.android.com/reference/java/net/Socket) on Android or [`NWConnection`](https://developer.apple.com/documentation/network/nwconnection) on iOS. - **Cross-Platform Framework Misconfiguration**: Configuring cross-platform frameworks improperly so that cleartext traffic is allowed for both Android and iOS versions of an app. - **Third-Party Libraries**: Using third-party libraries or SDKs that default to insecure communication methods or are improperly configured. @@ -60,7 +57,7 @@ Secure network protocols not only provide confidentiality but also ensure data i - **Compromise of Sensitive Data**: Attackers can capture, read, or alter sensitive information transmitted over the network, resulting in unauthorized disclosure or manipulation of user data. - **Authentication or Authorization Bypass**: Attackers can capture session tokens or credentials sent over cleartext channels, resulting in user impersonation and unauthorized access to accounts or backend systems. - **Compromise of System Integrity and Business Operations**: Attackers can inject malicious content or redirect users to impersonated services, resulting in altered app behavior, phishing, and reputational damage for the app owner. -- **Legal and Regulatory Non-Compliance**: Exposing personal data in transit can violate laws such as GDPR or HIPAA, resulting in legal penalties and mandatory disclosures for the app owner. +- **Legal and Regulatory Non-Compliance**: Attackers can capture personal data in transit, resulting in reportable breaches and regulatory penalties for the app owner under laws such as GDPR or HIPAA. ## Mitigations diff --git a/weaknesses/MASVS-NETWORK/MASWE-0026.md b/weaknesses/MASVS-NETWORK/MASWE-0026.md index 119461a..3fa1809 100644 --- a/weaknesses/MASVS-NETWORK/MASWE-0026.md +++ b/weaknesses/MASVS-NETWORK/MASWE-0026.md @@ -1,7 +1,7 @@ --- title: Insecure Certificate Validation id: MASWE-0026 -alias: insecure-cert-val +alias: insecure-cert-validation requirement: "The app validates certificates for all network traffic." platform: [android, ios] profiles: [L1, L2] @@ -22,7 +22,6 @@ refs: - https://support.google.com/faqs/answer/7071387?hl=en - https://developer.android.com/reference/android/webkit/WebViewClient.html?sjid=15211564825735678155-EU#onReceivedSslError(android.webkit.WebView,%20android.webkit.SslErrorHandler,%20android.net.http.SslError) - https://developer.android.com/privacy-and-security/security-ssl#WarningsSslSocket -- https://wiki.sei.cmu.edu/confluence/display/java/MSC00-J.+Use+SSLSocket+rather+than+Socket+for+secure+data+exchange - https://developer.apple.com/forums/thread/67493 - https://developer.apple.com/forums/thread/707320 - https://support.apple.com/en-us/102390 @@ -43,13 +42,14 @@ Certificate validation is the mechanism through which a TLS client establishes t - **Ignoring Hostname Verification**: Failing to verify that the certificate's hostname matches the server's hostname. - **Using Insecure Custom Trust Managers**: Implementing custom certificate validation logic that is incomplete, incorrect, or insecure. - **Incorrect Error Handling**: Proceeding with connections even when certificate validation errors occur, without alerting the user or terminating the connection. -- **Trusting All Certificates**: Configuring the application to trust all certificates by default, without any validation. +- **Third-Party Libraries**: Using third-party libraries or SDKs that disable or weaken certificate validation internally, or that default to permissive trust settings. ## Impact - **Compromise of Sensitive Data**: Attackers can capture, read, or alter sensitive information transmitted over the network, resulting in unauthorized disclosure or manipulation of user data. - **Authentication or Authorization Bypass**: Attackers can capture credentials or session tokens in transit, resulting in user impersonation and unauthorized access to accounts or backend systems. - **Compromise of System Integrity and Business Operations**: Attackers can impersonate legitimate servers and feed altered or malicious data to the app, resulting in unreliable or malicious app behavior and reputational damage for the app owner. +- **Legal and Regulatory Non-Compliance**: Attackers can capture personal data in transit, resulting in reportable breaches and regulatory penalties for the app owner under laws such as GDPR or HIPAA. ## Mitigations diff --git a/weaknesses/MASVS-NETWORK/MASWE-0027.md b/weaknesses/MASVS-NETWORK/MASWE-0027.md index 71f3a84..6cb995d 100644 --- a/weaknesses/MASVS-NETWORK/MASWE-0027.md +++ b/weaknesses/MASVS-NETWORK/MASWE-0027.md @@ -24,13 +24,13 @@ status: new This weakness occurs when identity pinning (also known as certificate pinning, public key pinning, or TLS pinning) is not implemented, or is implemented incorrectly, so the app cannot guarantee that it only communicates with servers presenting a specific, pre-determined cryptographic identity. -Identity pinning associates a mobile app with a specific certificate or public key, adding a layer of trust verification on top of standard certificate validation. This reduces the risk of unauthorized interception even if a trusted Certificate Authority (CA) is compromised. Without it, the app trusts any certificate that chains to any CA in the trust store, so a single compromised or coerced CA is enough to intercept its traffic. +Identity pinning associates a mobile app with a specific certificate or public key, adding a layer of trust verification on top of standard certificate validation. This reduces the risk of unauthorized interception even if a trusted Certificate Authority (CA) is compromised. Compromise of a public CA is rare, but pinning narrows trust to identities the app operator controls, and raises the effort required to intercept, inspect, or replay the app's traffic. Pinning is not foolproof: attackers who can reverse-engineer the app may remove or modify the pre-defined pins or the pinning logic, and attackers using runtime hooking and dynamic instrumentation may bypass the pinning checks on a device they control. This highlights the importance of implementing pinning **alongside other security measures** to enhance the app's resistance to advanced threats. ## Modes of Introduction -- **Improper Configuration of Pinning Libraries**: Misconfiguring libraries like TrustKit, OkHttp's `CertificatePinner`, Volley, or AFNetworking's `SSLPinningMode`, leading to ineffective pinning. +- **Improper Configuration of Pinning Libraries**: Misconfiguring libraries like TrustKit or OkHttp's `CertificatePinner` leading to ineffective pinning. - **Dynamic Pinning without Security**: Retrieving pins dynamically over insecure channels without proper validation. - **Improper Validation Logic**: Implementing custom pinning logic that does not correctly validate the certificate chain or public key. For example, accepting any certificate that chains to a trusted root CA instead of a specific certificate or public key. - **Lack of Backup Pins**: Not including backup pins, so the app cannot establish connections if the primary pin is no longer valid. From 6b22a11797665424f7f8b4af3049318590c65ec2 Mon Sep 17 00:00:00 2001 From: Carlos Holguera Date: Sun, 26 Jul 2026 10:34:21 +0200 Subject: [PATCH 22/70] Apply suggestions from code review Co-authored-by: Stefan Co-authored-by: Dionysis Lorentzos Co-authored-by: Carlos Holguera --- weaknesses/MASVS-CRYPTO/MASWE-0007.md | 12 ++++++++---- weaknesses/MASVS-CRYPTO/MASWE-0008.md | 4 ++-- weaknesses/MASVS-CRYPTO/MASWE-0009.md | 2 +- weaknesses/MASVS-CRYPTO/MASWE-0010.md | 6 ++++-- weaknesses/MASVS-CRYPTO/MASWE-0011.md | 8 ++++---- weaknesses/MASVS-CRYPTO/MASWE-0012.md | 2 +- weaknesses/MASVS-CRYPTO/MASWE-0013.md | 6 +++--- weaknesses/MASVS-CRYPTO/MASWE-0014.md | 2 +- weaknesses/MASVS-CRYPTO/MASWE-0015.md | 2 +- weaknesses/MASVS-CRYPTO/MASWE-0016.md | 4 ++-- 10 files changed, 27 insertions(+), 21 deletions(-) diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0007.md b/weaknesses/MASVS-CRYPTO/MASWE-0007.md index f2f17d8..2c898d4 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0007.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0007.md @@ -1,7 +1,7 @@ --- title: Improper Cryptographic Key Generation id: MASWE-0007 -alias: weak-crypto-key-generation +alias: improper-crypto-key-generation requirement: "The app securely generates cryptographic keys." platform: [android, ios] profiles: [L1, L2] @@ -10,7 +10,7 @@ attacks: [MAS-ATTACK-0018, MAS-ATTACK-0019, MAS-ATTACK-0020] mappings: masvs-v1: [MSTG-CRYPTO-2] masvs-v2: [MASVS-CRYPTO-2] - cwe: [331, 337, 338, 522] + cwe: [331, 326, 337, 338, 522] android-risks: - weak-prng android-core-app-quality: [Cryptographic_Algorithms] @@ -32,13 +32,16 @@ This weakness occurs when cryptographic keys are generated with insufficient len In cryptography, security strength is heavily influenced by how keys are generated. One critical aspect is the key size (key length), measured in bits, which must comply with current security best practices: algorithms used with insufficient key sizes are vulnerable to attack. Even with a sufficiently large key size, security can be compromised if the generation process is flawed. Failing to use strong, cryptographically secure pseudorandom number generators (CSPRNGs) with sufficient entropy can produce predictable keys that are easier for attackers to guess or reproduce. +Mobile platforms provide additional layers of protection for key material, such as generating and storing keys in secure hardware or key attestation. Failing to use these mechanisms where required results in weak key protection. + ## Modes of Introduction - **Insufficient Entropy**: Generating keys from a source of randomness with insufficient entropy or from predictable seeds. - **Insufficient Key Length**: Generating keys shorter than the lengths recommended by current standards for the chosen algorithm. - **Risky or Broken Algorithms**: Generating keys using deprecated, risky, or inherently broken cryptographic algorithms, which often only support weak key lengths. - **Insecure Key Export**: Exporting a key in plaintext when it must leave the secure environment in which it was created (for example, to be backed up or shared with another device), instead of "wrapping" it (encrypting it with another key) as specified in [NIST.SP.800-175Br1 5.3.5](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-175Br1.pdf), even when the key is sent over a secure channel. - +- **Insecure Key Properties**: Generating keys with properties such as an unspecified or overly broad purpose, insecure storage location (e.g. not using secure hardware if available) or access requirements (see @MASWE-0010). + ## Impact - **Compromise of Sensitive Data**: Attackers can decrypt protected information or forge encrypted data, resulting in unauthorized disclosure or modification of sensitive data. @@ -48,4 +51,5 @@ In cryptography, security strength is heavily influenced by how keys are generat - **Use Established Cryptographic Libraries**: Always use modern, well-established cryptographic libraries and APIs that follow best practices for entropy generation and key management. - **Wrap Keys Before Export**: When keys must be exported, protect them with key wrapping (e.g. AES Key Wrap or an equivalent authenticated scheme) so they are never exposed in plaintext outside a secure environment. -- **Use Sufficient Key Lengths**: Ensure that key lengths meet or exceed current standards for cryptographic security, such as 256-bit for AES encryption and 2048-bit for RSA (considering quantum computing attacks). See ["NIST Special Publication 800-57: Recommendation for Key Management: Part 1 – General"](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf), ["NIST Special Publication 800-131A: Transitioning the Use of Cryptographic Algorithms and Key Lengths"](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf), and ["BlueKrypt's Cryptographic Key Length Recommendation"](https://www.keylength.com/) for more information on cryptographic key sizes. +- **Use Sufficient Key Lengths**: Ensure that key lengths meet or exceed current standards for cryptographic security, such as 256-bit for AES encryption and 2048-bit for RSA (considering quantum computing attacks). See ["NIST Special Publication 800-57: Recommendation for Key Management: Part 1 – General"](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf), ["NIST Special Publication 800-131A: Transitioning the Use of Cryptographic Algorithms and Key Lengths"](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf), and ["BlueKrypt's Cryptographic Key Length Recommendation"](https://www.keylength.com/) for more information on cryptographic key sizes. +- **Key Attestation**: Use platform key attestation to obtain cryptographic proof that a key was generated and is stored inside secure hardware (e.g. a hardware-backed keystore, TEE, or Secure Element) with the expected properties. diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0008.md b/weaknesses/MASVS-CRYPTO/MASWE-0008.md index 3a64935..8d579b0 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0008.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0008.md @@ -1,7 +1,7 @@ --- title: Improper Cryptographic Key Derivation id: MASWE-0008 -alias: weak-crypto-key-derivation +alias: improper-crypto-key-derivation requirement: "The app derives cryptographic keys using approved key derivation functions." platform: [android, ios] profiles: [L1, L2] @@ -10,7 +10,7 @@ attacks: [MAS-ATTACK-0025, MAS-ATTACK-0026] mappings: masvs-v1: [MSTG-CRYPTO-2] masvs-v2: [MASVS-CRYPTO-2] - cwe: [326, 327, 916] + cwe: [326, 327, 759, 760, 916] maswe-beta: [MASWE-0010] refs: - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0009.md b/weaknesses/MASVS-CRYPTO/MASWE-0009.md index 623a39d..ff449de 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0009.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0009.md @@ -9,7 +9,7 @@ threat: MAS-THREAT-0009 attacks: [MAS-ATTACK-0001, MAS-ATTACK-0005] mappings: masvs-v2: [MASVS-CRYPTO-2] - cwe: [262, 324] + cwe: [324] maswe-beta: [MASWE-0011] refs: - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0010.md b/weaknesses/MASVS-CRYPTO/MASWE-0010.md index d728dac..02eb709 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0010.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0010.md @@ -9,7 +9,7 @@ threat: MAS-THREAT-0010 attacks: [MAS-ATTACK-0002, MAS-ATTACK-0003, MAS-ATTACK-0027] mappings: masvs-v2: [MASVS-CRYPTO-2, MASVS-AUTH-2, MASVS-AUTH-3] - cwe: [284] + cwe: [284, 306] maswe-beta: [MASWE-0018] refs: - https://developer.android.com/reference/android/security/keystore/KeyGenParameterSpec.Builder#setUnlockedDeviceRequired(boolean) @@ -25,7 +25,9 @@ status: new This weakness occurs when cryptographic keys can be used without restrictions on who may use them, under which device conditions, and for how long. -Platform keystores allow developers to bind key usage to strict conditions, such as requiring user authentication, requiring the device to be unlocked, binding the key to the current device, or limiting the validity of an authorization to a short period or a single operation. When these restrictions are not configured, any code running as the app, or any actor in possession of the device, can use the keys freely. This applies even to keys generated inside a hardware security module such as Android StrongBox or the iOS Secure Enclave: hardware backing protects the key material from extraction, but usage restrictions must still be configured explicitly. +Platform keystores allow developers to bind key usage to strict conditions, such as requiring user authentication, requiring the device to be unlocked, binding the key to the current device, or limiting the validity of an authorization to a short period or a single operation. + +When these restrictions are not configured, any code running as the app, or any actor in possession of the unlocked device, can use the keys freely. This applies even to keys generated inside a hardware security module such as Android StrongBox or the iOS Secure Enclave: hardware backing protects the key material from extraction, but usage restrictions must still be configured explicitly. ## Modes of Introduction diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0011.md b/weaknesses/MASVS-CRYPTO/MASWE-0011.md index 58fe581..66b4016 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0011.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0011.md @@ -1,7 +1,7 @@ --- title: Improper Encryption id: MASWE-0011 -alias: weak-encryption +alias: improper-encryption requirement: "The app properly encrypts sensitive data." platform: [android, ios] profiles: [L1, L2] @@ -34,10 +34,10 @@ Encryption is only as strong as its weakest component: the algorithm, the mode o ## Modes of Introduction -- **Broken Algorithms**: Relying on broken encryption algorithms (i.e., that are deprecated or disallowed by NIST or other standards) such as RC4. +- **Broken Algorithms**: Relying on broken encryption algorithms (i.e., that are deprecated or disallowed by NIST or other standards) such as RC4, DES, or 3DES. - **Predictable or Reused Initialization Vectors (IVs)**: Using IVs that are hardcoded, null, predictable, or reused in modes like AES-CBC or AES-CTR, or reusing nonces or using authentication tags of insufficient length in AEAD modes like AES-GCM. - **Risky Padding**: Using a padding scheme susceptible to padding oracle attacks (e.g. PKCS#7 with unauthenticated AES-CBC, or PKCS#1 v1.5 for RSA) in combination with observable padding-error signals. -- **Broken Modes of Operation**: Using modes that are considered broken. For example, AES-ECB is broken due to practical known-plaintext attacks and is disallowed by NIST. +- **Broken Modes of Operation**: Using modes that are considered broken. For example, NIST disallows AES-ECB because it is deterministic, meaning identical plaintext blocks yield identical ciphertext blocks, which leaks data patterns. - **Insufficient Key Length**: Using key sizes below current recommendations for the chosen algorithm. - **Insecure or Wrong Key Usage**: Reusing a single key for multiple purposes (e.g. encryption and signing) or with an unauthorized algorithm, violating key-separation principles. Per [NIST.SP.800-57pt1r5](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf), a single key should be used for only one purpose. - **Non-Cryptographic Operations**: Relying on techniques such as XOR, Base64 encoding, or simple obfuscation methods for security purposes. These methods provide no actual encryption. @@ -51,7 +51,7 @@ Encryption is only as strong as its weakest component: the algorithm, the mode o - **Use Secure Encryption Modes**: Choose secure, authenticated modes (e.g. approved by NIST) such as `AES/GCM/NoPadding`. If AES-CBC must be used, apply Encrypt-then-MAC (e.g. append HMAC) and, for RSA, prefer OAEP over PKCS#1 v1.5. - **Ensure Proper Initialization Vector Management**: Generate IVs using cryptographically secure random number generators (with sufficient entropy) and ensure they are unique for every operation; never hardcode, null, or reuse them. On Android, use `GCMParameterSpec` (not the legacy `IvParameterSpec`) for GCM. -- **Use Sufficiently Long Keys**: Enforce sufficiently long keys such as those approved by NIST, e.g., a minimum of 256 bits for AES. +- **Use Sufficiently Long Keys**: Enforce sufficiently long keys such as those approved by NIST, e.g., a minimum of 128 bits for AES. - **Use Each Key for a Single Purpose**: Derive or generate separate keys for encryption, authentication, and signing, and only use each key with its authorized algorithm. - **Do Not Expose Cryptographic Errors**: Avoid leaking detailed padding or decryption error messages or timing differences that could serve as an oracle. - **Rely on Proper Cryptographic Primitives**: Rely on well-vetted cryptographic primitives that have undergone rigorous peer review and formal validation. See @MASWE-0015 for signature verification. diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0012.md b/weaknesses/MASVS-CRYPTO/MASWE-0012.md index aeade09..726b159 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0012.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0012.md @@ -25,7 +25,7 @@ status: new This weakness occurs when a broken or unsuitable hash function is used in a security-sensitive context, such as integrity checks, digital signatures, or certificate fingerprints. -Broken algorithms such as MD5 and SHA-1 are vulnerable to collision attacks and must not be used where collision or second-preimage resistance is required. Using an otherwise sound hash function for the wrong job is equally problematic: passwords and passphrases require a dedicated password-based key derivation function rather than a plain hash (see @MASWE-0008), and non-cryptographic checksums provide no security at all. +Broken algorithms such as MD5 and SHA-1 have practical collision attacks, and NIST has deprecated both for all security purposes; they must not be used in any security-sensitive context. Using an otherwise sound hash function for the wrong job is equally problematic: passwords and passphrases require a dedicated password-based key derivation function rather than a plain hash (see @MASWE-0008), and non-cryptographic checksums provide no security at all. ## Modes of Introduction diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0013.md b/weaknesses/MASVS-CRYPTO/MASWE-0013.md index faa4b4e..c37a7f0 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0013.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0013.md @@ -6,11 +6,11 @@ requirement: "The app properly uses Message Authentication Codes (MACs)." platform: [android, ios] profiles: [L1, L2] threat: MAS-THREAT-0013 -attacks: [MAS-ATTACK-0018, MAS-ATTACK-0021, MAS-ATTACK-0029] +attacks: [MAS-ATTACK-0018, MAS-ATTACK-0021, MAS-ATTACK-0029, MAS-ATTACK-0090] mappings: masvs-v1: [MSTG-CRYPTO-4, MSTG-CRYPTO-5] masvs-v2: [MASVS-CRYPTO-1, MASVS-CRYPTO-2] - cwe: [323, 327, 807, 915] + cwe: [208, 323, 327, 354, 807] maswe-beta: [MASWE-0024, MASWE-0012] refs: - https://developer.android.com/privacy-and-security/cryptography#deprecated-functionality @@ -31,7 +31,7 @@ A MAC provides integrity and authenticity for a message using a shared secret ke ## Modes of Introduction - **Non-Cryptographic Checksums**: Using checksums such as CRC-32 where a MAC is required; checksums detect accidental corruption but can be trivially recomputed by an attacker. -- **MACs Built on Broken Hashes**: Building MACs on hash functions lacking collision resistance, such as MD5 or SHA-1. +- **MACs Built on Weak Hashes**: Building MACs on deprecated hash functions such as MD5 or SHA-1, or using naive constructions such as `hash(key ‖ message)` that are vulnerable to length-extension attacks. - **Weak or Reused MAC Keys**: Using MAC keys with insufficient entropy, or using a MAC key for more than one purpose or with an unauthorized algorithm, violating key-separation principles. - **Fragile Constructions**: Using constructions that fail outside narrow assumptions, such as raw CBC-MAC on variable-length messages, or composing encryption and authentication incorrectly (e.g. MAC-then-encrypt where encrypt-then-MAC is required). - **Truncated Tags**: Using authentication tags that are too short, significantly lowering the effort required for forgery. diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0014.md b/weaknesses/MASVS-CRYPTO/MASWE-0014.md index cb03cde..5aab6a4 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0014.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0014.md @@ -10,7 +10,7 @@ attacks: [MAS-ATTACK-0018, MAS-ATTACK-0021, MAS-ATTACK-0030] mappings: masvs-v1: [MSTG-CRYPTO-4, MSTG-CRYPTO-5] masvs-v2: [MASVS-CRYPTO-1, MASVS-CRYPTO-2] - cwe: [323, 327] + cwe: [323, 326, 327, 330] maswe-beta: [MASWE-0025, MASWE-0012] refs: - https://developer.android.com/privacy-and-security/cryptography#deprecated-functionality diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0015.md b/weaknesses/MASVS-CRYPTO/MASWE-0015.md index 5156ed4..dd8a5d9 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0015.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0015.md @@ -10,7 +10,7 @@ attacks: [MAS-ATTACK-0031] mappings: masvs-v1: [MSTG-CRYPTO-4] masvs-v2: [MASVS-CRYPTO-1] - cwe: [347] + cwe: [295, 347] maswe-beta: [MASWE-0026] refs: - https://cwe.mitre.org/data/definitions/347.html diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0016.md b/weaknesses/MASVS-CRYPTO/MASWE-0016.md index 345ccfb..0911715 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0016.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0016.md @@ -16,7 +16,7 @@ mappings: android-core-app-quality: [Cryptographic_Algorithms] maswe-beta: [MASWE-0027] refs: -- https://www.ietf.org/rfc/rfc1750.txt +- https://datatracker.ietf.org/doc/html/rfc4086 - https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html#secure-random-number-generation status: new --- @@ -42,4 +42,4 @@ A [PRNG](https://en.wikipedia.org/wiki/Pseudorandom_number_generator) generates - **Use Cryptographically Secure RNGs**: For security-relevant contexts, always generate random values with a cryptographically secure random number generator provided by the platform. - **Avoid Deterministic Seeding**: Do not use any random function in a deterministic way, even a secure one, and especially avoid hardcoded seed values, which can be recovered by decompiling the app. -- **Follow Established Guidance**: Refer to [RFC 1750 - Randomness Recommendations for Security](https://www.ietf.org/rfc/rfc1750.txt) and the [OWASP Cryptographic Storage Cheat Sheet - Secure Random Number Generation](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html#secure-random-number-generation) for recommendations on random number generation. +- **Follow Established Guidance**: Refer to [RFC 4086 - Randomness Requirements for Security](https://datatracker.ietf.org/doc/html/rfc4086) and the [OWASP Cryptographic Storage Cheat Sheet - Secure Random Number Generation](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html#secure-random-number-generation) for recommendations on random number generation. From edc163f1a9ca3151b21137632754f149d91e83fd Mon Sep 17 00:00:00 2001 From: Carlos Holguera Date: Sun, 26 Jul 2026 11:26:18 +0200 Subject: [PATCH 23/70] Apply suggestions from code review Co-authored-by: Jaco <43786394+jacobocasado@users.noreply.github.com> --- weaknesses/MASVS-PLATFORM/MASWE-0028.md | 22 +++++++++++----------- weaknesses/MASVS-PLATFORM/MASWE-0029.md | 17 ++++++++--------- 2 files changed, 19 insertions(+), 20 deletions(-) diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0028.md b/weaknesses/MASVS-PLATFORM/MASWE-0028.md index f60da54..9fb35e8 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0028.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0028.md @@ -1,5 +1,5 @@ --- -title: Sensitive Data Exposed via the User Interface +title: Unnecessary Exposure of Sensitive Data via the User Interface id: MASWE-0028 alias: data-leak-ui requirement: "The app does not unnecessarily expose sensitive data through the app user interface." @@ -13,32 +13,32 @@ mappings: cwe: [200, 359] maswe-beta: [MASWE-0053] refs: -- https://developer.android.com/develop/ui/views/text-and-emoji/edittext#SpecifyKeyboardType +- https://developer.android.com/develop/ui/views/touch-and-input/keyboard-input/style#Type - https://developer.apple.com/documentation/uikit/uitextinputtraits/1624427-issecuretextentry status: new --- ## Overview -This weakness occurs when sensitive data, such as passwords, PINs, card numbers, or other personal information, is unnecessarily exposed through the app's user interface. +This weakness occurs when an app exposes more sensitive data than is necessary for the user's current task through UI components or UI-mediated platform services (like the clipboard or the autocompletion feature). -Typical exposure paths include displaying values in cleartext when masking would suffice, allowing sensitive values to be copied to the clipboard, letting the keyboard cache or auto-correct learn from sensitive input, and not using secure text entry for secret fields. Anyone with brief access to the device or a view of its screen can then read the information. +Typical exposure paths include displaying secrets or complete identifiers in cleartext when masking or a partial representation would suffice, using unprotected input fields for passwords or PINs, permitting unnecessary copy to the system clipboard, and enabling keyboard or IME (Input Method Editor) features that may retain or later suggest sensitive input. ## Modes of Introduction -- **Non-Secure Text Entry**: Building password or PIN fields without secure text entry (e.g. `isSecureTextEntry` on iOS, `textPassword` input types on Android), so the input is shown in cleartext. -- **Copy Allowed on Sensitive Fields**: Allowing users to copy sensitive values, placing them on the shared clipboard. +- **Non-Secure Text Entry**: Building password or PIN fields without secure text entry behavior (e.g. [`isSecureTextEntry`](https://developer.apple.com/documentation/uikit/uitextinputtraits/issecuretextentry) on iOS, [`textPassword`](https://developer.android.com/develop/ui/views/touch-and-input/keyboard-input/style#Type) input types on Android), so the input is shown in cleartext. +- **Unsafe Clipboard Exposure**: Allowing sensitive values to be copied when copying the value is unnecessary, or placing them on the system clipboard automatically when it's not needed. - **Keyboard Caching and Auto-Correct**: Using input types that let the keyboard cache or auto-correct dictionaries learn sensitive input. - **Unmasked Sensitive Values**: Displaying full values (e.g. complete card numbers or personal identifiers) where a masked or partial representation would suffice. ## Impact -- **Compromise of Sensitive Data**: Attackers can read personal or financial information from the screen, the clipboard, or keyboard cache files, resulting in unauthorized disclosure of user data. +- **Compromise of Sensitive Data**: Sensitive information may be observed from the screen, transferred through the clipboard, retained by an input method, or subsequently disclosed to another user. - **Authentication or Authorization Bypass**: Attackers can capture credentials, PINs, or one-time codes exposed through the UI, resulting in unauthorized access to the user's accounts. ## Mitigations -- **Use Secure Text Entry**: Configure secret fields with the platform's secure input types so the input is masked and excluded from keyboard learning. -- **Disable Copy for Sensitive Fields**: Prevent copying of sensitive values to the clipboard where it is not essential. -- **Disable Keyboard Caching**: Use non-caching input types for sensitive fields so keyboards and auto-correct do not retain the values. -- **Mask Displayed Values**: Show masked or partial representations of sensitive values and reveal the full value only on explicit user request. +- **Use Secure Text Entry for Secrets**: Configure passwords, PINs, and other secrets using the platform's secure text-entry controls, such as [`textPassword` on Android Views](https://developer.android.com/develop/ui/views/touch-and-input/keyboard-input/style), [`SecureTextField` in Jetpack Compose](https://developer.android.com/develop/ui/compose/text/user-input), or [`isSecureTextEntry` on iOS](https://developer.apple.com/documentation/uikit/uitextinputtraits/issecuretextentry). Do not rely solely on custom visual masking when a platform-provided secure text-entry control is available. +- **Restrict Clipboard Exposure**: Prevent copying sensitive values when it is not required for the intended functionality. When copying is a legitimate feature, follow the platform's [secure clipboard handling guidance on Android](https://developer.android.com/privacy-and-security/risks/secure-clipboard-handling) and mark the content using [`ClipDescription.EXTRA_IS_SENSITIVE`](https://developer.android.com/reference/android/content/ClipDescription#EXTRA_IS_SENSITIVE) to obscure clipboard previews. On iOS, use pasteboard options such as [`localOnly`](https://developer.apple.com/documentation/uikit/uipasteboard/optionskey/localonly) and [`expirationDate`](https://developer.apple.com/documentation/uikit/uipasteboard/optionskey/expirationdate) to limit cross-device propagation and content lifetime. These mechanisms reduce exposure but do not provide access control over clipboard contents. +- **Limit Keyboard and IME Processing**: Disable unnecessary autocorrection, spell checking, suggestions, inline predictions, and personalized learning for the data that is considered sensitive. On Android, signal that dictionary-based suggestions are unnecessary using [`TYPE_TEXT_FLAG_NO_SUGGESTIONS`](https://developer.android.com/reference/android/text/InputType#TYPE_TEXT_FLAG_NO_SUGGESTIONS) and request that the IME does not retain personalized data using [`IME_FLAG_NO_PERSONALIZED_LEARNING`](https://developer.android.com/reference/android/view/inputmethod/EditorInfo#IME_FLAG_NO_PERSONALIZED_LEARNING). Treat the no-learning flag as a defense-in-depth measure rather than a guarantee because an IME may ignore it. On iOS, configure [`autocorrectionType`](https://developer.apple.com/documentation/uikit/uitextinputtraits/autocorrectiontype), [`spellCheckingType`](https://developer.apple.com/documentation/uikit/uitextinputtraits/spellcheckingtype), and [`inlinePredictionType`](https://developer.apple.com/documentation/uikit/uitextinputtraits/inlinepredictiontype) as appropriate for the sensitivity of the input. +- **Minimize Visual Disclosure**: Display only the portion of a sensitive value required for the user's current task. When revealing the full value is necessary, reveal it only after an explicit user action (see @MASWE-0017) and for a limited duration. diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0029.md b/weaknesses/MASVS-PLATFORM/MASWE-0029.md index 50147fe..f0720da 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0029.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0029.md @@ -1,5 +1,5 @@ --- -title: Sensitive Data Leaked via Notifications +title: Unnecessary Exposure of Sensitive Data via Notifications id: MASWE-0029 alias: data-leak-notifications requirement: "The app does not unnecessarily expose sensitive data through system notifications." @@ -19,22 +19,21 @@ status: new ## Overview -This weakness occurs when an app places sensitive data, such as one-time codes, message contents, or account details, into system notifications without restricting where and to whom they are visible. +This weakness occurs when an app includes more sensitive data (such as one-time codes, message contents, or account details) than necessary in a system notification. -Notifications are rendered on the lock screen, where anyone holding the device can read them without unlocking it, and they can be read by other apps that hold notification access (e.g. an Android `NotificationListenerService`). Any sensitive value included in a notification therefore leaves the app's control the moment it is posted. +Notifications can be rendered on the lock screen, and therefore, anyone holding the device can read them without unlocking it. They also can be read by other apps that hold notification access (e.g. an Android [`NotificationListenerService`](https://developer.android.com/reference/android/service/notification/NotificationListenerService)). Any sensitive value included in a notification therefore leaves the app's control the moment it is posted. ## Modes of Introduction -- **Sensitive Content in Notifications**: Including one-time codes, message contents, financial details, or other sensitive values directly in notification titles or bodies. +- **Sensitive Content in Notifications**: Including one-time codes, message contents, financial details, or other sensitive values directly in notification titles or bodies when a generic notification would suffice. - **No Lock-Screen Redaction**: Not configuring notification visibility so that sensitive content is redacted or hidden on the lock screen. ## Impact -- **Compromise of Sensitive Data**: Attackers can read message contents or account details from notifications, resulting in unauthorized disclosure of user data. -- **Authentication or Authorization Bypass**: Attackers can capture one-time codes delivered via notifications, resulting in the defeat of SMS- or push-based authentication factors and unauthorized account access. +- **Compromise of Sensitive Data**: Unauthorized observers or, where applicable, apps with notification-listener access may obtain personal, financial, authentication, or account information contained in notifications. +- **Authentication or Authorization Bypass**: Attackers may use exposed credentials or still-valid one-time codes to access an account, perform unauthorized transactions, or carry out other sensitive actions. ## Mitigations -- **Keep Sensitive Data Out of Notifications**: Use notifications to signal that something happened and reveal the sensitive details only inside the app after unlocking it. -- **Redact Notifications on the Lock Screen**: Configure notification visibility (e.g. private visibility with a public redacted version on Android) so sensitive content is hidden until the device is unlocked. -- **Review Notification Content Regularly**: Audit which notifications the app posts and ensure new features do not introduce sensitive values into them. +- **Minimize Notification Content**: Use notifications only to indicate that an event occurred, and retrieve sensitive details inside the app after appropriate authentication and authorization. For iOS remote notifications, follow Apple's [remote-notification payload guidance](https://developer.apple.com/documentation/usernotifications/generating-a-remote-notification) and keep user-visible alert content non-sensitive by default. +- **Configure Android Lock-Screen Visibility**: Use [`NotificationCompat.Builder.setVisibility()` and `setPublicVersion()`](https://developer.android.com/develop/ui/views/notifications/build-notification#lockscreenNotification) to modify the presentation of sensitive notifications. Use `VISIBILITY_PRIVATE` together with a generic public version when a redacted notification may be shown, and use `VISIBILITY_SECRET` when the notification should not appear on a secure lock screen. Do not place sensitive data in the title because private notifications may still display basic information including the title. From 530dccd50e743db97e406a7cd6ed6ebd5832df5f Mon Sep 17 00:00:00 2001 From: Carlos Holguera Date: Sun, 26 Jul 2026 11:52:06 +0200 Subject: [PATCH 24/70] Apply suggestions from code review Co-authored-by: Jaco <43786394+jacobocasado@users.noreply.github.com> --- weaknesses/MASVS-PLATFORM/MASWE-0030.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0030.md b/weaknesses/MASVS-PLATFORM/MASWE-0030.md index de34c94..0bd9b95 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0030.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0030.md @@ -2,7 +2,7 @@ title: Sensitive Data Leaked via Screenshots or Screen Recordings id: MASWE-0030 alias: data-leak-screenshots -requirement: "The app removes sensitive data from views when moved to the background or when being recorded." +requirement: "The app removes or masks sensitive data from its views when moved to the background, when being recorded or when a screenshot is taken." platform: [android, ios] profiles: [L2] threat: MAS-THREAT-0030 @@ -26,11 +26,12 @@ Mobile platforms allow users, other apps, and external tools to capture screensh ## Modes of Introduction - **Screenshots and Screen Recordings Not Prevented**: Not implementing measures (such as setting secure window flags) to prevent the operating system or other apps from capturing screenshots or screen recordings of sensitive views. -- **Unredacted Sensitive On-Screen Content**: Displaying sensitive information directly on the screen without masking or redacting it, including in the view snapshot the system takes when the app moves to the background. +- **Missing Capture-State Redaction**: Continuing to display sensitive information while the app or scene is being recorded, mirrored, or shared, despite the platform providing an API to detect the active capture state. +- **Excessive On-Screen Disclosure**: Displaying complete sensitive values when a masked, partial, temporary, or user-initiated representation would be sufficient for the current task. ## Impact -- **Compromise of Sensitive Data**: Attackers can obtain sensitive data previously displayed on the screen, such as account details, personal information, or one-time codes, resulting in unauthorized disclosure and enabling further attacks such as identity theft or account takeover. +- **Compromise of Sensitive Data**: Sensitive information may be retained in an image or video after the app session ends and may later be viewed, shared, synchronized, backed up, or accessed by another person or service. ## Mitigations From a9212294ded7d731091046ae10f9007132ceabde Mon Sep 17 00:00:00 2001 From: Carlos Holguera Date: Sun, 26 Jul 2026 11:53:29 +0200 Subject: [PATCH 25/70] Apply suggestions from code review Co-authored-by: Jan Seredynski --- weaknesses/MASVS-PLATFORM/MASWE-0031.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0031.md b/weaknesses/MASVS-PLATFORM/MASWE-0031.md index d2db489..d37c455 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0031.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0031.md @@ -28,6 +28,7 @@ In an overlay attack, a malicious app draws content on top of the target app to ## Modes of Introduction - **Touch Filtering Not Enabled**: Not enabling touch filtering on sensitive views (e.g. `setFilterTouchesWhenObscured(true)` or `android:filterTouchesWhenObscured="true"`) and not discarding touch events flagged as obscured (e.g. `FLAG_WINDOW_IS_PARTIALLY_OBSCURED`). +- **External Overlays Not Hidden**: Not using `setHideOverlayWindows(true)` to hide external overlays - **Sensitive Screens Not Protected**: Presenting confirmation dialogs or security-relevant screens without any occlusion defense, so their content can be covered or mimicked by an overlay. ## Impact @@ -39,5 +40,6 @@ In an overlay attack, a malicious app draws content on top of the target app to ## Mitigations - **Enable Touch Filtering on Sensitive Views**: Configure sensitive views to ignore touches delivered while the window is obscured, and discard motion events flagged as (partially) obscured. +- **Hide External Overlays**: Configure sensitive activities to hide all external overlays. - **Protect Sensitive Screens**: Apply overlay defenses to confirmation and authentication screens specifically, and consider pausing or hiding sensitive content when the app detects it is being drawn over. - **Use Trusted Confirmation Paths for Critical Actions**: For the most critical approvals, use hardware-protected confirmation mechanisms that overlays cannot forge (see @MASWE-0019). From 3c5c21ff65570895e104b9ca48cc06075dd309eb Mon Sep 17 00:00:00 2001 From: Carlos Holguera Date: Sun, 26 Jul 2026 11:59:58 +0200 Subject: [PATCH 26/70] Apply suggestions from code review Co-authored-by: Jan Seredynski --- weaknesses/MASVS-RESILIENCE/MASWE-0057.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0057.md b/weaknesses/MASVS-RESILIENCE/MASWE-0057.md index e6545bc..fe9c69a 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0057.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0057.md @@ -31,6 +31,7 @@ App virtualization and "dual-app" container frameworks run an app inside another - **Compromise of Sensitive Data**: Attackers can intercept the virtualized app's files, credentials, and API calls from the hosting app, resulting in exposure of user data without requiring root access. - **Bypass of Protection Mechanisms**: Attackers can instrument the app inside the container to defeat its client-side controls, resulting in the circumvention of its defenses on unrooted devices. - **Compromise of System Integrity and Business Operations**: Attackers can run multiple cloned instances to abuse promotions or multi-account limits, resulting in fraud against the app owner. +- **Lack of Server-Verified Platform Attestation**: Failing to validate the app's package identity, signing certificate via hardware-backed platform attestation (e.g., Play Integrity or App Attest) on a backend server, allowing the app to execute unchecked inside virtual containers or cloned spaces. ## Mitigations @@ -38,3 +39,4 @@ App virtualization and "dual-app" container frameworks run an app inside another - **Check for Known Frameworks**: Detect artifacts of known virtualization and cloning frameworks and their hosting packages. - **Respond to Detection**: Restrict sensitive functionality, notify the backend, or terminate when a virtualized environment is detected, according to the app's risk profile. - **Assess Effectiveness**: Test the detection against current virtualization frameworks and update it as they evolve. +- **Attest Application Integrity**: Use platform attestation frameworks such as Play Integrity on Android or App Attest on iOS (see @MASWE-0059) with backend nonce verification to validate the official package name, signing certificate, and application integrity. From c169515da74cc663a1a6b3b753a2ffcc8bc8ae40 Mon Sep 17 00:00:00 2001 From: Carlos Holguera Date: Sun, 26 Jul 2026 12:11:40 +0200 Subject: [PATCH 27/70] Apply suggestions from code review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Sergio García <32015541+sgIOlas@users.noreply.github.com> --- weaknesses/MASVS-RESILIENCE/MASWE-0058.md | 21 +++++++++++------ weaknesses/MASVS-RESILIENCE/MASWE-0059.md | 28 ++++++++++++++--------- weaknesses/MASVS-RESILIENCE/MASWE-0060.md | 13 +++++++---- weaknesses/MASVS-RESILIENCE/MASWE-0061.md | 17 ++++++++++---- weaknesses/MASVS-RESILIENCE/MASWE-0063.md | 18 ++++++++++----- weaknesses/MASVS-RESILIENCE/MASWE-0064.md | 13 ++++++----- 6 files changed, 72 insertions(+), 38 deletions(-) diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0058.md b/weaknesses/MASVS-RESILIENCE/MASWE-0058.md index fd23e56..85196ce 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0058.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0058.md @@ -1,8 +1,8 @@ --- -title: Emulator Detection Not Implemented +title: Emulated or Virtual Device Detection Not Implemented id: MASWE-0058 -alias: emulator-detection -requirement: "The app detects when it is running on an emulator." +alias: emulated-virtual-device-detection +requirement: "The app detects when it is running in an emulated or virtual device environment." platform: [android, ios] profiles: [R] threat: MAS-THREAT-0058 @@ -10,8 +10,15 @@ attacks: [MAS-ATTACK-0003, MAS-ATTACK-0066] mappings: masvs-v1: [MSTG-RESILIENCE-5, MSTG-RESILIENCE-8] masvs-v2: [MASVS-RESILIENCE-1, MASVS-RESILIENCE-4] - cwe: [693] maswe-beta: [MASWE-0099, MASWE-0103] +refs: +- https://developer.android.com/google/play/integrity/overview +- https://developer.android.com/google/play/integrity/verdicts +- https://github.com/eltavine/Duck-Detector-Refactoring +- https://github.com/Lakr233/vphone-cli +- https://developer.apple.com/documentation/devicecheck +- https://ieeexplore.ieee.org/document/10935812 + status: new --- @@ -19,12 +26,12 @@ status: new This weakness occurs when an app does not implement effective techniques to detect that it is running in an emulator or virtual device. -Emulators give attackers a fully controlled, snapshottable environment for analyzing the app, automating interactions, and running it at scale in bot farms. Detection typically relies on identifying the features and limitations of commonly used emulation solutions, such as characteristic device identifiers, hardware properties, sensors, and timing behavior. More broadly, the app should apply Runtime Application Self-Protection (RASP) techniques that detect a compromised environment and trigger appropriate responses. +Emulators give attackers a fully controlled, snapshottable environment for analyzing the app, automating interactions, and running it at scale in bot farms. Detection typically relies on identifying the features and limitations of commonly used emulation solutions, such as characteristic device identifiers, emulator-specific file-paths, hardware properties, sensors, and timing behavior. ## Modes of Introduction - **No Emulator Checks**: Shipping without any verification of device properties, hardware features, or sensor behavior that distinguish emulators from real devices. -- **Trivially Spoofable Checks**: Relying on a single property (e.g. a device model string) that emulators can trivially fake. +- **Single-Source Detection Signals**: Relying on a single source of emulation or virtualization indicators (e.g. system properties) that emulators can trivially fake. - **No Response Strategy**: Detecting an emulated environment but not adapting the app's behavior in response. ## Impact @@ -34,7 +41,7 @@ Emulators give attackers a fully controlled, snapshottable environment for analy ## Mitigations -- **Detect Emulator Characteristics**: Check device identifiers, hardware capabilities, sensor availability, and behavioral traits that differ between emulators and physical devices, combining multiple signals. +- **Detect Emulator Characteristics**: Check device identifiers, hardware capabilities, sensor availability, file paths and behavioral traits that differ between emulators and physical devices, combining multiple signals. - **Respond to Detection**: Restrict sensitive functionality, require additional verification, or terminate when an emulated environment is detected, according to the app's risk profile. - **Combine with Attestation**: Use server-verified device attestation (see @MASWE-0059) so emulated environments are also flagged independently of local checks. - **Assess Effectiveness**: Test the detection against popular emulators and hardening/evasion tools and refine it over time. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0059.md b/weaknesses/MASVS-RESILIENCE/MASWE-0059.md index 3b49de4..d7e951e 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0059.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0059.md @@ -10,26 +10,30 @@ attacks: [MAS-ATTACK-0065, MAS-ATTACK-0066, MAS-ATTACK-0068] mappings: masvs-v1: [MSTG-RESILIENCE-10] masvs-v2: [MASVS-RESILIENCE-1] - cwe: [693] maswe-beta: [MASWE-0100] refs: - https://developer.android.com/google/play/integrity -- https://support.google.com/googleplay/android-developer/answer/11395166?hl=en -- https://www.youtube.com/watch?v=TyxL78e5Bag -- https://github.com/1nikolas/play-integrity-checker-app -- https://developer.apple.com/videos/play/wwdc2021/10244/ -- https://developer.apple.com/documentation/devicecheck/preparing-to-use-the-app-attest-service -- https://github.com/iansampson/AppAttest -- https://github.com/firebase/firebase-ios-sdk/blob/v8.15.0/FirebaseAppCheck/Sources/AppAttestProvider/DCAppAttestService%2BFIRAppAttestService.h -- https://blog.restlesslabs.com/john/ios-app-attest +- https://developer.android.com/google/play/integrity/verdicts +- https://developer.android.com/google/play/integrity/standard +- https://developer.android.com/google/play/integrity/classic +- https://developer.apple.com/documentation/devicecheck +- https://developer.apple.com/documentation/devicecheck/accessing-and-modifying-per-device-data +- https://developer.apple.com/documentation/devicecheck/establishing-your-app-s-integrity +- https://developer.apple.com/documentation/devicecheck/validating-apps-that-connect-to-your-server +- https://github.com/Oliver-Binns/app-attest +- https://github.com/VisionR1/KeyAttestation +- https://github.com/JingMatrix/TEESimulator +- https://github.com/5ec1cff/TrickyStore status: new --- ## Overview -This weakness occurs when an app does not implement device attestation, so its backend cannot distinguish requests from genuine, uncompromised devices from those coming from rooted, emulated, tampered, or automated environments. +This weakness occurs when an app does not implement device attestation, so its backend cannot distinguish requests made from genuine, uncompromised devices from those coming from rooted, emulated, tampered, or automated environments. -Device attestation uses platform services, such as the Android Play Integrity API or iOS DeviceCheck and App Attest, to give the backend cryptographic assurance about the integrity of the device and platform the app runs on. Without it, the backend must trust whatever the client claims. Attestation results must be verified server-side, including nonce-based freshness, to be meaningful; a verdict checked only on the client is just another bypassable local check. +Device attestation uses platform services, such as the Android Play Integrity API or iOS DeviceCheck and App Attest, to provide the backend with cryptographically verifiable evidence about the device associated with a request. The evidence and security properties differ by platform and service. Without device attestation, the backend cannot independently verify device-origin claims made by the client. The backend must validate attestation evidence and apply the service-specific request-binding, freshness, and replay protections; client-side evaluation is another bypassable local check. + +On Android, Play Integrity can provide server-verifiable assurance that the device has not been compromised in ways covered by its device-integrity verdicts, such as an unlocked bootloader or an unrecognized operating-system image. On iOS, DeviceCheck and App Attest do not provide equivalent assurance about operating-system compromise. They can establish that evidence originates from genuine Apple hardware; App Attest also binds that evidence to a legitimate app instance, but neither service attests the integrity of iOS. ## Modes of Introduction @@ -37,10 +41,12 @@ Device attestation uses platform services, such as the Android Play Integrity AP - **Client-Side-Only Verification**: Requesting attestation but evaluating the verdict in the app instead of verifying it server-side. - **Missing Freshness Guarantees**: Verifying attestation without a server-issued nonce or timeliness check, allowing verdicts to be replayed. - **Verdicts Not Enforced**: Collecting attestation results but not gating sensitive operations on them. +- **Incomplete Evidence Validation**: Accepting device-attestation evidence without applying the service-specific checks for request binding, replay protection, and the device claims required by the backend's policy. ## Impact - **Compromise of System Integrity and Business Operations**: Attackers can drive the backend with automated or tampered clients, resulting in fraud, scraping, fake accounts, and abuse of the app owner's services. +- **Bypass of Protection Mechanisms**: Attackers can leverage tampered running environments to bypass the app's security checks or feature restrictions, resulting in unauthorized access to protected app functionality. - **Financial Loss**: Attackers can abuse promotions, premium features, or transaction flows from unattested environments, resulting in direct monetary loss to the app owner. ## Mitigations diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0060.md b/weaknesses/MASVS-RESILIENCE/MASWE-0060.md index d6ca615..1485fe0 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0060.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0060.md @@ -2,7 +2,7 @@ title: Debugger Detection Not Implemented id: MASWE-0060 alias: debugger-detection -requirement: "The app terminates if a debugger is detected." +requirement: "The app detects debugger attachment at runtime and responds to protect sensitive operations." platform: [android, ios] profiles: [R] threat: MAS-THREAT-0060 @@ -10,8 +10,13 @@ attacks: [MAS-ATTACK-0002] mappings: masvs-v1: [MSTG-RESILIENCE-2] masvs-v2: [MASVS-RESILIENCE-4] - cwe: [693] maswe-beta: [MASWE-0101] +refs: +- https://developer.android.com/reference/android/os/Debug#isDebuggerConnected() +- https://man7.org/linux/man-pages/man5/proc_pid_status.5.html +- https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man2/ptrace.2.html +- https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/sysctl.3.html +- https://www.youtube.com/watch?v=ih6gWZDuNME status: new --- @@ -19,12 +24,12 @@ status: new This weakness occurs when an app does not detect the presence of a debugger attached to it at runtime. -A debugger lets an attacker inspect memory, set breakpoints, and alter control flow to bypass client-side controls, even when the release build is not flagged as debuggable (see @MASWE-0050 for that case). Platforms offer detection primitives such as `Debug.isDebuggerConnected()` and the `TracerPid` field in `/proc/self/status` on Android, or `sysctl`- and `ptrace`-based checks on iOS. Without such checks and a response, a debugger can be attached and used against the app unnoticed. +A debugger lets an attacker inspect memory, set breakpoints, and alter control flow to bypass client-side controls, even when the release build is not flagged as debuggable (see @MASWE-0050 for that case). Platforms offer detection primitives such as `Debug.isDebuggerConnected()` (Java debugging) and the `TracerPid` field in `/proc/self/status` on Android (Native debugging), or `sysctl`- and `ptrace`-based checks on iOS. Without such checks and a response, a debugger can be attached and used against the app unnoticed. ## Modes of Introduction - **No Debugger Checks**: Shipping without any runtime verification that a debugger is attached to the process. -- **One-Time or Single-Point Checks**: Checking only at startup or in a single location, so attackers can attach later or patch out the one check. +- **One-Time or Single-Point Checks**: Checking only at startup or in a single code path instead of around sensitive operations and throughout runtime. - **No Response Strategy**: Detecting a debugger but not reacting in a way that protects the app's sensitive operations. ## Impact diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0061.md b/weaknesses/MASVS-RESILIENCE/MASWE-0061.md index 0934e38..45417cf 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0061.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0061.md @@ -2,7 +2,7 @@ title: Dynamic Analysis Tools Detection Not Implemented id: MASWE-0061 alias: dynamic-analysis-tools -requirement: "The app detects dynamic analysis tools." +requirement: "The app detects dynamic analysis tools and responds to protect sensitive operations." platform: [android, ios] profiles: [R] threat: MAS-THREAT-0061 @@ -10,8 +10,15 @@ attacks: [MAS-ATTACK-0003] mappings: masvs-v1: [MSTG-RESILIENCE-4] masvs-v2: [MASVS-RESILIENCE-4] - cwe: [693] maswe-beta: [MASWE-0102] +refs: +- https://frida.re/docs/home/ +- https://github.com/LSPosed/LSPosed +- https://github.com/LSPosed/LSPlant +- https://www.cydiasubstrate.com/api/c/MSHookFunction/ +- https://github.com/tealbathingsuit/ellekit +- https://github.com/roothide/Bootstrap +- https://burjcdigital.urjc.es/server/api/core/bitstreams/d249ebbb-5923-48ea-9215-af14cf2cc0b9/content status: new --- @@ -19,12 +26,14 @@ status: new This weakness occurs when an app does not detect the presence of dynamic instrumentation and hooking frameworks at runtime. -Tools such as Frida, Xposed/LSPosed, and ElleKit/Cydia Substrate let attackers observe and modify the app while it runs, replacing method implementations and defeating client-side security controls. These frameworks leave detectable artifacts, such as loaded libraries, named pipes, listening ports, and installed hooks, that the app can check for. Without detection and a response, instrumentation proceeds unnoticed. +Tools such as Frida, Xposed/LSPosed, and ElleKit/Cydia Substrate let attackers observe and modify the app while it runs, replacing method implementations and defeating client-side security controls. These frameworks can leave detectable artifacts, such as loaded libraries, named pipes, listening ports, installed hooks, or framework-specific classes, but attackers can often rename, relocate, hide, or patch these indicators to bypass shallow detection. Without layered detection and a response, instrumentation can proceed unnoticed. + +Unlike runtime code integrity verification (see @MASWE-0064), this weakness focuses on detecting the presence of instrumentation tools and frameworks through tool-specific indicators. On the other hand, runtime code integrity verification checks whether loaded code, executable memory, or security-critical functions were modified, even when no known tool artifact is present. ## Modes of Introduction - **No Instrumentation Checks**: Shipping without any detection of well-known instrumentation and hooking frameworks. -- **Artifact Checks Missing or Shallow**: Not checking for hooking artifacts such as suspicious loaded libraries, named pipes, listening ports, or modified function prologues, or checking only from easily hooked Java/Swift code. +- **Artifact Checks Missing or Shallow**: Not checking for hooking artifacts such as suspicious loaded libraries, named pipes, listening ports, or known trampoline instruction sequences in function prologues, or checking only from easily hooked Java/Swift code. - **No Response Strategy**: Detecting instrumentation but continuing to expose sensitive functionality. ## Impact diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0063.md b/weaknesses/MASVS-RESILIENCE/MASWE-0063.md index d232e9c..50e2843 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0063.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0063.md @@ -10,8 +10,14 @@ attacks: [MAS-ATTACK-0009, MAS-ATTACK-0070] mappings: masvs-v1: [MSTG-RESILIENCE-3] masvs-v2: [MASVS-RESILIENCE-2, MASVS-CODE-4] - cwe: [693] + cwe: [471] maswe-beta: [MASWE-0105] +refs: +- https://developer.android.com/privacy-and-security/cryptography +- https://developer.android.com/privacy-and-security/keystore +- https://developer.apple.com/documentation/cryptokit/hmac +- https://developer.apple.com/documentation/cryptokit/storing-cryptokit-keys-in-the-keychain +- https://developer.apple.com/documentation/security/restricting-keychain-item-accessibility status: new --- @@ -19,14 +25,14 @@ status: new This weakness occurs when an app does not verify that the resources it relies on have not been tampered with. -Beyond executable code, apps depend on resources whose integrity matters: files in the app sandbox, configuration, downloaded content, and dynamically loaded resources, including data restored from backups. An attacker who can alter these resources can change the app's behavior or inject malicious content without touching its code, sidestepping code-focused integrity checks (see @MASWE-0062, @MASWE-0064). +Beyond the app package, apps depend on non-executable resources whose integrity matters: files in the app sandbox, configuration, downloaded content, and data restored from backups. An attacker who can alter these resources can change the app's behavior or inject malicious content without modifying its packaged code, sidestepping package- and code-integrity checks (see @MASWE-0062, @MASWE-0064). Safe dynamic code loading is covered by @MASWE-0044. ## Modes of Introduction -- **Sandbox Files Not Verified**: Trusting files in the app's data directory without integrity checks, although they can be modified on compromised devices or through backup manipulation. +- **Sandbox Files Not Verified**: Trusting files in the app's data directory without verifying their integrity. - **Downloaded Resources Not Verified**: Using downloaded content or configuration without verifying its integrity and authenticity. -- **Restored Data Trusted Implicitly**: Loading data restored from backups or transfers as if the app had written it moments ago. -- **No Response to Tampering**: Having no defined behavior for when a resource fails validation. +- **Restored Data Not Revalidated**: Using data restored from backups or device transfers without revalidating its integrity. +- **Verification Result Ignored**: Continuing to use a resource after its integrity verification fails. ## Impact @@ -35,7 +41,7 @@ Beyond executable code, apps depend on resources whose integrity matters: files ## Mitigations -- **Verify Resource Integrity**: Validate hashes or signatures of security-relevant files in the sandbox before trusting them, keeping reference values out of the attacker's reach (e.g. signed or server-held). +- **Verify Resource Integrity**: Compare security-relevant files against a trusted expected hash, HMAC, or digital signature before use. Protect keys and reference values from modification, and treat local verification as a defense-in-depth control on compromised devices. - **Authenticate Downloaded Content**: Verify integrity and authenticity (e.g. a signature, see @MASWE-0015) of downloaded resources before use. - **Treat Restored Data as Untrusted**: Re-validate data that reappears via backup restore or device transfer before acting on it (see @MASWE-0048). - **Respond to Failed Checks**: Discard or re-fetch tampered resources, restrict functionality, or alert the backend when validation fails. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0064.md b/weaknesses/MASVS-RESILIENCE/MASWE-0064.md index 3a9f517..ed60dbb 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0064.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0064.md @@ -1,8 +1,8 @@ --- -title: Code Integrity Not Verified +title: Runtime Code Integrity Not Verified id: MASWE-0064 alias: runtime-code-integrity -requirement: "The app verifies the integrity of its code." +requirement: "The app detects unauthorized changes to its code and execution flow at runtime." platform: [android, ios] profiles: [R] threat: MAS-THREAT-0064 @@ -10,21 +10,22 @@ attacks: [MAS-ATTACK-0002, MAS-ATTACK-0003] mappings: masvs-v1: [MSTG-RESILIENCE-6] masvs-v2: [MASVS-RESILIENCE-2] - cwe: [693] maswe-beta: [MASWE-0107] status: new --- ## Overview -This weakness occurs when an app does not verify the integrity of its own code at runtime, allowing in-memory patching, code injection, and hooking to go undetected. +This weakness occurs when an app is running in an unsafe environment (rooted or jailbroken device) and does not verify the integrity of its own code at runtime, allowing in-memory patching, code injection, and hooking to go undetected. -Even a correctly signed app can be modified while it runs: attackers can patch instructions in memory, inject libraries into the process, or hook functions to change their behavior. Runtime code integrity verification, such as checking loaded code segments, detecting injected libraries, and spotting patched function prologues, complements static app attestation (see @MASWE-0062) by covering tampering that happens after the app has launched. +Even a correctly signed app can be modified while it runs: attackers can patch instructions in memory, inject libraries into the process, or hook functions to change their behavior. Runtime code integrity verification, such as checking loaded code segments, detecting injected libraries, and spotting patched function prologues, complements packaged-app integrity verification (see @MASWE-0062) by covering tampering that happens after the app has launched. + +Unlike dynamic-analysis tool detection (see @MASWE-0061), runtime integrity verification detects unauthorized changes to the app's memory and execution state without relying on tool-specific artifacts. ## Modes of Introduction - **No Runtime Code Checks**: Not verifying the integrity of loaded code segments or executable memory at runtime. -- **Injected Libraries Not Detected**: Not inspecting the process for libraries that are not part of the app or platform. +- **Injected Libraries or Executable Mappings Not Detected**: Not inspecting the process for executable memory mappings or libraries that are unexpected for the app or platform. - **Hooked Functions Not Detected**: Not checking security-critical functions for patched prologues or redirected implementations. - **No Response to Tampering**: Detecting modifications but not reacting to protect sensitive operations. From 86a383ddc5814b39a0e7955ff8d686d8a38b928a Mon Sep 17 00:00:00 2001 From: Carlos Holguera Date: Sun, 26 Jul 2026 12:22:51 +0200 Subject: [PATCH 28/70] Apply suggestions from code review Co-authored-by: Dionysis Lorentzos Co-authored-by: Stefan --- weaknesses/MASVS-STORAGE/MASWE-0003.md | 6 +++--- weaknesses/MASVS-STORAGE/MASWE-0004.md | 10 +++++----- weaknesses/MASVS-STORAGE/MASWE-0005.md | 8 +++++--- weaknesses/MASVS-STORAGE/MASWE-0006.md | 18 +++++++++--------- 4 files changed, 22 insertions(+), 20 deletions(-) diff --git a/weaknesses/MASVS-STORAGE/MASWE-0003.md b/weaknesses/MASVS-STORAGE/MASWE-0003.md index 6c38580..8b9bf45 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0003.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0003.md @@ -31,9 +31,9 @@ Sensitive data may include personally identifiable information (PII), passwords, - **Data Stored Unencrypted**: Writing sensitive data to the app's private data directory (sandbox) unencrypted. - **Hardcoded Encryption Key**: Encrypting sensitive data with a key that is hardcoded inside the application. -- **Encryption Key Stored on Filesystem**: Encrypting sensitive data but storing the key alongside it or in another easily accessible location. +- **Encryption Key Stored on Filesystem**: Encrypting sensitive data but storing the generated key alongside it or in another easily accessible location. - **Insufficient Encryption**: Encrypting sensitive data with an algorithm or configuration that is not considered strong. -- **Insufficient Access Restrictions**: Exposing private files to other apps through incorrect file permissions (e.g. the deprecated `MODE_WORLD_READABLE`/`MODE_WORLD_WRITEABLE` modes on Android), a misconfigured `FileProvider`, or Keychain items protected with weak accessibility attributes on iOS (e.g. `kSecAttrAccessibleAlways`). +- **Insufficient Access Restrictions**: Exposing private files to other apps through incorrect file permissions (e.g. the deprecated `MODE_WORLD_READABLE`/`MODE_WORLD_WRITEABLE` file permission modes on Android), a misconfigured `FileProvider`, or Keychain items protected with weak accessibility attributes on iOS (e.g. `kSecAttrAccessibleAlways`). - **Data Not Removed After Use**: Retaining sensitive data in private storage (including caches, temporary files, WebView state, and network caches) longer than needed. ## Impact @@ -44,7 +44,7 @@ Sensitive data may include personally identifiable information (PII), passwords, ## Mitigations - **Minimize Local Storage of Sensitive Data**: Avoid storing sensitive data locally if it is not required for app functionality, e.g. keep PII server-side, render it at time of use, and remove any cached data on logout. -- **Restrict File Access**: Never use `MODE_WORLD_READABLE`/`MODE_WORLD_WRITEABLE`; share data through a properly configured `ContentProvider`/`FileProvider` with per-grant permissions instead, and on iOS store Keychain items with the strictest viable accessibility attribute (e.g. `kSecAttrAccessibleWhenUnlockedThisDeviceOnly`). +- **Restrict File Access**: Use platform APIs to restrict file access as much as possible (least privilege principle). On Android, share data through a properly configured `ContentProvider`/ `FileProvider` with per-grant permissions instead of the deprecated `MODE_WORLD_READABLE`/`MODE_WORLD_WRITEABLE` file permission modes. On iOS, store Keychain items with the strictest viable accessibility attribute (e.g. `kSecAttrAccessibleWhenUnlockedThisDeviceOnly`). - **Remove Data When No Longer Needed**: Clear sensitive data, caches, and temporary files as soon as they are no longer needed (e.g. on logout or when leaving a sensitive flow) to limit the window during which they can be exposed. - **Use Platform Keystores**: Store cryptographic keys exclusively using the platform's hardware-backed keystore solution, such as the Android Keystore or the iOS Keychain. - **Encrypt Data at Rest**: For other files and preferences, use platform-provided features for encrypting data at rest or techniques implementing envelope encryption with Data Encryption Keys (DEK) and Key Encryption Keys (KEK) or equivalent methods. For example, on Android, use [`EncryptedFile`](https://developer.android.com/reference/androidx/security/crypto/EncryptedFile) or [`EncryptedSharedPreferences`](https://developer.android.com/reference/androidx/security/crypto/EncryptedSharedPreferences); on iOS, use [iOS Data Protection](https://developer.apple.com/documentation/uikit/protecting_the_user_s_privacy/encrypting_your_app_s_files). diff --git a/weaknesses/MASVS-STORAGE/MASWE-0004.md b/weaknesses/MASVS-STORAGE/MASWE-0004.md index 3d4b755..f5a19bf 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0004.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0004.md @@ -25,13 +25,13 @@ status: new This weakness occurs when an app stores sensitive data unencrypted in shared or external storage, where other apps can access it without any user interaction. -Apps frequently opt to store data in external storage due to its larger capacity. However, once another app is granted the relevant permissions, it can access this data at any time. External storage such as SD cards can also be physically removed and read. Even when external storage is emulated by the system, improper file permissions or misuse of file-saving APIs can leave files open to unauthorized access, modification, or deletion. +On Android, apps can store data explicitly in an app-specific external storage (`getExternalFilesDir()`), use the `MediaStore`-API or Storage Access Framework (SAF) to access shared folders. The app-specific external storage can not be accessed by other apps. However, if the external storage is located on a physical SD card, it can be removed and read. If the external storage is emulated by the system, actors with access to an unlocked phone can access it using _Android Debug Bridge (ADB)_. -This weakness primarily concerns Android, which permits the use of shared and external storage. On iOS, apps cannot directly write to or read from arbitrary locations; the system enforces strict sandboxing so apps can only access their own sandboxed file directories. +This weakness primarily concerns Android, which permits the explicit use of shared and external storage. However, while it is not possible to directly read and write an external folder on iOS, apps can use the by default pre-installed Files app or the document picker to read and write to a system-wide shared location. ## Modes of Introduction -- **Data Stored Unencrypted**: Writing sensitive data to shared or external storage unencrypted. +- **Data Stored Unencrypted**: Writing sensitive data to shared or external storage unencrypted. On Android, this also includes the app-specific external storage. - **Hardcoded Encryption Key**: Encrypting sensitive data stored in external storage with a key that is hardcoded inside the application. - **Encryption Key Stored on Filesystem**: Encrypting sensitive data stored in external storage but storing the key alongside it or in another easily accessible location. - **Insufficient Encryption**: Encrypting sensitive data with an algorithm or configuration that is not considered strong. @@ -42,11 +42,11 @@ This weakness primarily concerns Android, which permits the use of shared and ex - **Compromise of Sensitive Data**: Attackers can extract personal information and media such as photos, documents, and audio files, resulting in unauthorized disclosure of user data. - **Authentication or Authorization Bypass**: Attackers can extract passwords, cryptographic keys, and session tokens, resulting in identity theft or account takeover. - **Bypass of Protection Mechanisms**: Attackers can tamper with data used by the app, e.g. a database describing the state of premium features, resulting in circumvention of business logic and revenue loss for the app owner. -- **Execution of Unauthorized Code**: Attackers can modify executable code or inject malicious payloads (e.g. enabling SQL injection or path traversal) into files that the app loads or processes from external storage, resulting in code execution or further compromise within the app's context. ## Mitigations -- **Prefer Private Storage**: Store files in the [private app sandbox or internal storage](https://developer.android.com/training/data-storage/app-specific#internal) whenever possible, or use shared storage mechanisms that require user interaction for access. +- **Prefer Private Storage**: Store files in the [private internal storage](https://developer.android.com/training/data-storage/app-specific#internal) whenever possible. +- **Limit Platform File Sharing**: Prohibit sensitive data to be shared using the platform's storage sharing frameworks such as Storage Access Framework (SAF) on Android or document picker on iOS whenever possible. - **Encrypt Data Before Writing**: Encrypt any sensitive data stored in shared or external storage, e.g. using [Android's `EncryptedFile` API](https://developer.android.com/reference/androidx/security/crypto/EncryptedFile). - **Protect Encryption Keys**: Protect any keys used for data encryption with the device's hardware-backed keystore where available, and never hardcode them inside the application. diff --git a/weaknesses/MASVS-STORAGE/MASWE-0005.md b/weaknesses/MASVS-STORAGE/MASWE-0005.md index d9cd2a4..60b304e 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0005.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0005.md @@ -10,7 +10,7 @@ attacks: [MAS-ATTACK-0001, MAS-ATTACK-0005, MAS-ATTACK-0008] mappings: masvs-v1: [MSTG-STORAGE-1, MSTG-CRYPTO-1] masvs-v2: [MASVS-STORAGE-1, MASVS-CRYPTO-2] - cwe: [312, 318, 321, 322] + cwe: [312, 318, 321] android-risks: - hardcoded-cryptographic-secrets maswe-beta: [MASWE-0013, MASWE-0014, MASWE-0016] @@ -32,13 +32,15 @@ Cryptographic keys are essential for securing sensitive data in mobile applicati - **Insecure Storage Locations**: Storing cryptographic keys in locations that are not designed for secure storage, such as regular configuration or user preferences files, application data directories, or other areas lacking encryption and access control mechanisms. - **Hardcoded Cryptographic Keys**: Including cryptographic keys directly in the application code or in resources shipped with the app package. -- **Insecure Imported Keys**: Importing cryptographic keys from untrusted sources or without validating their integrity. +- **Insecure Key Import**: Importing keys into the keystore in plaintext instead of using secure wrapped or encrypted import, exposing the key material outside the secure environment. ## Impact - **Compromise of Sensitive Data**: Attackers can decrypt protected information or forge encrypted data, resulting in unauthorized disclosure or modification of sensitive data. - **Authentication or Authorization Bypass**: Attackers can create valid cryptographic values or impersonate trusted parties, resulting in unauthorized access to protected accounts, data, or functionality. - +- **Bypass of Protection Mechanisms**: Attackers can forge licensing, entitlement, or integrity tokens signed with a compromised key to unlock restricted features or defeat client-side checks, resulting in circumvention of the protections the app enforces. +- **Financial Loss**: Attackers can abuse a compromised key that authenticates to a paid or metered backend service to run up usage on the owner's account, resulting in unexpected charges to the app owner. + ## Mitigations - **Use Platform Keystores**: Where possible, generate cryptographic keys dynamically on the device, rather than using predefined keys, and ensure that they are securely stored after creation. For this you can use the platform-specific keystores, such as the [Android Keystore](https://developer.android.com/training/articles/keystore) or the [iOS Keychain](https://developer.apple.com/documentation/security/keychain_services). diff --git a/weaknesses/MASVS-STORAGE/MASWE-0006.md b/weaknesses/MASVS-STORAGE/MASWE-0006.md index b8f7408..e5b7cd1 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0006.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0006.md @@ -10,7 +10,7 @@ attacks: [MAS-ATTACK-0001] mappings: masvs-v1: [MSTG-STORAGE-1, MSTG-CODE-2] masvs-v2: [MASVS-STORAGE-1] - cwe: [312, 540, 798] + cwe: [312, 321, 540, 798] android-risks: - insecure-api-usage maswe-beta: [MASWE-0005, MASWE-0013, MASWE-0036] @@ -41,14 +41,14 @@ Note that developer _debug_ artifacts (verbose logging, backdoors, testing utili - **Financial Loss**: Attackers can abuse compromised API keys to make unauthorized billed API calls (e.g., AI/ML services), resulting in unexpected charges to the app owner. - **Compromise of System Integrity and Business Operations**: Attackers can use extracted credentials to access backend services, resulting in service disruption, policy-violation suspensions, or denial of service. - **Compromise of Sensitive Data**: Attackers can use extracted cryptographic material to decrypt protected data, resulting in unauthorized disclosure of user or app data. -- **Bypass of Protection Mechanisms**: Attackers can use hardcoded keys to unlock paid features or access restricted content, resulting in circumvention of app protections and revenue loss for the app owner. +- **Bypass of Protection Mechanisms**: Attackers can use hardcoded keys to unlock paid features or access restricted content, resulting in circumvention of the protections the app enforces. ## Mitigations -- **Use Stateful API Services**: Prefer API services that provide secure authentication, client validation, and session controls. Implement dynamic tokens that expire after a reasonably short time (e.g., 1 hour) to reduce the impact of key exposure, and ensure proper error handling and logging to detect unauthorized access attempts. Consider OAuth 2.0 and libraries such as AppAuth to simplify secure OAuth flows. -- **Proxy Static Secrets Through a Middleware**: If a stateful API service is not viable, front the stateless API with a middleware solution (API proxy or gateway) that proxies requests between the app and the API endpoint, keeping the static secret server-side rather than in the client. Use JSON Web Tokens (JWT) and JSON Web Signature (JWS) as appropriate. -- **Restrict Unavoidable Hardcoded Secrets**: If secrets must be hardcoded, configure them with the minimum required permissions and restrictions to reduce the impact in case of exposure. -- **Retrieve Secrets at Runtime**: Consider using a [Key Management Service](https://cloud.google.com/kms/docs/key-management-service) to retrieve secrets at runtime after validating app integrity. -- **Use Platform Keystores**: Store cryptographic keys and authentication material using the platform's hardware-backed keystore (Android Keystore, iOS Keychain) instead of embedding them in the package. See @MASWE-0005. -- **Audit for Leftover Secrets**: Regularly audit the codebase and dependencies for hardcoded sensitive data and developer leftovers (e.g. using tools such as [gitleaks](https://github.com/gitleaks/gitleaks)) and strip build artifacts and source files from release packages. -- **Harden Only as a Last Resort**: When no other secure option is available, use white-box cryptography, code/resource obfuscation, and RASP to raise the effort required to extract secrets, ensuring keys are only assembled in memory when needed. These techniques deter but do not prevent extraction and must not replace the mitigations above. +- **Proxy Static Secrets Through a Middleware**: If a stateful API service is not viable, front the stateless API with a middleware solution (API proxy or gateway) that proxies requests between the app and the API endpoint, keeping the static secret server-side rather than in the client. Use JSON Web Tokens (JWT) and JSON Web Signature (JWS) as appropriate. +- **Use Stateful API Services**: Prefer API services that provide secure authentication, client validation, and session controls. Implement dynamic tokens that expire after a reasonably short time (e.g., 1 hour) to reduce the impact of key exposure, and ensure proper error handling and logging to detect unauthorized access attempts. Consider OAuth 2.0 and libraries such as AppAuth to simplify secure OAuth flows. +- **Retrieve Secrets at Runtime**: Consider using a [Key Management Service](https://cloud.google.com/kms/docs/key-management-service) behind a middleware solution (API proxy or gateway) to retrieve secrets at runtime after validating device and app integrity and over a secure, pinned channel that protects the transferred secrets (see @MASWE-0027). +- **Restrict Unavoidable Hardcoded Secrets**: If secrets must be hardcoded, configure them with the minimum required permissions and restrictions to reduce the impact in case of exposure. +- **Use Platform Keystores**: Store cryptographic keys and authentication material using the platform's hardware-backed keystore (Android Keystore, iOS Keychain) instead of embedding them in the package. See @MASWE-0005. +- **Audit for Leftover Secrets**: Regularly audit the codebase and dependencies for hardcoded sensitive data and developer leftovers (e.g., using tools such as [gitleaks](https://github.com/gitleaks/gitleaks)) and strip build artifacts and source files from release packages. +- **Harden Only as a Last Resort**: When no other secure option is available, use white-box cryptography, code/resource obfuscation, and RASP to raise the effort required to extract secrets, ensuring keys are only assembled in memory when needed. These techniques deter but do not prevent extraction and must not replace the mitigations above. From 88192e395a7658fda0b380c7212eb5160bf72fdf Mon Sep 17 00:00:00 2001 From: Carlos Holguera Date: Sun, 26 Jul 2026 18:27:22 +0200 Subject: [PATCH 29/70] Apply suggestions from code review Co-authored-by: Jaco <43786394+jacobocasado@users.noreply.github.com> Co-authored-by: Carlos Holguera --- weaknesses/MASVS-PLATFORM/MASWE-0028.md | 4 ++-- weaknesses/MASVS-PLATFORM/MASWE-0030.md | 10 +++++----- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0028.md b/weaknesses/MASVS-PLATFORM/MASWE-0028.md index 9fb35e8..d902db8 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0028.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0028.md @@ -20,9 +20,9 @@ status: new ## Overview -This weakness occurs when an app exposes more sensitive data than is necessary for the user's current task through UI components or UI-mediated platform services (like the clipboard or the autocompletion feature). +This weakness occurs when an app exposes sensitive data beyond what is required for the user's current task, or exposes required data without protections proportionate to its sensitivity, through UI components or UI-mediated platform services, such as the clipboard or autocompletion features. -Typical exposure paths include displaying secrets or complete identifiers in cleartext when masking or a partial representation would suffice, using unprotected input fields for passwords or PINs, permitting unnecessary copy to the system clipboard, and enabling keyboard or IME (Input Method Editor) features that may retain or later suggest sensitive input. +Typical exposure paths include displaying secrets or complete identifiers in cleartext when masking or a partial representation would suffice, using unprotected input fields for passwords or PINs, permitting unnecessary copying to the system clipboard, and enabling keyboard or IME (Input Method Editor) features that may retain or later suggest sensitive input. ## Modes of Introduction diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0030.md b/weaknesses/MASVS-PLATFORM/MASWE-0030.md index 0bd9b95..370e86b 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0030.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0030.md @@ -1,5 +1,5 @@ --- -title: Sensitive Data Leaked via Screenshots or Screen Recordings +title: Insufficient Protection of Sensitive Data from Screenshots or Screen Recordings id: MASWE-0030 alias: data-leak-screenshots requirement: "The app removes or masks sensitive data from its views when moved to the background, when being recorded or when a screenshot is taken." @@ -21,11 +21,11 @@ status: new This weakness occurs when sensitive data displayed by the app can be captured in screenshots or screen recordings, or persists in system-generated snapshots, without the app preventing or redacting it. -Mobile platforms allow users, other apps, and external tools to capture screenshots or record the screen. In addition, when an app enters the background, the system may capture a snapshot of the app's current view to display in the app switcher, and store it on the file system. Any sensitive content visible on screen at that moment can end up in these images. +Mobile platforms allow users, privileged apps, and external tools to capture screenshots or record the screen. In addition, when an app enters the background, the system may capture a snapshot of the app's current view for display in the app switcher. Sensitive content that remains visible without appropriate protection can be retained in these images or recordings. ## Modes of Introduction -- **Screenshots and Screen Recordings Not Prevented**: Not implementing measures (such as setting secure window flags) to prevent the operating system or other apps from capturing screenshots or screen recordings of sensitive views. +- **Missing Platform Screenshot Protection**: Displaying sensitive fields without applying the related platform protections that can avoid the field information from appearing in screenshots or screen recordings (e.g., in Android, applying the [`FLAG_SECURE`]("https://developer.android.com/reference/android/view/WindowManager.LayoutParams#FLAG_SECURE") flag). - **Missing Capture-State Redaction**: Continuing to display sensitive information while the app or scene is being recorded, mirrored, or shared, despite the platform providing an API to detect the active capture state. - **Excessive On-Screen Disclosure**: Displaying complete sensitive values when a masked, partial, temporary, or user-initiated representation would be sufficient for the current task. @@ -35,5 +35,5 @@ Mobile platforms allow users, other apps, and external tools to capture screensh ## Mitigations -- **Prevent Screenshots and Screen Recording**: Mark views containing sensitive data as secure so the system blocks screenshots and screen recordings of them. -- **Redact Sensitive On-Screen Content**: Mask or redact sensitive content in the UI and replace or obscure the view before the system captures the background snapshot, so no confidential data is visible in captured images. +- **Redact Sensitive On-Screen Content**: Display only the portion of a sensitive value required for the current task. Mask values by default and unmask the values only for the needed actions, masking them again once they have been used for the task. +- **Anti-Screenshot Platform Protections**: Apply platform protections that prevent elements containing sensitive content from appearing in screenshots or on non-secure displays (for example, in Android, applying the [`FLAG_SECURE`]("https://developer.android.com/reference/android/view/WindowManager.LayoutParams#FLAG_SECURE") flag). From 58e49269c4c18e421864e54549b6918c59dde154 Mon Sep 17 00:00:00 2001 From: Carlos Holguera Date: Sun, 26 Jul 2026 18:45:21 +0200 Subject: [PATCH 30/70] Apply suggestions from code review Co-authored-by: Carlos Holguera Co-authored-by: Jaco <43786394+jacobocasado@users.noreply.github.com> --- weaknesses/MASVS-PLATFORM/MASWE-0029.md | 2 +- weaknesses/MASVS-PLATFORM/MASWE-0030.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0029.md b/weaknesses/MASVS-PLATFORM/MASWE-0029.md index f0720da..97f4dfb 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0029.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0029.md @@ -21,7 +21,7 @@ status: new This weakness occurs when an app includes more sensitive data (such as one-time codes, message contents, or account details) than necessary in a system notification. -Notifications can be rendered on the lock screen, and therefore, anyone holding the device can read them without unlocking it. They also can be read by other apps that hold notification access (e.g. an Android [`NotificationListenerService`](https://developer.android.com/reference/android/service/notification/NotificationListenerService)). Any sensitive value included in a notification therefore leaves the app's control the moment it is posted. +Notifications can be rendered on the lock screen, and therefore, anyone holding the device can read them without unlocking it. They also can be read by other apps that hold notification access, if the platform allows it (e.g. an Android [`NotificationListenerService`](https://developer.android.com/reference/android/service/notification/NotificationListenerService)). Any sensitive value included in a notification therefore leaves the app's control the moment it is posted. ## Modes of Introduction diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0030.md b/weaknesses/MASVS-PLATFORM/MASWE-0030.md index 370e86b..cf2c49d 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0030.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0030.md @@ -19,7 +19,7 @@ status: new ## Overview -This weakness occurs when sensitive data displayed by the app can be captured in screenshots or screen recordings, or persists in system-generated snapshots, without the app preventing or redacting it. +This weakness occurs when sensitive data displayed by an app can be captured in screenshots or screen recordings, and the app does not prevent the capture or conceal or redact the data when such protection is warranted. Mobile platforms allow users, privileged apps, and external tools to capture screenshots or record the screen. In addition, when an app enters the background, the system may capture a snapshot of the app's current view for display in the app switcher. Sensitive content that remains visible without appropriate protection can be retained in these images or recordings. From 4252ccde1901cb86e8bfd66f81f8a7f7066bb659 Mon Sep 17 00:00:00 2001 From: Carlos Holguera Date: Sun, 26 Jul 2026 19:18:02 +0200 Subject: [PATCH 31/70] Apply suggestions from code review Co-authored-by: Jan Seredynski --- weaknesses/MASVS-STORAGE/MASWE-0001.md | 1 - 1 file changed, 1 deletion(-) diff --git a/weaknesses/MASVS-STORAGE/MASWE-0001.md b/weaknesses/MASVS-STORAGE/MASWE-0001.md index 5227f8e..0e8b7c7 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0001.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0001.md @@ -42,6 +42,5 @@ Logging all possible information is very useful at development time, especially - **Avoid Logging Sensitive Data**: Do not log sensitive data at all; treat any user or system secret as unloggable by default. - **Redact Sensitive Data**: Where log statements are needed around sensitive values, redact or mask those values before writing them. -- **Remove Unnecessary Logging**: Strip logging statements from release builds unless they are deemed necessary to the app and explicitly identified as safe, e.g. as a result of a security audit. - **Use Log Levels Properly**: Assign debug-only details to debug or verbose levels and ensure those levels are disabled in production releases. - **Disable Logging in Production**: Use build flags or configuration to disable logging in production releases, following the platform guidance for [Android](log-info-disclosure#mitigations) and [iOS](https://developer.apple.com/documentation/os/logging/generating_log_messages_from_your_code#3665948). From f026ba64bf96bfd16ce0d288672fd57400d1417b Mon Sep 17 00:00:00 2001 From: Carlos Holguera Date: Sun, 26 Jul 2026 19:47:37 +0200 Subject: [PATCH 32/70] Apply suggestions from code review Co-authored-by: Carlos Holguera --- weaknesses/MASVS-CODE/MASWE-0045.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/weaknesses/MASVS-CODE/MASWE-0045.md b/weaknesses/MASVS-CODE/MASWE-0045.md index e985a33..bdd5851 100644 --- a/weaknesses/MASVS-CODE/MASWE-0045.md +++ b/weaknesses/MASVS-CODE/MASWE-0045.md @@ -9,7 +9,6 @@ threat: MAS-THREAT-0045 attacks: [MAS-ATTACK-0001, MAS-ATTACK-0059] mappings: masvs-v2: [MASVS-CODE-3, MASVS-CODE-4] - cwe: [693] android-risks: - use-of-native-code maswe-beta: [MASWE-0116] @@ -24,7 +23,7 @@ status: new This weakness occurs when an app's native code is built without the exploit-mitigation features that compilers and toolchains provide. -Mitigations such as stack canaries (stack-smashing protection), Address Space Layout Randomization via Position-Independent Executables (PIE/PIC), non-executable memory (NX/DEP), fortified (bounds-checked) libc functions, and Automatic Reference Counting on iOS do not remove memory-corruption bugs, but they substantially raise the effort required to exploit them. Binaries built without these features make any memory-corruption vulnerability, in the app's own code or its native dependencies, far easier to turn into code execution. +Mitigations such as stack canaries (stack-smashing protection), Address Space Layout Randomization (ASLR) via Position-Independent Executables (PIE/PIC), non-executable memory (NX/DEP), fortified (bounds-checked) libc functions, and Automatic Reference Counting (ARC) on iOS do not remove memory-corruption bugs, but they substantially raise the effort required to exploit them. Binaries built without these features make any memory-corruption vulnerability, in the app's own code or its native dependencies, far easier to turn into code execution. ## Modes of Introduction @@ -42,4 +41,3 @@ Mitigations such as stack canaries (stack-smashing protection), Address Space La - **Enable Compiler Mitigations**: Build all native code and dependencies with stack canaries, PIE/PIC, non-executable memory, and fortified functions enabled, and verify the flags in release binaries rather than assuming toolchain defaults. - **Keep Memory-Safety Features On**: Use Automatic Reference Counting on iOS and prefer memory-safe languages for new code where feasible. -- **Cover Third-Party Native Libraries**: Verify that prebuilt native dependencies were also compiled with these mitigations, since a single unprotected library weakens the whole process. From 010b44260220f9d3427ab6ec1b5dea37e601dece Mon Sep 17 00:00:00 2001 From: Jeroen Beckers Date: Mon, 27 Jul 2026 08:21:59 +0200 Subject: [PATCH 33/70] Apply suggestion from @serek8 Co-authored-by: Jan Seredynski --- weaknesses/MASVS-PLATFORM/MASWE-0039.md | 1 + 1 file changed, 1 insertion(+) diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0039.md b/weaknesses/MASVS-PLATFORM/MASWE-0039.md index d52f5e9..41b81f5 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0039.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0039.md @@ -41,3 +41,4 @@ Accessibility services (e.g. Android's `AccessibilityService`) can observe scree - **Use Secure Input Fields**: Mark secret fields as password/secure entry so platforms mask their content from accessibility reading. - **Add Friction to High-Risk Flows**: Require verification that UI automation cannot satisfy (e.g. biometric-bound confirmation, see @MASWE-0021) for the most sensitive actions. - **Preserve Legitimate Accessibility**: Minimize only the sensitive values exposed; never degrade the app's overall accessibility for assistive-technology users. +- **Use Custom Passcode Inputs**: Replace standard system keyboards with an in-app custom keypad for sensitive entry fields, preventing accessibility services from capturing or announcing typed credentials. From a39c022005a9eb53de3de460b75f4a27457bbdd0 Mon Sep 17 00:00:00 2001 From: Jeroen Beckers Date: Mon, 27 Jul 2026 08:22:44 +0200 Subject: [PATCH 34/70] Apply suggestions from code review Co-authored-by: Jan Seredynski --- weaknesses/MASVS-PLATFORM/MASWE-0039.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0039.md b/weaknesses/MASVS-PLATFORM/MASWE-0039.md index 41b81f5..7cbc8c9 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0039.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0039.md @@ -28,6 +28,7 @@ Accessibility services (e.g. Android's `AccessibilityService`) can observe scree - **Secrets in Accessibility Metadata**: Exposing sensitive values through accessibility node text, labels, or hints beyond what assistive technology needs. - **Sensitive Fields Not Using Secure Input**: Presenting secret input in fields that are not marked as password/secure entry, so their content is readable through accessibility APIs. - **High-Risk Flows Fully Automatable**: Designing sensitive flows (e.g. payments) so that they can be completed entirely through programmatic UI interaction without any additional verification. +- **System Keyboards Exposing Sensitive Input**: Relying on standard system keyboards for passcode or PIN entry, which allows keyboard events and typed credentials to be captured by accessibility services. ## Impact @@ -42,3 +43,4 @@ Accessibility services (e.g. Android's `AccessibilityService`) can observe scree - **Add Friction to High-Risk Flows**: Require verification that UI automation cannot satisfy (e.g. biometric-bound confirmation, see @MASWE-0021) for the most sensitive actions. - **Preserve Legitimate Accessibility**: Minimize only the sensitive values exposed; never degrade the app's overall accessibility for assistive-technology users. - **Use Custom Passcode Inputs**: Replace standard system keyboards with an in-app custom keypad for sensitive entry fields, preventing accessibility services from capturing or announcing typed credentials. +- **Use Custom Passcode Inputs**: Replace standard system keyboards with an in-app custom keypad for sensitive entry fields, preventing accessibility services from capturing or announcing typed credentials. From c4c49cd908dc402001c7a8d96a4af18e6cde224a Mon Sep 17 00:00:00 2001 From: Carlos Holguera Date: Mon, 27 Jul 2026 11:35:39 +0200 Subject: [PATCH 35/70] update 0065 after review --- weaknesses/MASVS-PRIVACY/MASWE-0065.md | 22 ++++++++++------------ 1 file changed, 10 insertions(+), 12 deletions(-) diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0065.md b/weaknesses/MASVS-PRIVACY/MASWE-0065.md index a7d9882..4da5315 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0065.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0065.md @@ -16,8 +16,7 @@ refs: - https://gdpr-info.eu/recitals/no-26/ - https://gdpr-info.eu/recitals/no-28/ - https://gdpr-info.eu/art-4-gdpr/ -- -https://www.edpb.europa.eu/topics/ai-and-technology/anonymisation-pseudonymisation_en +- https://www.edpb.europa.eu/topics/ai-and-technology/anonymisation-pseudonymisation_en - https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2014/wp216_en.pdf - https://www.statista.com/topics/9460/app-tracking-and-mobile-privacy/ status: new @@ -25,25 +24,24 @@ status: new ## Overview -This weakness occurs when an app processes or shares user data without applying unlinkability techniques such as data abstraction, anonymization, or pseudonymization, allowing individuals to be identified and tracked across different services and over time. +This weakness occurs when an app processes or shares user data without applying anonymization, or pseudonymization measures allowing individuals to be identified and potentially tracked across different services and over time. -This weakness occurs when an app processes or shares user data without applying privacy measures such as data abstraction, anonymization, pseudonymization, or unlinkability protocols. This can allow individuals to be identified and tracked across services and over time. - -Anonymization uses techniques such as randomization or generalization to irreversibly prevent identification. Pseudonymization replaces identifiable data with tokens or hashed values, but may remain reversible when additional information is available. Privacy preserving protocols can provide further unlinkability. [Private Information Retrieval (PIR)](https://en.wikipedia.org/wiki/Private_information_retrieval) hides which data a user retrieves, while [Oblivious HTTP (OHTTP)](https://www.ietf.org/rfc/rfc9458.html) separates the user identity from the request content. +Anonymization uses techniques such as randomization or generalization to irreversibly prevent identification. Pseudonymization replaces identifiable data with tokens or hashed values, but may remain reversible when additional information is available. ## Modes of Introduction -- **Direct Identifiers Not Removed**: Failing to remove or transform direct identifiers, such as user ID or name, before server-side collection, or to manipulate the data to prevent linkage to real-world identities. -- **Not Implementing Privacy-Preserving Protocols**: Failing to use protocols such as PIR or OHTTP. -- **Sensitive Data Not Redacted Before Passing to AI**: Sending unredacted sensitive or personal data to AI services without first removing or masking identifiers, where it may also be retained and used to train models. +- **Identifiers Not Removed**: Failing to remove or transform identifiers, such as user ID or name, before server-side collection. +- **Pseudonymization Implemented Insecurely**: Using predictable or stable hashes, reusing pseudonyms across unrelated contexts, or storing keys or mapping data together with the pseudonymized data. +- **Sensitive Metadata Not Removed**: Failing to remove private or sensitive metadata, such as geolocation from Exif data, before server-side collection. +- **Sensitive Data Not Redacted Before Sending to AI Services**: Sending unredacted sensitive or personal data to AI services. ## Impact -- **Violation of User Privacy**: Third parties can profile users and target them with advertising without consent, resulting in the loss of users' control over their personal information and its unforeseen use, e.g. to train AI models. +- **Violation of User Privacy**: Third parties can profile users and target them with advertising without consent, resulting in the loss of users' control over their personal information, retention and its unforeseen use, e.g. to train AI models. - **Legal and Regulatory Non-Compliance**: Processing personal data without de-identification safeguards can violate data protection laws and regulations (like GDPR), resulting in legal consequences and fines for the app owner. +- **Loss of User Trust**: Unexpected identification, tracking, or secondary use of personal data can reduce user confidence in the app. ## Mitigations - **Use Anonymisation and Pseudonymisation**: Ensure techniques like anonymisation and pseudonymisation are implemented to prevent user identification. -- **Implement Privacy-Preserving Protocols**: Use protocols such as PIR or OHTTP. -- **Redact Sensitive Data Before Passing to AI**: Before sending data to AI services, redact or mask sensitive fields and identifiers so that personal data is not exposed to (or used to train) third-party models. +- **Redact Sensitive Data Before Sending to AI Services**: Before sending data to AI services, redact or mask sensitive fields and identifiers so that personal data is not exposed to (or used to train) third-party models. From b6093008b59832fc79666757b131a4acee1257da Mon Sep 17 00:00:00 2001 From: Carlos Holguera Date: Mon, 27 Jul 2026 11:49:38 +0200 Subject: [PATCH 36/70] Add new MASWE-0078 --- weaknesses/MASVS-PRIVACY/MASWE-0078.md | 49 ++++++++++++++++++++++++++ 1 file changed, 49 insertions(+) create mode 100644 weaknesses/MASVS-PRIVACY/MASWE-0078.md diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0078.md b/weaknesses/MASVS-PRIVACY/MASWE-0078.md new file mode 100644 index 0000000..6399d5d --- /dev/null +++ b/weaknesses/MASVS-PRIVACY/MASWE-0078.md @@ -0,0 +1,49 @@ +--- +title: Inadequate Awareness and Unsafe Defaults for Privacy Relevant Actions +id: MASWE-0078 +alias: user-awareness-unsafe-defaults-privacy-actions +requirement: "Before completing a privacy relevant action, the app clearly communicates the affected data, destination, audience, and material privacy consequences, and defaults to the least exposing option appropriate for the requested functionality." +platform: [android, ios] +profiles: [P] +threat: MAS-THREAT-0070 +attacks: [MAS-ATTACK-0084, MAS-ATTACK-0087] +mappings: + masvs-v2: [MASVS-PRIVACY-2] + cwe: [359] + maswe-beta: [MASWE-0109] +refs: +- https://cloud.google.com/sensitive-data-protection/docs/classification-redaction +- https://gdpr-info.eu/recitals/no-26/ +- https://gdpr-info.eu/recitals/no-28/ +- https://gdpr-info.eu/art-4-gdpr/ +- https://www.edpb.europa.eu/topics/ai-and-technology/anonymisation-pseudonymisation_en +- https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2014/wp216_en.pdf +- https://www.statista.com/topics/9460/app-tracking-and-mobile-privacy/ +status: new +--- + +## Overview + +This weakness occurs when an app performs a privacy relevant action without making its scope or material consequences reasonably apparent to the user, or when the app uses defaults that expose more data than is necessary for the expected functionality. + +Privacy relevant actions include sharing, exporting, publishing, synchronizing, backing up, changing visibility, responding to a request from another party, or moving data from private app storage to storage or services accessible by other applications, users, or third parties. + +The weakness may cause users to disclose different data, disclose data to a broader audience, or create more persistent copies than they reasonably intended. It includes flows where the app honors another party's request for data without clearly showing the user what will be shared and with whom, or allowing the user to control the disclosure. It does not require the underlying processing to rely on consent. The issue is whether the interface and defaults allow the user to understand and control the resulting privacy state. + +## Modes of Introduction + +- **Unclear Disclosure Context**: The interface or action labels do not clearly identify the affected records, files, accounts, data elements, included metadata, destination, audience, or resulting privacy state, including when responding to another party's request for data. +- **Overly Exposing Defaults**: The app preselects broader audiences, more data, longer retention, public visibility, or additional recipients when a less exposing default would satisfy the expected functionality. +- **Insufficient Disclosure Review and Feedback**: The app does not allow the user to review, control, or confirm a consequential disclosure, or clearly indicate that a high impact or difficult to reverse disclosure has occurred. + +## Impact + +- **Violation of User Privacy**: The app can disclose personal or sensitive data to recipients who are not entitled to receive it under the user's sharing choices, resulting in unauthorized exposure of that data. +- **Loss of User Trust**: Users can discover that the app shared data without their awareness or control, resulting in reduced confidence in the app and its owner. +- **Legal and Regulatory Non-Compliance**: The app can share personal data without adequate transparency or user control, resulting in violations of privacy obligations and potential enforcement action. + +## Mitigations + +- **Provide Clear Disclosure Context and Control**: At the point of action, show the affected data, included metadata, destination, audience, and material privacy consequences; before responding to another party's request for data, identify the requester and recipient and allow the user to approve, limit, or decline the disclosure. +- **Use Privacy Protective Defaults**: Default to the narrowest audience, smallest data set, shortest appropriate persistence, and least exposing destination that supports the requested functionality. +- **Support Review and Reversal of Consequential Disclosures**: Before completion, allow users to review selected items, recipients, audience, included metadata, and visibility; make the resulting privacy state visible and provide proportionate confirmation or undo mechanisms when practical. From 2ebda61dcd4e02232ba174f2cd423b48ecafd278 Mon Sep 17 00:00:00 2001 From: Carlos Holguera Date: Mon, 27 Jul 2026 11:54:59 +0200 Subject: [PATCH 37/70] already covered in 0078 --- weaknesses/MASVS-PRIVACY/MASWE-0071.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0071.md b/weaknesses/MASVS-PRIVACY/MASWE-0071.md index adfd594..db66f37 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0071.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0071.md @@ -6,7 +6,7 @@ requirement: "The app requests user consent prior to any data processing." platform: [android, ios] profiles: [P] threat: MAS-THREAT-0071 -attacks: [MAS-ATTACK-0085, MAS-ATTACK-0086, MAS-ATTACK-0087] +attacks: [MAS-ATTACK-0085, MAS-ATTACK-0086] mappings: masvs-v2: [MASVS-PRIVACY-4] cwe: [200, 285, 358, 359] @@ -30,7 +30,6 @@ In addition, users must be able to easily withdraw their consent at any time and - **Failure to Prompt for Consent Changes**: Failing to prompt the user for consent when data collection practices change or when additional data is collected beyond what was originally specified. - **Ambiguous Consent Mechanisms**: Bundling consent with terms of service, often covering future use cases without notifying the user again, or implying consent when the user doesn't explicitly deny access. -- **Lack of User Awareness When Exporting Data**: Designing sharing or exporting flows that do not make the user aware of the privacy consequences of their action. For example, when a user "Saves" a picture, not warning them that the data will be exported to public/shared storage, or when using the share sheet, not being explicit about which items are shared. ## Impact @@ -43,4 +42,3 @@ In addition, users must be able to easily withdraw their consent at any time and - **Prompt for Consent on Changes**: Establish mechanisms for prompting users for consent if data collection practices change or if additional data is being collected, ensuring transparency when app functionality evolves. - **Obtain Clear and Explicit User Consent for Immediate Actions**: Before accessing sensitive resources like sensors or local data (e.g., camera, location), always request explicit permission from the user. Clearly explain why the permission is needed, using mechanisms like [purpose strings](https://developer.apple.com/documentation/uikit/protecting_the_user_s_privacy/requesting_access_to_protected_resources) on iOS or [similar prompts](https://developer.android.com/training/permissions/requesting#explain) on Android, to ensure users understand the immediate use of their data. - **Ensure Informed and Transparent Consent**: Provide users with clear, specific information about what data will be collected, how it will be used, and the potential impact. Consent should not be hidden in terms of service or bundled for future uses. Users must confirm consent separately for each purpose, especially when permissions extend beyond the initial request. -- **Make Users Aware When Exporting or Sharing Data**: When the user shares or exports data (e.g. saving media to shared storage or using the system share sheet), surface the privacy consequences so they can make an informed choice, and default share flows to the least-exposing option. From 181addfebee0369e0c5ab0281d8ce957a145a2c7 Mon Sep 17 00:00:00 2001 From: Carlos Holguera Date: Mon, 27 Jul 2026 12:10:52 +0200 Subject: [PATCH 38/70] address feedback for 0072 and 0074 --- .github/instructions/attacks.yaml | 3 ++- weaknesses/MASVS-PRIVACY/MASWE-0072.md | 16 ++++++++++------ weaknesses/MASVS-PRIVACY/MASWE-0074.md | 8 +++++--- 3 files changed, 17 insertions(+), 10 deletions(-) diff --git a/.github/instructions/attacks.yaml b/.github/instructions/attacks.yaml index 3b91f49..06795c6 100644 --- a/.github/instructions/attacks.yaml +++ b/.github/instructions/attacks.yaml @@ -86,4 +86,5 @@ MAS-ATTACK-0085: Collecting data under consent that is bundled, implied, or othe MAS-ATTACK-0086: Continuing to collect data under an outdated consent after practices have changed. MAS-ATTACK-0087: Exporting or sharing data through flows whose privacy consequences are not evident to the user. MAS-ATTACK-0088: Holding excessive or no-longer-needed permissions granted to the app. -MAS-ATTACK-0089: Inheriting the app's permissions in third-party SDKs, whose data collection is difficult to audit and control. +MAS-ATTACK-0089: Using permissions granted to the host app to call protected APIs and collect data from a third-party SDK. +MAS-ATTACK-0090: Forging a MAC or tag by exploiting non-constant-time verification or distinguishable error responses. diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0072.md b/weaknesses/MASVS-PRIVACY/MASWE-0072.md index 6678efd..28b6de8 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0072.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0072.md @@ -23,6 +23,8 @@ refs: - https://arxiv.org/pdf/2203.10583 - https://ieeexplore.ieee.org/document/9001128 - https://www.enisa.europa.eu/sites/default/files/publications/WP2017%20O-2-2-4%20GDPR%20Mobile.pdf +- https://developer.android.com/privacy-and-security/risks/ai-risks/excessive-agency +- https://developer.android.com/privacy-and-security/risks/ai-risks/sensitive-information-disclosure status: new --- @@ -34,25 +36,27 @@ Permissions control access to sensitive device features such as the camera, micr Developers face the challenge of balancing functionality with privacy: while some permissions are essential for core features (e.g., a camera app requiring camera access), excessive permissions enable unnecessary data collection. From the user's perspective, privacy concerns may lead to reluctance in granting permissions, forcing them to choose between privacy and app functionality, while other users may grant permissions without fully understanding the implications. Pre-installed apps aggravate the problem, as they frequently come with excessive permissions that are granted by default and that users cannot control or revoke. -Third-party libraries (SDKs) further complicate permission management by inheriting app permissions and introducing privacy and security risks that are difficult to audit and control. Mobile permission models often fail to distinguish between permissions granted to an app and those assigned to third-party components, a challenge highlighted in the [IEEE research paper "Engineering Privacy in Smartphone Apps"](https://ieeexplore.ieee.org/document/9001128) (Section IV, _"Third-party content"_). Furthermore, third-party services behind these SDKs may continue accessing data collected over the network even after permissions are revoked or the app is deleted. +Third-party libraries (SDKs) further complicate permission management by requiring permissions that the app itself does not need and by using the app's granted permissions to collect data. Similarly, AI-enabled features can be given permission-backed tools that allow them to access sensitive data or act on the user's behalf beyond what the feature requires. Mobile permission models often fail to distinguish between permissions granted to an app and those assigned to third-party components, a challenge highlighted in the [IEEE research paper "Engineering Privacy in Smartphone Apps"](https://ieeexplore.ieee.org/document/9001128) (Section IV, _"Third-party content"_). Furthermore, third-party services behind these SDKs may continue accessing data collected over the network even after permissions are revoked or the app is deleted. ## Modes of Introduction - **Requesting Excessive Permissions**: Requesting more permissions than necessary for the app's core functionality. -- **Lack of Use of Privacy-Friendly Alternatives**: Failing to use privacy-friendly alternatives that are less intrusive than permissions. For example, using coarse location instead of fine location, or using an image picker instead of requesting access to the camera and photo gallery. -- **Lack of Proactive Permission Revocation**: Not relinquishing or revoking permissions that are no longer necessary, resulting in unnecessary data access over time. +- **Lack of Use of Privacy-Friendly Alternatives**: Failing to use less intrusive alternatives, such as requesting fine location when coarse location would suffice or requesting camera and photo-library access instead of using an image picker. +- **Retaining Unneeded Permissions**: Not revoking permissions that are no longer necessary. - **Inadequate Permission Explanations**: Failing to provide clear explanations for why each permission is required. +- **Third-Party Permission Requirements**: Including SDKs that require permissions beyond the app's functional needs or use granted permissions to collect and analyze data. +- **Excessive AI Agent Permissions**: Giving an AI-enabled feature permission-backed tools or data access beyond what it requires for its intended task. ## Impact -- **Violation of User Privacy**: Apps and embedded components can unnecessarily access personal data such as location, contacts, or media, resulting in misuse, surveillance, or profiling of the user. -- **Compromise of Sensitive Data**: Third-party services can collect and retain data obtained through inherited permissions; once that data leaves the app its security can no longer be guaranteed, resulting in an increased risk of large-scale exposure via data breaches. +- **Violation of User Privacy**: Apps and embedded components can use unnecessarily granted access to collect location, contacts, or media, resulting in tracking, surveillance, or profiling of the user. +- **Compromise of Sensitive Data**: Apps and embedded components can retain sensitive data collected through unnecessary permissions, resulting in broader exposure of that data when the app or a third-party service suffers a data breach. - **Loss of User Trust**: Users can perceive permission requests as unjustified, resulting in refused permissions, negative reviews, lower user engagement, and reduced retention for the app owner. - **Legal and Regulatory Non-Compliance**: Requesting or retaining unnecessary permissions can violate data minimization requirements in regulations like GDPR or CCPA, resulting in fines, legal action, or removal from app stores for the app owner. ## Mitigations -- **Limit Permissions to Essential Needs**: Ensure the app only requests permissions necessary for core functionality, avoiding the collection of unnecessary data and adhering to the principle of data minimization. +- **Limit Permissions to Essential Needs**: Ensure the app and any AI-enabled features only request permissions necessary for core functionality, avoiding the collection of unnecessary data and adhering to the principle of data minimization. - **Prefer Privacy-Friendly Alternatives**: Use privacy-friendly alternatives to permissions that are less intrusive and provide users with more control over their data. For example, use coarse location instead of fine location, or use an image picker instead of requesting access to the camera and photo gallery. - **Enable Proactive Permission Revocation**: Automatically relinquish permissions that are no longer necessary to minimize unnecessary data access over time, and ensure that users can manually revoke permissions at any time through a clear and accessible interface. - **Implement Just-in-Time Permission Requests**: Request permissions only when they are needed, providing clear explanations for why each permission is required. This approach helps build user trust and ensures users understand the implications of granting access to their data. diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0074.md b/weaknesses/MASVS-PRIVACY/MASWE-0074.md index d905cc2..55c7348 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0074.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0074.md @@ -23,22 +23,24 @@ status: new This weakness occurs when an app uses functionality that unnecessarily exposes user data even though the platform provides a privacy-preserving alternative. -Platforms increasingly offer least-exposing APIs for common tasks: system authentication sessions (`ASWebAuthenticationSession` on iOS, Custom Tabs on Android, per [RFC 8252, Appendix B](https://datatracker.ietf.org/doc/html/rfc8252#appendix-B)) keep credentials and browsing state isolated from the app, and system pickers (e.g. `PHPickerViewController` on iOS, the Android Photo Picker) return only the items the user selects without any broad permission grant. Choosing the non-privacy-preserving option leads to avoidable data exposure and over-collection. This is the privacy-focused counterpart to @MASWE-0047, which applies the same "prefer platform-provided functionality" principle from a security angle; some features, such as system authentication sessions, improve both. +Platforms increasingly offer least-exposing APIs for common tasks: system authentication sessions (`ASWebAuthenticationSession` on iOS, Custom Tabs on Android, per [RFC 8252, Appendix B](https://datatracker.ietf.org/doc/html/rfc8252#appendix-B)) keep credentials and browsing state isolated from the app, system pickers (e.g. `PHPickerViewController` on iOS, the Android Photo Picker) return only the items the user selects without any broad permission grant, and on-device processing can avoid sending data to remote AI services. Choosing the non-privacy-preserving option leads to avoidable data exposure and over-collection. This is the privacy-focused counterpart to @MASWE-0047, which applies the same "prefer platform-provided functionality" principle from a security angle; some features, such as system authentication sessions, improve both. ## Modes of Introduction - **Embedded Authentication Flows**: Handling third-party authentication in embedded WebViews or deprecated session APIs, exposing credentials and browsing state to the app, instead of isolated system authentication sessions. - **Broad Permissions Instead of Pickers**: Requesting full photo-library, camera, or file access when a system picker would return only the user-selected items without any permission. +- **Remote Processing Instead of On-Device AI**: Sending user data to remote AI services when on-device processing can support the feature. - **Over-Exposing API Choices**: Choosing APIs that reveal more user data than the feature requires when a least-exposing platform alternative exists (see also @MASWE-0072). ## Impact -- **Violation of User Privacy**: The app and its embedded components can observe credentials, browsing state, or whole data collections (e.g. the entire photo library) that a privacy-preserving alternative would never have exposed, resulting in avoidable over-collection of personal data. -- **Compromise of Sensitive Data**: Data unnecessarily accessible to the app can be leaked through any other weakness or through embedded third parties, resulting in exposure of user data that the app never needed to hold. +- **Violation of User Privacy**: The app and its embedded components can collect and correlate credentials, browsing state, or whole data collections that a privacy-preserving alternative would never have exposed, resulting in tracking, surveillance, or profiling of the user. +- **Compromise of Sensitive Data**: The app and its embedded components can retain data that a privacy-preserving alternative would not expose, resulting in broader exposure when the app or a third-party service suffers a data breach. - **Loss of User Trust**: Users can perceive unnecessary permission prompts and embedded login flows as invasive, resulting in refused permissions, abandoned logins, and reduced retention. ## Mitigations - **Use System Authentication Sessions**: Authenticate against third-party services with `ASWebAuthenticationSession` on iOS or Custom Tabs on Android, following RFC 8252, instead of embedded WebViews or deprecated APIs. - **Prefer System Pickers**: Use the system photo, file, and contact pickers so the app receives only what the user explicitly selects, without broad permission grants. +- **Prefer On-Device Processing**: Use on-device AI or other local processing when it can support the feature without sending user data to a remote service. - **Choose Least-Exposing APIs**: When the platform offers a privacy-preserving variant of a capability, prefer it and request broad access only when the feature genuinely requires it (see @MASWE-0072). From 6780fb970bca23659a1f2da32a15cb0a022ee176 Mon Sep 17 00:00:00 2001 From: Jeroen Beckers Date: Mon, 27 Jul 2026 15:23:06 +0200 Subject: [PATCH 39/70] Apply suggestion from @jacobocasado Co-authored-by: Jaco <43786394+jacobocasado@users.noreply.github.com> --- weaknesses/MASVS-RESILIENCE/MASWE-0051.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0051.md b/weaknesses/MASVS-RESILIENCE/MASWE-0051.md index a94297a..d30dd83 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0051.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0051.md @@ -13,7 +13,7 @@ mappings: cwe: [693] maswe-beta: [MASWE-0089, MASWE-0092] refs: -- https://developer.android.com/build/shrink-code +- https://developer.android.com/topic/performance/app-optimization/enable-app-optimization#overview status: new --- From 1946ff1df4376ae8ef1253731a0feaca96861a2d Mon Sep 17 00:00:00 2001 From: Jeroen Beckers Date: Mon, 27 Jul 2026 15:24:00 +0200 Subject: [PATCH 40/70] Apply suggestion from @jacobocasado Co-authored-by: Jaco <43786394+jacobocasado@users.noreply.github.com> --- weaknesses/MASVS-RESILIENCE/MASWE-0051.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0051.md b/weaknesses/MASVS-RESILIENCE/MASWE-0051.md index d30dd83..eb035fe 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0051.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0051.md @@ -19,7 +19,7 @@ status: new ## Overview -This weakness occurs when an app's code, particularly its security-relevant logic, ships without effective obfuscation, making reverse engineering and static analysis straightforward. +This weakness occurs when an app's code, particularly its security-relevant logic, ships without effective obfuscation, facilitating reverse engineering and static analysis. Obfuscation does not prevent reverse engineering, but it raises its cost. Effective schemes go beyond default identifier renaming and include techniques such as control-flow transformations, opaque predicates, instruction substitution, instruction block chopping, and method inlining, as well as hindering decompilers from producing usable output. Without them, attackers can quickly understand and locate the app's defenses and proprietary logic. From b3b03a566f57bbe6146175ecedb08719670a65c0 Mon Sep 17 00:00:00 2001 From: Jeroen Beckers Date: Mon, 27 Jul 2026 15:24:29 +0200 Subject: [PATCH 41/70] Apply suggestion from @jacobocasado Co-authored-by: Jaco <43786394+jacobocasado@users.noreply.github.com> --- weaknesses/MASVS-RESILIENCE/MASWE-0051.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0051.md b/weaknesses/MASVS-RESILIENCE/MASWE-0051.md index eb035fe..8e023e9 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0051.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0051.md @@ -21,7 +21,7 @@ status: new This weakness occurs when an app's code, particularly its security-relevant logic, ships without effective obfuscation, facilitating reverse engineering and static analysis. -Obfuscation does not prevent reverse engineering, but it raises its cost. Effective schemes go beyond default identifier renaming and include techniques such as control-flow transformations, opaque predicates, instruction substitution, instruction block chopping, and method inlining, as well as hindering decompilers from producing usable output. Without them, attackers can quickly understand and locate the app's defenses and proprietary logic. +Obfuscation does not prevent reverse engineering, but it raises its cost. Identifier renaming or string encryption are easier to implement and are considered common obfuscation techniques. However, there are other obfuscation techniques, like control-flow transformations, opaque predicates, instruction substitution, instruction block chopping, and method inlining, as well as hindering decompilers from producing usable output. Most of these techniques can be combined together. ## Modes of Introduction From 7b7541161b4ae160f245e45ee250778f27e260de Mon Sep 17 00:00:00 2001 From: Jeroen Beckers Date: Mon, 27 Jul 2026 15:25:13 +0200 Subject: [PATCH 42/70] Apply suggestion from @jacobocasado Co-authored-by: Jaco <43786394+jacobocasado@users.noreply.github.com> --- weaknesses/MASVS-RESILIENCE/MASWE-0051.md | 1 - 1 file changed, 1 deletion(-) diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0051.md b/weaknesses/MASVS-RESILIENCE/MASWE-0051.md index 8e023e9..f996e02 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0051.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0051.md @@ -27,7 +27,6 @@ Obfuscation does not prevent reverse engineering, but it raises its cost. Identi - **No Obfuscation Applied**: Shipping release builds without any minification or obfuscation, leaving class, method, and symbol names intact. - **Security-Relevant Logic Left Readable**: Applying only default renaming while leaving security checks, licensing logic, and proprietary algorithms trivially analyzable, without stronger techniques such as opaque predicates, instruction substitution, or control-flow transformations. -- **Effectiveness Never Assessed**: Never testing the obfuscation against current decompilers and deobfuscation tooling, so its actual strength is unknown. ## Impact From 4244fff06db77c9830f5d0c796cc85cc6b9c3177 Mon Sep 17 00:00:00 2001 From: Jeroen Beckers Date: Mon, 27 Jul 2026 15:25:32 +0200 Subject: [PATCH 43/70] Apply suggestion from @jacobocasado Co-authored-by: Jaco <43786394+jacobocasado@users.noreply.github.com> --- weaknesses/MASVS-RESILIENCE/MASWE-0051.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0051.md b/weaknesses/MASVS-RESILIENCE/MASWE-0051.md index f996e02..01b10f5 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0051.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0051.md @@ -35,7 +35,7 @@ Obfuscation does not prevent reverse engineering, but it raises its cost. Identi ## Mitigations -- **Enable Obfuscation for Release Builds**: Apply the platform's minification and obfuscation tooling (e.g. R8) or established commercial obfuscators to all release builds. +- **Enable Obfuscation for Release Builds**: Apply the platform's minification and obfuscation tooling or established commercial obfuscators to all release builds. - **Harden Security-Relevant Code**: Apply stronger transformations (opaque predicates, instruction substitution, control-flow obfuscation, method inlining) to the code implementing security checks and proprietary logic. - **Assess Obfuscation Effectiveness**: Regularly attempt to reverse engineer the release build with state-of-the-art decompilers and deobfuscators to validate that the protection meets its goal. - **Combine with Runtime Protections**: Pair obfuscation with runtime integrity and anti-instrumentation checks (see @MASWE-0053, @MASWE-0061, @MASWE-0064), since obfuscation alone only delays attackers. From 48339e49bf113031ee1de89b76f25b1e53434a6d Mon Sep 17 00:00:00 2001 From: Jeroen Beckers Date: Mon, 27 Jul 2026 15:25:59 +0200 Subject: [PATCH 44/70] Apply suggestion from @jacobocasado Co-authored-by: Jaco <43786394+jacobocasado@users.noreply.github.com> --- weaknesses/MASVS-RESILIENCE/MASWE-0051.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0051.md b/weaknesses/MASVS-RESILIENCE/MASWE-0051.md index 01b10f5..c92100c 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0051.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0051.md @@ -26,7 +26,7 @@ Obfuscation does not prevent reverse engineering, but it raises its cost. Identi ## Modes of Introduction - **No Obfuscation Applied**: Shipping release builds without any minification or obfuscation, leaving class, method, and symbol names intact. -- **Security-Relevant Logic Left Readable**: Applying only default renaming while leaving security checks, licensing logic, and proprietary algorithms trivially analyzable, without stronger techniques such as opaque predicates, instruction substitution, or control-flow transformations. +- **Security-Relevant Logic Left Readable**: Not applying enough obfuscation to security-relevant code, leaving code sections like security checks, licensing logic, and proprietary algorithms trivially analyzable. ## Impact From 2d1e08973f1269cb25d37044424b99a01e8c1a19 Mon Sep 17 00:00:00 2001 From: Jeroen Beckers Date: Mon, 27 Jul 2026 15:26:41 +0200 Subject: [PATCH 45/70] Apply suggestion from @jacobocasado Co-authored-by: Jaco <43786394+jacobocasado@users.noreply.github.com> --- weaknesses/MASVS-RESILIENCE/MASWE-0051.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0051.md b/weaknesses/MASVS-RESILIENCE/MASWE-0051.md index c92100c..d435e9e 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0051.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0051.md @@ -36,6 +36,6 @@ Obfuscation does not prevent reverse engineering, but it raises its cost. Identi ## Mitigations - **Enable Obfuscation for Release Builds**: Apply the platform's minification and obfuscation tooling or established commercial obfuscators to all release builds. -- **Harden Security-Relevant Code**: Apply stronger transformations (opaque predicates, instruction substitution, control-flow obfuscation, method inlining) to the code implementing security checks and proprietary logic. +- **Harden Security-Relevant Code**: Apply stronger transformations (opaque predicates, instruction substitution, control-flow obfuscation, method inlining) to the security-relevant code. - **Assess Obfuscation Effectiveness**: Regularly attempt to reverse engineer the release build with state-of-the-art decompilers and deobfuscators to validate that the protection meets its goal. - **Combine with Runtime Protections**: Pair obfuscation with runtime integrity and anti-instrumentation checks (see @MASWE-0053, @MASWE-0061, @MASWE-0064), since obfuscation alone only delays attackers. From e443d40b4d891afd9ef3c2d5b0e43e79f9d29600 Mon Sep 17 00:00:00 2001 From: Jeroen Beckers Date: Mon, 27 Jul 2026 15:27:31 +0200 Subject: [PATCH 46/70] Apply suggestion from @jacobocasado Co-authored-by: Jaco <43786394+jacobocasado@users.noreply.github.com> --- weaknesses/MASVS-RESILIENCE/MASWE-0051.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0051.md b/weaknesses/MASVS-RESILIENCE/MASWE-0051.md index d435e9e..ca330c5 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0051.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0051.md @@ -38,4 +38,4 @@ Obfuscation does not prevent reverse engineering, but it raises its cost. Identi - **Enable Obfuscation for Release Builds**: Apply the platform's minification and obfuscation tooling or established commercial obfuscators to all release builds. - **Harden Security-Relevant Code**: Apply stronger transformations (opaque predicates, instruction substitution, control-flow obfuscation, method inlining) to the security-relevant code. - **Assess Obfuscation Effectiveness**: Regularly attempt to reverse engineer the release build with state-of-the-art decompilers and deobfuscators to validate that the protection meets its goal. -- **Combine with Runtime Protections**: Pair obfuscation with runtime integrity and anti-instrumentation checks (see @MASWE-0053, @MASWE-0061, @MASWE-0064), since obfuscation alone only delays attackers. +- **Combine with Runtime Protections**: Pair obfuscation with runtime integrity and anti-instrumentation checks (see the mitigations in @MASWE-0053, @MASWE-0061, @MASWE-0064), since obfuscation alone only delays attackers. From a477f27cc22308aba3a7025508e3114023acab6d Mon Sep 17 00:00:00 2001 From: Jeroen Beckers Date: Mon, 27 Jul 2026 15:36:39 +0200 Subject: [PATCH 47/70] Apply suggestions from code review Co-authored-by: Jaco <43786394+jacobocasado@users.noreply.github.com> --- weaknesses/MASVS-RESILIENCE/MASWE-0049.md | 18 ++++++++++-------- weaknesses/MASVS-RESILIENCE/MASWE-0050.md | 5 +++-- 2 files changed, 13 insertions(+), 10 deletions(-) diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0049.md b/weaknesses/MASVS-RESILIENCE/MASWE-0049.md index ff4a091..05959fc 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0049.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0049.md @@ -1,8 +1,8 @@ --- -title: Missing Device Secure Lock Verification Implementation +title: Sensitive Functionality Enabled Without a Secure Device Lock id: MASWE-0049 alias: secured-device-detection-not-implemented -requirement: "The app verifies that the device has a secure lock screen configured before enabling sensitive functionality." +requirement: "The app verifies that the device has a secure lock screen configured before enabling or performing sensitive functionality." platform: [android, ios] profiles: [L2] threat: MAS-THREAT-0049 @@ -13,6 +13,7 @@ mappings: maswe-beta: [MASWE-0008] refs: - https://developer.apple.com/documentation/localauthentication/logging_a_user_into_your_app_with_face_id_or_touch_id +- https://developer.apple.com/documentation/localauthentication/lacontext/canevaluatepolicy(_:error:) - https://developer.android.com/reference/android/app/KeyguardManager#isDeviceSecure() - https://developer.android.com/reference/android/hardware/biometrics/BiometricManager#canAuthenticate(int) status: new @@ -20,14 +21,17 @@ status: new ## Overview -This weakness occurs when an app enables sensitive functionality without verifying that the device has a secure lock screen (passcode, PIN, pattern, or biometric) configured. +This weakness occurs when an app enables sensitive functionality without verifying that the device has a secure lock screen (passcode, PIN, pattern, or biometric) configured and without enforcing authentication using such lock screen mechanism. -Many of the platform's data-protection guarantees assume a device credential exists: on iOS, file encryption classes tied to the passcode only protect data if a passcode is set, and on Android, keystore protections such as unlocked-device requirements are meaningless on a device with no lock. If the app does not check for a secure device lock, it may expose sensitive data on devices where anyone who picks them up has full access. +Many of the platform's data-protection mechanisms assume a device credential exists: on iOS, file encryption classes tied to the passcode only protect data if a passcode is set, and on Android, keystore protections such as unlocked-device requirements are meaningless on a device with no lock. + +If the app does not check for a secure device lock before performing sensitive functionality, it might expose sensitive data or enable sensitive actions for anyone that unlocks the device. ## Modes of Introduction -- **No Secure-Lock Check**: Enabling sensitive features without verifying the device lock state, e.g. via `KeyguardManager.isDeviceSecure()` on Android or `LAContext.canEvaluatePolicy(_:error:)` on iOS. -- **Data Protection Not Tied to the Passcode**: Storing sensitive items on iOS without passcode-dependent protection classes (e.g. `kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly`), so the data remains available even when no passcode is set. +**No Secure-Lock Check**: Enabling sensitive features without verifying the device lock state, e.g., [`KeyguardManager.isDeviceSecure()`](https://developer.android.com/reference/android/app/KeyguardManager#isDeviceSecure()) on Android or [`LAContext.canEvaluatePolicy(_:error:)`](https://developer.apple.com/documentation/localauthentication/lacontext/canevaluatepolicy%28_%3Aerror%3A%29) on iOS. +- **Data Protection Not Tied to the Passcode**: Storing sensitive items on iOS without passcode-dependent protection classes (e.g. [`kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly`](https://developer.apple.com/documentation/security/ksecattraccessiblewhenpasscodesetthisdeviceonly)), so the data remains available even when no passcode is set. +- **Stale Device-Lock Assumption**: Checking the device-lock configuration only during onboarding or feature enrollment and continuing to enable the functionality after the device credential has been removed or the required authentication policy is no longer available. ## Impact @@ -37,5 +41,3 @@ Many of the platform's data-protection guarantees assume a device credential exi ## Mitigations - **Verify the Device Lock State**: Check that a secure lock screen is configured (e.g. `isDeviceSecure()` on Android, `canEvaluatePolicy` on iOS) before enabling sensitive functionality, and guide users to set one when missing. -- **Bind Data Protection to the Passcode**: On iOS, store sensitive Keychain items with passcode-dependent protection classes such as `kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly`, so data becomes unavailable if the passcode is removed. -- **Degrade Gracefully**: On devices without a secure lock, restrict the most sensitive features or require in-app authentication instead of silently operating unprotected. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0050.md b/weaknesses/MASVS-RESILIENCE/MASWE-0050.md index df72c8c..6135226 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0050.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0050.md @@ -18,14 +18,15 @@ refs: - https://developer.android.com/guide/topics/manifest/application-element - https://developer.android.com/reference/android/webkit/WebView#setWebContentsDebuggingEnabled(boolean) - https://developer.apple.com/documentation/webkit/wkwebview/4111163-isinspectable +- https://developer.apple.com/documentation/bundleresources/entitlements/com.apple.security.cs.debugger status: new --- ## Overview -This weakness occurs when debug mechanisms, such as the platform's debuggable flag or WebView content debugging, remain enabled in production builds. +This weakness occurs when the application has debug mechanisms enabled in production builds, allowing the usage of platform debuggers, or exposes embedded web or JavaScript content to developer inspection tools. -Mobile apps typically include configuration flags and mechanisms that enable debugging. While these are essential during development, leaving them enabled in production makes the app inspectable and manipulable, even on non-rooted or non-jailbroken devices, and may expose sensitive information through verbose logging or developer tools that would otherwise be inaccessible. +Mobile apps typically include configuration flags and mechanisms that enable debugging. While these are essential during development, leaving them enabled in production makes the app inspectable and manipulable. Beyond the application-level debuggable flag, this weakness also covers WebView content debugging, which lets a remote inspector attach to the app's web content (e.g. Android's `WebView.setWebContentsDebuggingEnabled(true)` or iOS's `WKWebView.isInspectable`). Like the debuggable flag, this must be disabled in production builds. From fa18d0706b7bc4d224ed7ead9ee7b979fd0ffbcd Mon Sep 17 00:00:00 2001 From: Jeroen Beckers Date: Mon, 27 Jul 2026 16:26:47 +0200 Subject: [PATCH 48/70] Apply suggestions from code review Applied a bunch of Co-authored-by: Jaco <43786394+jacobocasado@users.noreply.github.com> Co-authored-by: Stefan Co-authored-by: Jeroen Beckers --- weaknesses/MASVS-RESILIENCE/MASWE-0050.md | 10 +++++----- weaknesses/MASVS-RESILIENCE/MASWE-0052.md | 11 ++++------- weaknesses/MASVS-RESILIENCE/MASWE-0053.md | 8 +++----- weaknesses/MASVS-RESILIENCE/MASWE-0054.md | 4 ++-- weaknesses/MASVS-RESILIENCE/MASWE-0055.md | 2 +- 5 files changed, 15 insertions(+), 20 deletions(-) diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0050.md b/weaknesses/MASVS-RESILIENCE/MASWE-0050.md index 6135226..c16db66 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0050.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0050.md @@ -28,20 +28,20 @@ This weakness occurs when the application has debug mechanisms enabled in produc Mobile apps typically include configuration flags and mechanisms that enable debugging. While these are essential during development, leaving them enabled in production makes the app inspectable and manipulable. -Beyond the application-level debuggable flag, this weakness also covers WebView content debugging, which lets a remote inspector attach to the app's web content (e.g. Android's `WebView.setWebContentsDebuggingEnabled(true)` or iOS's `WKWebView.isInspectable`). Like the debuggable flag, this must be disabled in production builds. +Beyond the application-level debuggable flag, this weakness also covers web-content debugging, which lets a remote inspector attach to the app's web content (e.g. Android's [`WebView.setWebContentsDebuggingEnabled(true)`](https://developer.android.com/reference/android/webkit/WebView#setWebContentsDebuggingEnabled(boolean)) or iOS's [`WKWebView.isInspectable`](https://developer.apple.com/documentation/webkit/wkwebview/isinspectable)). Like the debuggable flag, this must be disabled in production builds. ## Modes of Introduction - **Misconfigured Build Settings**: Accidentally leaving the app in a debuggable state through improper selection of build variants, errors in CI/CD configurations, or mistakenly applying debug settings to production environments. -- **WebView Content Debugging Left Enabled**: Leaving WebView content debugging enabled in production (e.g. `setWebContentsDebuggingEnabled(true)` on Android or `isInspectable = true` on iOS). +- **WebView or JavaScript Debugging Enabled**: Leaving WebView content debugging enabled in production (e.g. `setWebContentsDebuggingEnabled(true)` on Android or `isInspectable = true` on iOS). ## Impact - **Compromise of Sensitive Data**: Attackers can read the app's memory and logs to obtain encryption keys, API keys, user credentials, or tokens that are never written to the app's code or disk, resulting in unauthorized disclosure of secrets and user data. - **Authentication or Authorization Bypass**: Attackers can manipulate the app's execution flow to skip authentication and authorization checks, resulting in unauthorized access to protected functionality. -- **Execution of Unauthorized Code**: Attackers can inject and execute arbitrary code within the app's context, e.g. by injecting reverse engineering tools like Frida, resulting in further exploitation of the app or the device. +- **Facilitated Reverse Engineering and Instrumentation**: Debug access reduces the effort required to observe and manipulate the application's behavior and may facilitate further dynamic analysis or instrumentation. ## Mitigations -- **Disable the Debuggable Flag in Release Builds**: Ensure that the debuggable flag in the app's configuration file is not enabled for production builds, e.g. by using build variants or flavors to separate debug and release configurations so the flag is enabled only for debug builds. -- **Disable WebView Content Debugging in Release Builds**: Do not call `setWebContentsDebuggingEnabled(true)` on Android and keep `WKWebView.isInspectable` set to `false` on iOS in production builds. +- **Disable Application Debugging in Release Builds**: Ensure that the debuggable flag in the app's configuration file is not enabled for production builds. For example, set [`isDebuggable = false` or `debuggable false`](https://developer.android.com/studio/publish/preparing) in Android or ensure that the `get-task-allow` entitlement is absent or set to `false` in iOS applications. +- **Disable WebView and JavaScript Content Debugging in Release Builds**: Ensure that the WebViews and JavaScript contexts in the application are not debuggable. For example, do not call `setWebContentsDebuggingEnabled(true)` on Android and keep `WKWebView.isInspectable` set to `false` on iOS. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0052.md b/weaknesses/MASVS-RESILIENCE/MASWE-0052.md index 0be888a..a2015c6 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0052.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0052.md @@ -19,23 +19,20 @@ status: new This weakness occurs when an app's resources and assets are left in clear, unprotected form, revealing how the app works and aiding reverse engineering. -Beyond code, strings, layouts, configuration files, bundled data, and native binaries all carry information about the app's inner workings. Attackers mining the package can use them to map features, find security-relevant configuration, and identify targets for tampering. Note that obfuscation or encryption applied without integrity validation can itself be tampered with, so resource protection should complement, not replace, integrity checks (see @MASWE-0063). +In addition to application code, various artifacts such as strings, layouts, configuration files and bundled data all contain information about the app's inner workings. Attackers mining the package can use them to map features, find security-relevant configuration, and identify targets for tampering. Note that obfuscation or encryption applied without integrity validation can itself be tampered with, so resource protection should complement, not replace, integrity checks (see @MASWE-0063). ## Modes of Introduction -- **Resources Left in Clear**: Shipping strings, configuration, and other assets unobfuscated and unencrypted in the package. -- **Native Binaries Not Protected**: Shipping native libraries without encryption or packing, exposing their full structure to static analysis. +- **Resources Left in Clear**: Shipping strings, configuration, and other assets unobfuscated and unencrypted in the application package. - **Identifiers Left Meaningful**: Keeping descriptive resource and string identifiers that map directly to features and security controls. -- **Protection Without Integrity Validation**: Obfuscating or encrypting resources without verifying their integrity, leaving the protected resources silently replaceable. ## Impact -- **Bypass of Protection Mechanisms**: Attackers can locate security-relevant configuration and assets and use them to target the app's defenses, resulting in easier circumvention of its protections. +- **Bypass of Protection Mechanisms**: Attackers can locate security-relevant configuration and assets and use cross-references to target the app's security-relevant code locations, resulting in easier circumvention of its protections. - **Compromise of Sensitive Data**: Attackers can extract proprietary content and internal information from clear resources, resulting in intellectual property exposure. ## Mitigations -- **Obfuscate or Encrypt Sensitive Resources**: Protect strings, configuration, and assets that reveal security-relevant behavior, decrypting them only when needed at runtime. -- **Pack or Encrypt Native Binaries**: Apply packing or encryption to native libraries containing sensitive logic. +- **Obfuscate Sensitive Resources**: Obfuscate strings, configuration, and assets that reveal security-relevant behavior. - **Obfuscate Resource Identifiers**: Replace meaningful resource and string identifiers with non-descriptive ones in release builds. - **Validate Resource Integrity**: Combine resource protection with integrity verification (see @MASWE-0063) so protected resources cannot simply be replaced. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0053.md b/weaknesses/MASVS-RESILIENCE/MASWE-0053.md index 7ca2f32..28d66f6 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0053.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0053.md @@ -17,20 +17,18 @@ status: new ## Overview -This weakness occurs when an app relies on obfuscation that automated deobfuscation and static-analysis tooling can undo, because no techniques protect the obfuscation itself. +This weakness occurs when an app relies on obfuscation techniques that can be reversed (e.g., by automated deobfuscation and static-analysis), because no techniques protect the obfuscation itself. -Obfuscation alone is a moving target: publicly available deobfuscators, decompilers, and scripted analyses can strip common transformations automatically. Anti-deobfuscation techniques, such as anti-decompilation constructs, control-flow shapes that defeat common deobfuscators, and self-checks that detect tampering with obfuscated code, raise the cost of reversing the obfuscation. This weakness complements @MASWE-0051 by protecting the obfuscation itself. +Publicly available deobfuscators, decompilers, and scripted analyses can strip common transformations automatically. Anti-deobfuscation techniques, such as anti-decompilation constructs and control-flow shapes that defeat common deobfuscators, raise the cost of reversing the obfuscation. This weakness complements @MASWE-0051 by focusing on cases where improperly implemented or insufficiently protected obfuscation can be deobfuscated. ## Modes of Introduction - **Obfuscation Without Hardening**: Applying standard obfuscation whose transformations are automatically reversible by publicly available tooling. -- **Deobfuscator-Friendly Control Flow**: Using control-flow patterns that common deobfuscators normalize without difficulty. -- **No Tamper Detection for Obfuscated Code**: Not detecting when obfuscated code has been modified, unpacked, or re-written by analysis tooling. - **Effectiveness Never Assessed**: Never attempting deobfuscation with current tooling to measure how long the protection actually holds. ## Impact -- **Bypass of Protection Mechanisms**: Attackers can recover near-original code and then locate and defeat the app's client-side defenses, resulting in the circumvention of protections the obfuscation was meant to shield. +- **Bypass of Obfuscation Mechanisms**: Attackers can defeat obfuscation mechanisms and as a result, recover a understandable representation of the code that the obfuscation mechanisms were intended to protect, facilitating reverse engineering. - **Compromise of Sensitive Data**: Attackers can recover proprietary algorithms and embedded secrets despite the obfuscation, resulting in intellectual property exposure. ## Mitigations diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0054.md b/weaknesses/MASVS-RESILIENCE/MASWE-0054.md index 72cff43..1dff5b8 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0054.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0054.md @@ -22,14 +22,14 @@ status: new This weakness occurs when an app ships to production containing developer debug artifacts, such as verbose logging, testing utilities, debugging symbols, or leftover debug and test code. -Such artifacts help adversaries understand the app's behavior and internals, may include sensitive implementation details, and, most critically, may include backdoors, such as hidden switches or an insecure trust manager, that can disable security controls like TLS certificate validation. Note the distinction from @MASWE-0006: that weakness covers developer leftover artifacts that leak confidentiality (staging URLs, developer identities, source files), while this one covers debug artifacts that weaken the app's resilience. +Such artifacts help adversaries understand the app's behavior and internals, may include sensitive implementation details, and, most critically, may include backdoors, such as hidden switches enabling debug menus or an insecure trust manager, that can disable security controls like TLS certificate validation. Note the distinction from @MASWE-0006: that weakness covers developer leftover artifacts that leak confidentiality (staging URLs, developer identities, source files), while this one covers debug artifacts that weaken the app's resilience. ## Modes of Introduction - **Verbose Logging and Debug Flows**: Leaving verbose or debug-level logging and diagnostic code paths active in production builds. - **Testing Utilities Enabled**: Shipping with development-time utilities enabled, such as StrictMode on Android. - **Debugging Symbols Not Stripped**: Releasing binaries with debugging symbols that map the code for reverse engineers. -- **Backdoors and Hidden Switches**: Leaving debug or test code that can disable security controls, e.g. an insecure trust manager or a hidden configuration flag that turns off TLS verification. +- **Backdoors or Hidden Switches and Debug Menus**: Leaving debug or test code that can disable security controls, e.g. an insecure trust manager or a hidden configuration flag that turns off TLS verification. ## Impact diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0055.md b/weaknesses/MASVS-RESILIENCE/MASWE-0055.md index 78f3831..27e224d 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0055.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0055.md @@ -29,7 +29,7 @@ Even when the connection uses HTTPS, an attacker who controls the device can byp ## Impact - **Compromise of System Integrity and Business Operations**: Attackers can map the app's API and craft or tamper with requests, resulting in fraud, scraping, and abuse of backend services at the app owner's expense. -- **Bypass of Protection Mechanisms**: Attackers can modify payloads that carry security-relevant state, resulting in the circumvention of client-reported controls and business logic. +- **Bypass of Protection Mechanisms**: Attackers can easily modify payloads that carry security-relevant state, without having to reverse-engineer the application to first circumvent the additional encryption. ## Mitigations From cc320ca6fa4f0537d40112a771da5a13d2b3dc0d Mon Sep 17 00:00:00 2001 From: Jeroen Beckers Date: Mon, 27 Jul 2026 17:10:26 +0200 Subject: [PATCH 49/70] Apply suggestions from code review Co-authored-by: Stefan --- weaknesses/MASVS-RESILIENCE/MASWE-0056.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0056.md b/weaknesses/MASVS-RESILIENCE/MASWE-0056.md index 1a661df..fe9eff5 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0056.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0056.md @@ -2,7 +2,7 @@ title: Root/Jailbreak Detection Not Implemented id: MASWE-0056 alias: root-jailbreak-detection -requirement: "The app terminates if a rooted/jailbroken device is detected." +requirement: "The app detects if it runs on a rooted/jailbroken device and reacts appropriately." platform: [android, ios] profiles: [R] threat: MAS-THREAT-0056 From e2d846dfd303e25a3a40fabf85d3955695736ed0 Mon Sep 17 00:00:00 2001 From: Sven Date: Mon, 27 Jul 2026 20:27:40 +0200 Subject: [PATCH 50/70] Apply suggestion from @serek8 Co-authored-by: Jan Seredynski --- weaknesses/MASVS-AUTH/MASWE-0021.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/weaknesses/MASVS-AUTH/MASWE-0021.md b/weaknesses/MASVS-AUTH/MASWE-0021.md index 575e36b..8de98d0 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0021.md +++ b/weaknesses/MASVS-AUTH/MASWE-0021.md @@ -27,7 +27,7 @@ status: new This weakness occurs when local authentication, such as biometrics, device credentials, or a custom app PIN, can be bypassed because it is implemented as an event-bound check rather than being cryptographically tied to a protected resource. -Local authentication is only as strong as what it unlocks. When the app merely reacts to a "success" callback, an attacker who controls the app's execution can invoke the protected logic directly, without ever passing the check. To be effective, local authentication must gate access to a key in the platform keystore, using a `CryptoObject` on Android or Keychain access control on iOS, so that the protected operation cannot proceed without an authentication that the OS and hardware enforce. For connected apps, authentication and authorization decisions that are enforced only locally, rather than on the server side, are similarly bypassable by tampering with the client. +Local authentication is only as strong as what it unlocks. When the app merely reacts to a "success" callback, an attacker who controls the app's execution can invoke the protected logic directly, without ever passing the check. To be effective, local authentication must require a cryptographic operation, such as decrypting a secret or signing a payload, using a key locked inside secure hardware like a Trusted Execution Environment or Secure Enclave. Because the hardware itself enforces user authentication before executing the operation, an attacker spoofing a successful callback cannot produce the required cryptographic proof or unencrypted data. For connected apps, authentication and authorization decisions that are enforced only locally, rather than on the server side, are similarly bypassable by tampering with the client. ## Modes of Introduction From 64828e28773b74f58bde232d906c34848ff3d240 Mon Sep 17 00:00:00 2001 From: Sven Date: Mon, 27 Jul 2026 20:30:13 +0200 Subject: [PATCH 51/70] Apply suggestion from @serek8 Co-authored-by: Jan Seredynski --- weaknesses/MASVS-AUTH/MASWE-0021.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/weaknesses/MASVS-AUTH/MASWE-0021.md b/weaknesses/MASVS-AUTH/MASWE-0021.md index 8de98d0..a4f8e95 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0021.md +++ b/weaknesses/MASVS-AUTH/MASWE-0021.md @@ -44,7 +44,7 @@ Local authentication is only as strong as what it unlocks. When the app merely r ## Mitigations -- **Bind Authentication to Keystore Keys**: Gate protected operations on keys stored in the platform keystore that require user authentication, using `CryptoObject` on Android and Keychain access control (e.g. `.biometryCurrentSet`, `.userPresence`) on iOS, so success cannot be simulated in software. +- **Bind Authentication to Keystore Keys**: Protect sensitive actions by requiring a cryptographic operation (such as decryption or signing) using keys stored in the platform keystore. Use mechanisms like `CryptoObject` on Android or Keychain access control on iOS (such as `.biometryCurrentSet`) so attackers cannot bypass authentication by hooking software callbacks. - **Use Strict Access Control Flags**: Choose Keychain and keystore parameters that enforce the intended factor and invalidate on enrollment changes (see @MASWE-0023), avoiding weak flags and long authentication validity windows. - **Enforce Authentication Server-Side**: For connected apps, gate server resources on server-verified evidence of authentication (e.g. a signed challenge produced with an authentication-bound key), never on a client-side boolean. - **Bind Custom Credentials to the Keystore**: Implement custom PINs or passwords via keystore- or Keychain-backed mechanisms (e.g. `applicationPassword`) instead of comparing values in app code. From 32ce49e5f39f53f86a30a4b077ca2e148c882cd6 Mon Sep 17 00:00:00 2001 From: Sven Date: Mon, 27 Jul 2026 21:15:27 +0200 Subject: [PATCH 52/70] Apply suggestion from @jacobocasado Co-authored-by: Jaco <43786394+jacobocasado@users.noreply.github.com> --- weaknesses/MASVS-PLATFORM/MASWE-0028.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0028.md b/weaknesses/MASVS-PLATFORM/MASWE-0028.md index d902db8..6b85c9c 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0028.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0028.md @@ -2,7 +2,7 @@ title: Unnecessary Exposure of Sensitive Data via the User Interface id: MASWE-0028 alias: data-leak-ui -requirement: "The app does not unnecessarily expose sensitive data through the app user interface." +requirement: "The app does not unnecessarily expose sensitive data through its user interface." platform: [android, ios] profiles: [L2] threat: MAS-THREAT-0028 From 8cb0cc0b2297907f1a07253f2624af69c0dd5680 Mon Sep 17 00:00:00 2001 From: Sven Date: Mon, 27 Jul 2026 21:16:10 +0200 Subject: [PATCH 53/70] Apply suggestion from @jacobocasado Co-authored-by: Jaco <43786394+jacobocasado@users.noreply.github.com> --- weaknesses/MASVS-PLATFORM/MASWE-0028.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0028.md b/weaknesses/MASVS-PLATFORM/MASWE-0028.md index 6b85c9c..459b100 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0028.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0028.md @@ -20,7 +20,7 @@ status: new ## Overview -This weakness occurs when an app exposes sensitive data beyond what is required for the user's current task, or exposes required data without protections proportionate to its sensitivity, through UI components or UI-mediated platform services, such as the clipboard or autocompletion features. +This weakness occurs when an app exposes sensitive data beyond what is required for the user's current task, or exposes required data without protections proportionate to its sensitivity through its user interface. Typical exposure paths include displaying secrets or complete identifiers in cleartext when masking or a partial representation would suffice, using unprotected input fields for passwords or PINs, permitting unnecessary copying to the system clipboard, and enabling keyboard or IME (Input Method Editor) features that may retain or later suggest sensitive input. From 50a69fa36fa8d0edcb6fef448c9c42c32ef45785 Mon Sep 17 00:00:00 2001 From: Sven Date: Mon, 27 Jul 2026 21:16:34 +0200 Subject: [PATCH 54/70] Apply suggestion from @jacobocasado Co-authored-by: Jaco <43786394+jacobocasado@users.noreply.github.com> --- weaknesses/MASVS-PLATFORM/MASWE-0028.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0028.md b/weaknesses/MASVS-PLATFORM/MASWE-0028.md index 459b100..a4ce8ad 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0028.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0028.md @@ -22,7 +22,7 @@ status: new This weakness occurs when an app exposes sensitive data beyond what is required for the user's current task, or exposes required data without protections proportionate to its sensitivity through its user interface. -Typical exposure paths include displaying secrets or complete identifiers in cleartext when masking or a partial representation would suffice, using unprotected input fields for passwords or PINs, permitting unnecessary copying to the system clipboard, and enabling keyboard or IME (Input Method Editor) features that may retain or later suggest sensitive input. +The typical exposure path involves displaying secrets or sensitive information in cleartext when masking or a partial representation would suffice, (e.g., using unprotected input fields for passwords or PINs). ## Modes of Introduction From c4830e0161ede80ebcef40d63d7059b66427a2b1 Mon Sep 17 00:00:00 2001 From: Sven Date: Mon, 27 Jul 2026 21:24:07 +0200 Subject: [PATCH 55/70] Apply suggestions from code review Co-authored-by: Jaco <43786394+jacobocasado@users.noreply.github.com> --- weaknesses/MASVS-PLATFORM/MASWE-0028.md | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0028.md b/weaknesses/MASVS-PLATFORM/MASWE-0028.md index a4ce8ad..48d69f2 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0028.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0028.md @@ -26,19 +26,15 @@ The typical exposure path involves displaying secrets or sensitive information i ## Modes of Introduction -- **Non-Secure Text Entry**: Building password or PIN fields without secure text entry behavior (e.g. [`isSecureTextEntry`](https://developer.apple.com/documentation/uikit/uitextinputtraits/issecuretextentry) on iOS, [`textPassword`](https://developer.android.com/develop/ui/views/touch-and-input/keyboard-input/style#Type) input types on Android), so the input is shown in cleartext. -- **Unsafe Clipboard Exposure**: Allowing sensitive values to be copied when copying the value is unnecessary, or placing them on the system clipboard automatically when it's not needed. -- **Keyboard Caching and Auto-Correct**: Using input types that let the keyboard cache or auto-correct dictionaries learn sensitive input. +- **Non-Secure Text Entry**: Building password or PIN fields without inserting them in platform-specific fields that mask sensitive data (e.g. [`isSecureTextEntry`](https://developer.apple.com/documentation/uikit/uitextinputtraits/issecuretextentry) on iOS, [`textPassword`](https://developer.android.com/develop/ui/views/touch-and-input/keyboard-input/style#Type) input types on Android), so the input is shown in cleartext. - **Unmasked Sensitive Values**: Displaying full values (e.g. complete card numbers or personal identifiers) where a masked or partial representation would suffice. ## Impact -- **Compromise of Sensitive Data**: Sensitive information may be observed from the screen, transferred through the clipboard, retained by an input method, or subsequently disclosed to another user. +- **Compromise of Sensitive Data**: Sensitive information may be observed from the screen and captured by other user. - **Authentication or Authorization Bypass**: Attackers can capture credentials, PINs, or one-time codes exposed through the UI, resulting in unauthorized access to the user's accounts. ## Mitigations - **Use Secure Text Entry for Secrets**: Configure passwords, PINs, and other secrets using the platform's secure text-entry controls, such as [`textPassword` on Android Views](https://developer.android.com/develop/ui/views/touch-and-input/keyboard-input/style), [`SecureTextField` in Jetpack Compose](https://developer.android.com/develop/ui/compose/text/user-input), or [`isSecureTextEntry` on iOS](https://developer.apple.com/documentation/uikit/uitextinputtraits/issecuretextentry). Do not rely solely on custom visual masking when a platform-provided secure text-entry control is available. -- **Restrict Clipboard Exposure**: Prevent copying sensitive values when it is not required for the intended functionality. When copying is a legitimate feature, follow the platform's [secure clipboard handling guidance on Android](https://developer.android.com/privacy-and-security/risks/secure-clipboard-handling) and mark the content using [`ClipDescription.EXTRA_IS_SENSITIVE`](https://developer.android.com/reference/android/content/ClipDescription#EXTRA_IS_SENSITIVE) to obscure clipboard previews. On iOS, use pasteboard options such as [`localOnly`](https://developer.apple.com/documentation/uikit/uipasteboard/optionskey/localonly) and [`expirationDate`](https://developer.apple.com/documentation/uikit/uipasteboard/optionskey/expirationdate) to limit cross-device propagation and content lifetime. These mechanisms reduce exposure but do not provide access control over clipboard contents. -- **Limit Keyboard and IME Processing**: Disable unnecessary autocorrection, spell checking, suggestions, inline predictions, and personalized learning for the data that is considered sensitive. On Android, signal that dictionary-based suggestions are unnecessary using [`TYPE_TEXT_FLAG_NO_SUGGESTIONS`](https://developer.android.com/reference/android/text/InputType#TYPE_TEXT_FLAG_NO_SUGGESTIONS) and request that the IME does not retain personalized data using [`IME_FLAG_NO_PERSONALIZED_LEARNING`](https://developer.android.com/reference/android/view/inputmethod/EditorInfo#IME_FLAG_NO_PERSONALIZED_LEARNING). Treat the no-learning flag as a defense-in-depth measure rather than a guarantee because an IME may ignore it. On iOS, configure [`autocorrectionType`](https://developer.apple.com/documentation/uikit/uitextinputtraits/autocorrectiontype), [`spellCheckingType`](https://developer.apple.com/documentation/uikit/uitextinputtraits/spellcheckingtype), and [`inlinePredictionType`](https://developer.apple.com/documentation/uikit/uitextinputtraits/inlinepredictiontype) as appropriate for the sensitivity of the input. - **Minimize Visual Disclosure**: Display only the portion of a sensitive value required for the user's current task. When revealing the full value is necessary, reveal it only after an explicit user action (see @MASWE-0017) and for a limited duration. From 18874678feb750313d018f2357e9ecaf33bfccf4 Mon Sep 17 00:00:00 2001 From: Jeroen Beckers Date: Mon, 27 Jul 2026 21:48:22 +0200 Subject: [PATCH 56/70] Apply suggestions from code review Co-authored-by: Jaco <43786394+jacobocasado@users.noreply.github.com> --- weaknesses/MASVS-CODE/MASWE-0048.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/weaknesses/MASVS-CODE/MASWE-0048.md b/weaknesses/MASVS-CODE/MASWE-0048.md index dd30fb4..f2716eb 100644 --- a/weaknesses/MASVS-CODE/MASWE-0048.md +++ b/weaknesses/MASVS-CODE/MASWE-0048.md @@ -32,7 +32,9 @@ status: new This weakness occurs when data originating outside the app's trust boundary reaches a sensitive sink without being validated, sanitized, or safely parsed. -Untrusted data is any data the app did not create itself, regardless of how it arrives: network responses (even over TLS), data restored from backups, external interfaces such as Bluetooth, NFC, and USB, local files (including document pickers and archives), user interface input (text fields, QR codes, URLs, the clipboard), and IPC (received intents, broadcasts, content URIs, or deep links). When such data reaches a dangerous sink unchecked, it can cause SQL injection, path traversal (including zip path traversal), XML external entity (XXE) injection, insecure object deserialization, output-encoding flaws, or memory corruption in native parsers. +Untrusted data is any data the app did not create itself, regardless of how it arrives: network responses (even over TLS), data restored from backups, external interfaces such as Bluetooth, NFC, and USB, local files (including document pickers and archives), user interface input (text fields, QR codes, URLs, the clipboard), and the platform's IPC (e.g., for Android, received intents, broadcasts, content URIs, or deep links). + +When the untrusted data reaches a dangerous sink that has not been validated or sanitized, it cause unintended behavior of the application by exploiting vulnerabilities like SQL injection, path traversal (including variants like ZIP path traversal), XML external entity (XXE) injection, insecure object deserialization, output-encoding flaws, or memory corruption in native parsers, or misleading presentation of security-relevant information. ## Modes of Introduction @@ -42,12 +44,14 @@ Untrusted data is any data the app did not create itself, regardless of how it a - **Insecure Parsing**: Parsing untrusted XML with external entities enabled, or emitting untrusted data without proper output encoding. - **Insecure Deserialization**: Deserializing untrusted data into rich object types (e.g. `Serializable`, `Parcelable`, `NSCoding`, XML/JSON object mappers) without restricting the allowed types. - **Weakly Validated URI Handling**: Relying on URI parsing classes that apply little to no validation of untrusted input when making security decisions. +- **Unsafe Presentation of Untrusted Data**: Displaying untrusted data in notifications, warnings, confirmation dialogs, or other security-sensitive interfaces without constraining its length or formatting. ## Impact - **Compromise of Sensitive Data**: Attackers can extract or overwrite private files and database contents through path traversal, SQL injection, or XXE, resulting in unauthorized disclosure or modification of user and app data. - **Execution of Unauthorized Code**: Attackers can exploit insecure deserialization or memory corruption in parsers, resulting in attacker-controlled code running in the app's context. - **Authentication or Authorization Bypass**: Attackers can manipulate queries or logic through injected input, resulting in access to data or functionality beyond what the caller is authorized for. +- **Application Content Spoofing**: Attackers can obscure, alter, or impersonate trusted application content in interfaces or notifications, resulting in users approving unintended actions or ignoring legitimate security alerts. ## Mitigations @@ -56,3 +60,4 @@ Untrusted data is any data the app did not create itself, regardless of how it a - **Canonicalize and Contain Paths**: Canonicalize externally supplied file names and paths and verify they resolve inside the intended directory before any file operation, including when extracting archives. - **Harden Parsers**: Disable external entity resolution for XML, apply correct output encoding for the destination context, and prefer hardened platform parsers. - **Deserialize Safely**: Avoid deserializing untrusted data into rich object graphs; prefer simple data formats and safe APIs with explicit type allow-lists. +- **Distinguish Untrusted Data From Application-Generated Content**: Distinguish externally-provided values from trusted application content, especially in notifications and security-sensitive interfaces. Apply context-appropriate length, line, and formatting restrictions so untrusted data cannot obscure or alter the apparent meaning of the information presented. From 934e0112d556fccbddc8d520ee767eb82a974a6b Mon Sep 17 00:00:00 2001 From: Jeroen Date: Mon, 27 Jul 2026 22:01:30 +0200 Subject: [PATCH 57/70] Make requirement wording consistent --- weaknesses/MASVS-CODE/MASWE-0040.md | 2 +- weaknesses/MASVS-CODE/MASWE-0042.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/weaknesses/MASVS-CODE/MASWE-0040.md b/weaknesses/MASVS-CODE/MASWE-0040.md index d1d5f28..406b914 100644 --- a/weaknesses/MASVS-CODE/MASWE-0040.md +++ b/weaknesses/MASVS-CODE/MASWE-0040.md @@ -2,7 +2,7 @@ title: Enforced Updating Not Implemented id: MASWE-0040 alias: enforced-updating -requirement: "The app terminates if an outdated app version is detected." +requirement: "The app detects if it must be updated and reacts appropriately." platform: [android, ios] profiles: [L2] threat: MAS-THREAT-0040 diff --git a/weaknesses/MASVS-CODE/MASWE-0042.md b/weaknesses/MASVS-CODE/MASWE-0042.md index c1d032a..d7b31ec 100644 --- a/weaknesses/MASVS-CODE/MASWE-0042.md +++ b/weaknesses/MASVS-CODE/MASWE-0042.md @@ -2,7 +2,7 @@ title: Running on a Recent Platform Version Not Ensured id: MASWE-0042 alias: run-on-recent-platform-version -requirement: "The app terminates if an unsupported OS version is detected." +requirement: "The app detects if it is running on an unsupported OS version and reacts appropriately." platform: [android, ios] profiles: [L2] threat: MAS-THREAT-0042 From 373e02aecf55830bf25149bbab3b738d9e1a60ee Mon Sep 17 00:00:00 2001 From: Jeroen Beckers Date: Mon, 27 Jul 2026 22:03:34 +0200 Subject: [PATCH 58/70] Apply suggestions from code review Co-authored-by: Stefan --- weaknesses/MASVS-AUTH/MASWE-0024.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/weaknesses/MASVS-AUTH/MASWE-0024.md b/weaknesses/MASVS-AUTH/MASWE-0024.md index 1757a74..17e6830 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0024.md +++ b/weaknesses/MASVS-AUTH/MASWE-0024.md @@ -1,5 +1,5 @@ --- -title: Lack of Auto-fill Support for Authenticators +title: Lack of Auto-fill Support for Credential Providers id: MASWE-0024 alias: autofill-authenticators requirement: "The app enables auto-fill support for authenticators." @@ -31,8 +31,8 @@ Platforms provide secure flows for supplying credentials, one-time codes, and pa - **No Auto-Fill Support in Credential Fields**: Building login fields that are not recognized by or are incompatible with the platform's auto-fill framework and password managers. - **No One-Time-Code Auto-Fill**: Requiring users to manually read and copy one-time codes (e.g. from SMS) instead of supporting the platform's code auto-fill. -- **Missing Website Association**: Not associating the app with its domain, preventing secure credential sharing between the app and its website counterpart. -- **Embedded Third-Party Login Instead of System Flows**: Handling third-party authentication in embedded views instead of system-provided authentication sessions (e.g. `ASWebAuthenticationSession`). +- **Missing Website Association**: Not associating the app with its domain, preventing frictionless secure credential sharing between the app and its website counterpart. +- **Embedded Custom Login Instead of System Flows**: Handling custom authentication, such as using third-party logins in embedded views, instead of system-provided authentication sessions (e.g. `ASWebAuthenticationSession`). - **No Support for Passwordless Authentication**: Not offering passkeys or other multi-device FIDO/WebAuthn credentials where they could replace passwords. ## Impact @@ -46,4 +46,4 @@ Platforms provide secure flows for supplying credentials, one-time codes, and pa - **Support One-Time-Code Auto-Fill**: Use the platform mechanisms that deliver one-time codes directly into the app, removing the need for manual copying. - **Associate the App with Its Domain**: Configure website association (e.g. iOS Password AutoFill with associated domains, shared web credentials) so credentials flow securely between the app and its website. - **Use System Authentication Sessions for Third-Party Logins**: Authenticate against third-party services with system flows such as `ASWebAuthenticationSession` instead of embedded views. -- **Adopt Passkeys**: Offer passkeys or other WebAuthn-based passwordless authentication to remove shared secrets from the login flow entirely. +- **Support Passkeys**: Offer passkeys or other WebAuthn-based passwordless authentication to remove shared secrets from the login flow entirely. From 42285d0415fb25ba6829a52bf24a2002671d081b Mon Sep 17 00:00:00 2001 From: Jeroen Beckers Date: Mon, 27 Jul 2026 22:12:45 +0200 Subject: [PATCH 59/70] Apply suggestion from @sgIOlas MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Sergio García <32015541+sgIOlas@users.noreply.github.com> --- weaknesses/MASVS-RESILIENCE/MASWE-0062.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0062.md b/weaknesses/MASVS-RESILIENCE/MASWE-0062.md index 2974906..a90918f 100644 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0062.md +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0062.md @@ -6,7 +6,7 @@ requirement: "The app implements app attestation." platform: [android, ios] profiles: [R] threat: MAS-THREAT-0062 -attacks: [MAS-ATTACK-0040, MAS-ATTACK-0069] +attacks: [MAS-ATTACK-0040, MAS-ATTACK-0068, MAS-ATTACK-0069] mappings: masvs-v1: [MSTG-CODE-1] masvs-v2: [MASVS-RESILIENCE-2] From 26739ba559697bfa1cfd7ab0446928b81a6981bb Mon Sep 17 00:00:00 2001 From: Carlos Holguera Date: Tue, 28 Jul 2026 09:51:57 +0200 Subject: [PATCH 60/70] Apply suggestions from code review Co-authored-by: Carlos Holguera Co-authored-by: Stefan Co-authored-by: Jeroen Beckers Co-authored-by: Jaco <43786394+jacobocasado@users.noreply.github.com> Co-authored-by: Sven --- weaknesses/MASVS-AUTH/MASWE-0019.md | 14 ++++- weaknesses/MASVS-AUTH/MASWE-0020.md | 5 +- weaknesses/MASVS-AUTH/MASWE-0021.md | 6 +- weaknesses/MASVS-AUTH/MASWE-0024.md | 90 ++++++++++++++--------------- weaknesses/MASVS-CODE/MASWE-0040.md | 9 ++- weaknesses/MASVS-CODE/MASWE-0043.md | 10 ++-- weaknesses/MASVS-CODE/MASWE-0044.md | 2 +- weaknesses/MASVS-CODE/MASWE-0046.md | 7 ++- weaknesses/MASVS-CODE/MASWE-0047.md | 2 +- weaknesses/MASVS-CODE/MASWE-0048.md | 12 ++-- 10 files changed, 84 insertions(+), 73 deletions(-) diff --git a/weaknesses/MASVS-AUTH/MASWE-0019.md b/weaknesses/MASVS-AUTH/MASWE-0019.md index d3fd0f7..7620d32 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0019.md +++ b/weaknesses/MASVS-AUTH/MASWE-0019.md @@ -21,7 +21,16 @@ status: new This weakness occurs when critical actions, such as confirming a payment or a high-value transaction, can be approved without a trusted confirmation path that produces cryptographic evidence of what the user actually saw and approved. -For a critical action to be non-repudiable, the user must be shown exactly what they are approving through a trusted, hardware-protected confirmation path, and the app should obtain cryptographic evidence that this specific prompt was confirmed by the user. On Android, this can be achieved with [Android Protected Confirmation](https://developer.android.com/training/articles/security-android-protected-confirmation), which displays the prompt via a Trusted UI and signs the confirmed message with a hardware-backed key. Note that it does not provide a secure information channel, so it must not be used to display sensitive information that wouldn't ordinarily be shown on the device. Equivalent trusted-confirmation paths on other platforms need to be evaluated case by case. +For a critical action to be non-repudiable, the user must be shown exactly what they are approving through a trusted, hardware-protected confirmation path, and the app should obtain cryptographic evidence that this specific prompt was confirmed by the user. + +This can be achieved by displaying a prompt and then signing the confirmed message with an attested hardware-backed key. + +Note that it does not provide a secure information channel, so it must not be used to display sensitive information that wouldn't ordinarily be shown on the device. Equivalent trusted-confirmation paths on other platforms need to be evaluated case by case. + + +!!! Warning + + On Android, [Android Protected Confirmation](https://developer.android.com/training/articles/security-android-protected-confirmation) can display the prompt and sign the confirmed message with a hardware-backed key. However, while the API itself is not deprecated, its interface definition is [deprecated](https://android.googlesource.com/platform/system/security/+/07fec0ff). It is therefore not guaranteed that Android Protected Confirmation works properly on current devices. Beyond the technical aspect, non-repudiation has a legal dimension: a signed, user-confirmed action carries evidentiary value that a plain in-app confirmation does not, which matters when transactions are later disputed. @@ -38,7 +47,6 @@ Beyond the technical aspect, non-repudiation has a legal dimension: a signed, us ## Mitigations -- **Use a Hardware-Protected Confirmation Path**: Confirm critical actions through a Trusted UI mechanism such as Android Protected Confirmation, where the prompt is displayed and confirmed outside the reach of the main OS. - **Bind Cryptographic Evidence to the Action**: Have the confirmation produce a hardware-backed signature over the exact message shown to the user, verify it server-side, and retain it as evidence of the approval. - **Do Not Display Secrets in the Prompt**: Keep sensitive information out of the trusted confirmation message; it guarantees integrity of the confirmation, not confidentiality of its contents. -- **Use the Strongest Available Alternative**: Where no trusted-UI mechanism exists, bind transaction approval to a user-authenticated, hardware-backed signing key (e.g. biometric-bound transaction signing) as the closest available equivalent. +- **Use the Strongest Available Alternative**: Where no trusted-UI mechanism exists, bind transaction approval to a user-authenticated, hardware-backed signing key (e.g. biometric-bound transaction signing) as the closest available equivalent. Verify the key attestation certificate of the signing key on the server-side. diff --git a/weaknesses/MASVS-AUTH/MASWE-0020.md b/weaknesses/MASVS-AUTH/MASWE-0020.md index aedd867..824e9df 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0020.md +++ b/weaknesses/MASVS-AUTH/MASWE-0020.md @@ -34,7 +34,7 @@ status: new This weakness occurs when app components that expose functionality or data do not enforce proper authentication or authorization on their callers. -It covers any component reachable by other apps or processes without adequate access control, including services, broadcast receivers, activities, and content providers, as well as local web services or open ports exposed by the app, which are also considered app components. It also covers the handling of authentication material on such surfaces, for example authentication tokens accepted without validation or authentication flows handled insecurely inside WebViews. +It covers any component reachable by other apps or processes without adequate access control, including services, broadcast receivers, activities, and content providers, as well as local web services or open ports exposed by the app. It also covers the handling of authentication material on such surfaces, for example authentication tokens accepted without validation or authentication flows handled insecurely inside WebViews. ## Modes of Introduction @@ -44,7 +44,8 @@ It covers any component reachable by other apps or processes without adequate ac - **Over-Broad Data Grants**: Using sticky broadcasts, over-broad or persistable URI permission grants, or persistent data sharing where one-time, scoped sharing would suffice. - **Unprotected Local Network Services**: Binding a local web service or open port that accepts connections without authentication. - **Authentication Material Not Validated**: Accepting authentication tokens without proper validation (e.g. missing signature or claim checks, no PKCE in OAuth flows) or handling authentication inside WebViews instead of secure system flows. - +- **Missing Authentication or Authorization on Deep Links**: App-defined URI scheme, Android App Link, or iOS Universal Link triggers a sensitive action (e.g., password reset, fund transfer, account linking) without verifying that the request came from an authenticated or authorized source. + ## Impact - **Compromise of Sensitive Data**: Attackers can query unprotected content providers or receive broadcast data, resulting in unauthorized disclosure of user or app data to other apps on the device. diff --git a/weaknesses/MASVS-AUTH/MASWE-0021.md b/weaknesses/MASVS-AUTH/MASWE-0021.md index a4f8e95..cee754b 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0021.md +++ b/weaknesses/MASVS-AUTH/MASWE-0021.md @@ -35,7 +35,8 @@ Local authentication is only as strong as what it unlocks. When the app merely r - **Weak Keychain Access Control Flags**: Protecting Keychain items with flags that do not enforce the intended factor (e.g. `kSecAccessControlTouchIDAny` without additional constraints) or storing "protected" data retrievable without authentication. - **Insecure Device-Credential Fallback**: Implementing Confirm Credentials or similar flows with long authentication validity durations or without binding them to keystore keys. - **Local-Only Enforcement**: Enforcing authentication or authorization decisions solely in client code for apps that have a backend, instead of validating them server-side. -- **Custom Credentials Not Keystore-Bound**: Implementing a custom app PIN or password as a plain comparison in code instead of binding it to the platform keystore (e.g. via the Keychain's `applicationPassword` access control). +- **No Brute-Force Resistance**: Allowing unlimited attempts against a custom PIN or password because the app does not track failures. +- **Custom Credentials Hardcoded**: Implementing a custom app PIN or password as a plain comparison in code. ## Impact @@ -47,5 +48,6 @@ Local authentication is only as strong as what it unlocks. When the app merely r - **Bind Authentication to Keystore Keys**: Protect sensitive actions by requiring a cryptographic operation (such as decryption or signing) using keys stored in the platform keystore. Use mechanisms like `CryptoObject` on Android or Keychain access control on iOS (such as `.biometryCurrentSet`) so attackers cannot bypass authentication by hooking software callbacks. - **Use Strict Access Control Flags**: Choose Keychain and keystore parameters that enforce the intended factor and invalidate on enrollment changes (see @MASWE-0023), avoiding weak flags and long authentication validity windows. - **Enforce Authentication Server-Side**: For connected apps, gate server resources on server-verified evidence of authentication (e.g. a signed challenge produced with an authentication-bound key), never on a client-side boolean. -- **Bind Custom Credentials to the Keystore**: Implement custom PINs or passwords via keystore- or Keychain-backed mechanisms (e.g. `applicationPassword`) instead of comparing values in app code. +- **Bind Custom Credentials to the KeyChain**: For defining a custom PIN or password as an authentication factor, bind it to key material by using `applicationPassword` rather than comparing it in app code. - **Require Explicit User Action**: For passive modalities such as face recognition, require explicit confirmation of the authentication prompt before proceeding with sensitive operations. +- **Resist Credential Guessing**: Keep each attempt dependent on hardware-backed key material so guesses cannot be parallelized off-device, and combine app-defined credentials with a biometric or device-credential constraint so every attempt also requires an OS-throttled factor. diff --git a/weaknesses/MASVS-AUTH/MASWE-0024.md b/weaknesses/MASVS-AUTH/MASWE-0024.md index 17e6830..4f96924 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0024.md +++ b/weaknesses/MASVS-AUTH/MASWE-0024.md @@ -1,49 +1,49 @@ ---- +--- title: Lack of Auto-fill Support for Credential Providers -id: MASWE-0024 -alias: autofill-authenticators -requirement: "The app enables auto-fill support for authenticators." -platform: [android, ios] -profiles: [L2] -threat: MAS-THREAT-0024 -attacks: [MAS-ATTACK-0041, MAS-ATTACK-0042] -mappings: - masvs-v1: [MSTG-AUTH-9] - masvs-v2: [MASVS-AUTH-1, MASVS-AUTH-3] - cwe: [287, 522] - android-core-app-quality: [Autofill_Hints, Credential_Manager] - maswe-beta: [MASWE-0028, MASWE-0032, MASWE-0035, MASWE-0039] -refs: -- https://developer.apple.com/documentation/security/password_autofill -- https://developer.apple.com/documentation/authenticationservices/aswebauthenticationsession -- https://developer.android.com/guide/topics/text/autofill -- https://developer.apple.com/documentation/authenticationservices/public-private_key_authentication/supporting_passkeys -status: new ---- - -## Overview - -This weakness occurs when an app does not support the platform's auto-fill and credential-management mechanisms, pushing users toward insecure workarounds such as copying and pasting credentials between apps. - -Platforms provide secure flows for supplying credentials, one-time codes, and passkeys: credential and one-time-code auto-fill, Password AutoFill tied to the app's associated domain, system authentication sessions for third-party services, passwordless authentication with passkeys and WebAuthn, and shared web credentials between an app and its website counterpart. When an app ignores these mechanisms, users end up typing or copying secrets manually, weakening both their credentials and the trust boundary they cross. - -## Modes of Introduction - -- **No Auto-Fill Support in Credential Fields**: Building login fields that are not recognized by or are incompatible with the platform's auto-fill framework and password managers. -- **No One-Time-Code Auto-Fill**: Requiring users to manually read and copy one-time codes (e.g. from SMS) instead of supporting the platform's code auto-fill. +id: MASWE-0024 +alias: autofill-authenticators +requirement: "The app enables auto-fill support for credential providers." +platform: [android, ios] +profiles: [L2] +threat: MAS-THREAT-0024 +attacks: [MAS-ATTACK-0041, MAS-ATTACK-0042] +mappings: + masvs-v1: [MSTG-AUTH-9] + masvs-v2: [MASVS-AUTH-1, MASVS-AUTH-3] + cwe: [287, 522] + android-core-app-quality: [Autofill_Hints, Credential_Manager] + maswe-beta: [MASWE-0028, MASWE-0032, MASWE-0035, MASWE-0039] +refs: +- https://developer.apple.com/documentation/security/password_autofill +- https://developer.apple.com/documentation/authenticationservices/aswebauthenticationsession +- https://developer.android.com/guide/topics/text/autofill +- https://developer.apple.com/documentation/authenticationservices/public-private_key_authentication/supporting_passkeys +status: new +--- + +## Overview + +This weakness occurs when an app does not support the platform's auto-fill and credential-management mechanisms, pushing users toward insecure workarounds such as copying and pasting credentials between apps. + +Platforms provide secure flows for supplying credentials, one-time codes, and passkeys: credential and one-time-code auto-fill, Password AutoFill tied to the app's associated domain, system authentication sessions for third-party services, passwordless authentication with passkeys and WebAuthn, and shared web credentials between an app and its website counterpart. When an app ignores these mechanisms, users end up typing or copying secrets manually, weakening both their credentials and the trust boundary they cross. + +## Modes of Introduction + +- **No Auto-Fill Support in Credential Fields**: Building login fields that are not recognized by or are incompatible with the platform's auto-fill framework and password managers. +- **No One-Time-Code Auto-Fill**: Requiring users to manually read and copy one-time codes (e.g. from SMS) instead of supporting the platform's code auto-fill. - **Missing Website Association**: Not associating the app with its domain, preventing frictionless secure credential sharing between the app and its website counterpart. - **Embedded Custom Login Instead of System Flows**: Handling custom authentication, such as using third-party logins in embedded views, instead of system-provided authentication sessions (e.g. `ASWebAuthenticationSession`). -- **No Support for Passwordless Authentication**: Not offering passkeys or other multi-device FIDO/WebAuthn credentials where they could replace passwords. - -## Impact - -- **Authentication or Authorization Bypass**: Attackers can reuse captured credentials or one-time codes, resulting in account takeover and unauthorized access to the user's data and functionality. -- **Compromise of Sensitive Data**: Attackers can read credentials exposed through clipboard-based workarounds, resulting in disclosure of authentication material that protects sensitive information. - -## Mitigations - -- **Support Platform Auto-Fill**: Annotate credential fields so the platform's auto-fill framework and password managers can fill them securely (e.g. autofill hints on Android, `textContentType` on iOS). -- **Support One-Time-Code Auto-Fill**: Use the platform mechanisms that deliver one-time codes directly into the app, removing the need for manual copying. -- **Associate the App with Its Domain**: Configure website association (e.g. iOS Password AutoFill with associated domains, shared web credentials) so credentials flow securely between the app and its website. -- **Use System Authentication Sessions for Third-Party Logins**: Authenticate against third-party services with system flows such as `ASWebAuthenticationSession` instead of embedded views. +- **No Support for Passwordless Authentication**: Not offering passkeys or other multi-device FIDO/WebAuthn credentials where they could replace passwords. + +## Impact + +- **Authentication or Authorization Bypass**: Attackers can reuse captured credentials or one-time codes, resulting in account takeover and unauthorized access to the user's data and functionality. +- **Compromise of Sensitive Data**: Attackers can read credentials exposed through clipboard-based workarounds, resulting in disclosure of authentication material that protects sensitive information. + +## Mitigations + +- **Support Platform Auto-Fill**: Annotate credential fields so the platform's auto-fill framework and password managers can fill them securely (e.g. autofill hints on Android, `textContentType` on iOS). +- **Support One-Time-Code Auto-Fill**: Use the platform mechanisms that deliver one-time codes directly into the app, removing the need for manual copying. +- **Associate the App with Its Domain**: Configure website association (e.g. iOS Password AutoFill with associated domains, shared web credentials) so credentials flow securely between the app and its website. +- **Use System Authentication Sessions for Third-Party Logins**: Authenticate against third-party services with system flows such as `ASWebAuthenticationSession` instead of embedded views. - **Support Passkeys**: Offer passkeys or other WebAuthn-based passwordless authentication to remove shared secrets from the login flow entirely. diff --git a/weaknesses/MASVS-CODE/MASWE-0040.md b/weaknesses/MASVS-CODE/MASWE-0040.md index 406b914..760c297 100644 --- a/weaknesses/MASVS-CODE/MASWE-0040.md +++ b/weaknesses/MASVS-CODE/MASWE-0040.md @@ -22,22 +22,21 @@ status: new ## Overview -This weakness occurs when an app has no mechanism to force users onto a fixed version after a critical vulnerability is discovered, or when the update requirement is enforced only on the client side. +This weakness occurs when an app has no mechanism to force users to update to a more secure version after a critical vulnerability has been remediated. -When a critical vulnerability is found in a production app, the developer needs a way to move the installed base to a patched version quickly. Platforms provide building blocks for this, such as Android In-App Updates (`AppUpdateManager`) and store version checks on iOS, but robust enforcement requires the backend to signal and enforce the minimum acceptable version: a purely client-side check can be bypassed by the very attackers it is meant to stop. +When a critical vulnerability is found in a production app, the developer needs a way to migrate existing users to the latest version as quickly as possible. Platforms provide building blocks for this, such as Android In-App Updates (`AppUpdateManager`) and store version checks on iOS, but robust enforcement requires the backend to signal and enforce the minimum acceptable version. ## Modes of Introduction - **No Enforced-Update Mechanism**: Shipping the app without any in-app or enforced update flow, so vulnerable versions keep working indefinitely. -- **Client-Side-Only Enforcement**: Enforcing the update requirement only in app code, without the backend rejecting requests from versions below the minimum supported one. ## Impact - **Compromise of Sensitive Data**: Attackers can exploit already-fixed vulnerabilities against users stuck on old versions, resulting in exposure of user data long after a patch was published. -- **Compromise of System Integrity and Business Operations**: The app owner cannot retire vulnerable versions from the installed base, resulting in a prolonged attack window, extended incident response, and continued abuse of backend services. +- **Compromise of System Integrity and Business Operations**: The app owner cannot retire vulnerable versions from the installed base, resulting in a prolonged attack window. ## Mitigations - **Implement an Enforced Update Flow**: Use platform mechanisms such as Android In-App Updates or a version check against the app store on iOS to require updating when a critical fix ships. -- **Enforce the Minimum Version Server-Side**: Have the backend declare the minimum supported app version and reject requests from older clients, so bypassing the client-side prompt does not restore access. +- **Enforce the Minimum Version Server-Side**: Have the backend declare the minimum supported app version and reject requests from older clients. - **Distinguish Flexible and Immediate Updates**: Reserve blocking (immediate) updates for security-critical releases and use flexible updates otherwise, so users accept the mechanism when it matters. diff --git a/weaknesses/MASVS-CODE/MASWE-0043.md b/weaknesses/MASVS-CODE/MASWE-0043.md index ed08cf2..0cd413f 100644 --- a/weaknesses/MASVS-CODE/MASWE-0043.md +++ b/weaknesses/MASVS-CODE/MASWE-0043.md @@ -2,7 +2,7 @@ title: Latest Platform Version Not Targeted id: MASWE-0043 alias: target-latest-platform-version -requirement: "The app targets a recent OS version." +requirement: "The app targets the latest platform version." platform: [android, ios] profiles: [L2] threat: MAS-THREAT-0043 @@ -20,9 +20,9 @@ status: new ## Overview -This weakness occurs when an app does not target a recent platform version, missing the newest platform-enforced security protections and behavior changes. +This weakness occurs when an app does not target the latest platform version, missing the newest platform-enforced security protections and behavior changes. -Targeting the latest platform version, via `targetSdkVersion` on Android or by building with a recent Xcode/SDK on iOS, opts the app into protections such as scoped storage, stricter runtime-permission handling, permission auto-reset, and modern TLS defaults. When an app targets an old version, the OS applies backward-compatibility behaviors and the app silently misses these protections. This is distinct from the minimum supported version (see @MASWE-0042): here the concern is the target/compiled version. +Targeting the latest platform version, via `targetSdkVersion` on Android or by building with the latest Xcode/SDK on iOS, opts the app into protections such as scoped storage, stricter runtime-permission handling, permission auto-reset, and modern TLS defaults. When an app targets an old version, the OS applies backward-compatibility behaviors and the app silently misses these protections. This is distinct from the minimum supported version (see @MASWE-0042): here the concern is the target/compiled version. ## Modes of Introduction @@ -36,5 +36,5 @@ Targeting the latest platform version, via `targetSdkVersion` on Android or by b ## Mitigations -- **Target the Latest Platform Version**: Update `targetSdkVersion` and build with a recent SDK promptly each platform cycle, following the store requirements for [Android](https://developer.android.com/google/play/requirements/target-sdk) and [iOS](https://developer.apple.com/news/upcoming-requirements/). -- **Adopt New Protections Deliberately**: Review each platform release's behavior changes and migrate off legacy behaviors instead of suppressing or postponing them. +- **Target the Latest Platform Version**: Update `targetSdkVersion` and build with the latest SDK promptly each platform cycle, following the store requirements for [Android](https://developer.android.com/google/play/requirements/target-sdk) and [iOS](https://developer.apple.com/news/upcoming-requirements/). +- **Adopt New Protections**: Review each platform release's behavior changes and migrate off legacy behaviors. diff --git a/weaknesses/MASVS-CODE/MASWE-0044.md b/weaknesses/MASVS-CODE/MASWE-0044.md index bfbed0c..7805b35 100644 --- a/weaknesses/MASVS-CODE/MASWE-0044.md +++ b/weaknesses/MASVS-CODE/MASWE-0044.md @@ -28,7 +28,7 @@ Dynamic code loading includes loading native libraries via `dlopen`, loading DEX ## Modes of Introduction -- **Loading from Writable or External Locations**: Loading native libraries or DEX/JAR files from writable, external, or world-accessible storage where other apps or actors can replace them. +- **Loading from Writable or External Locations**: Loading native libraries or DEX/JAR files from writable, external, or world-accessible storage where other malicious apps can replace them. - **Downloaded Code Without Verification**: Downloading and executing code, plugins, or scripts without verifying their integrity and authenticity (e.g. signature verification, see @MASWE-0015). - **Code from Other Packages**: Executing code from other installed packages (e.g. via package contexts with code inclusion) whose identity and integrity are not verified. diff --git a/weaknesses/MASVS-CODE/MASWE-0046.md b/weaknesses/MASVS-CODE/MASWE-0046.md index 0848f0b..7a48fad 100644 --- a/weaknesses/MASVS-CODE/MASWE-0046.md +++ b/weaknesses/MASVS-CODE/MASWE-0046.md @@ -23,7 +23,7 @@ status: new This weakness occurs when an app relies on deprecated APIs or functionality that are no longer maintained, may lack security fixes, or have been superseded by safer alternatives. -Platforms deprecate APIs precisely because better-designed replacements exist, often fixing security shortcomings of the old API. Continuing to use deprecated security-relevant APIs can leave the app exposed to weaknesses the platform has already addressed. A representative example is the use of deprecated Android KeyStore implementations such as Bouncy Castle (BKS), but this weakness covers deprecated APIs and functionality in general, including cryptography, storage, networking, and platform features. +Platforms deprecate APIs for various reasons. It may be architectural changes, lack of developer adoption, reduced hardware support, or a better-designed replacement that fixes security shortcomings of the old API. Continuing to use deprecated security-relevant APIs can leave the app exposed to weaknesses the platform has already addressed. A representative example is the use of deprecated Android KeyStore implementations such as Bouncy Castle (BKS), but this weakness covers deprecated APIs and functionality in general, including cryptography, storage, networking, and platform features. ## Modes of Introduction @@ -38,6 +38,7 @@ Platforms deprecate APIs precisely because better-designed replacements exist, o ## Mitigations -- **Migrate Off Deprecated APIs**: Replace deprecated security-relevant APIs with the platform's recommended alternatives as part of regular maintenance. +- **Migrate Off Deprecated APIs**: Replace deprecated APIs with the platform's recommended alternatives as part of regular maintenance. Prioritize migration of security-relevant APIs. - **Treat Deprecation Warnings as Actionable**: Surface deprecation warnings in builds and reviews, and track migrations for security-relevant APIs with priority. -- **Follow Platform Release Notes**: Review each platform release's deprecation and behavior-change notes to plan migrations before old functionality is removed or breaks. +- **Follow Platform Release Notes**: Review each platform release's deprecation and behavior-change notes to plan migrations before old functionality is removed or breaks. +- **Test the App on All Supported Platforms**: Run the app on all platform API versions supported during development. diff --git a/weaknesses/MASVS-CODE/MASWE-0047.md b/weaknesses/MASVS-CODE/MASWE-0047.md index 551557f..edffd1a 100644 --- a/weaknesses/MASVS-CODE/MASWE-0047.md +++ b/weaknesses/MASVS-CODE/MASWE-0047.md @@ -2,7 +2,7 @@ title: Using Non-Standard APIs for Security-Critical Functionality id: MASWE-0047 alias: non-standard-security-apis -requirement: "The app does not use non-standard APIs for security-critical functionality." +requirement: "The app uses standard APIs for security-critical functionality." platform: [android, ios] profiles: [L2] threat: MAS-THREAT-0047 diff --git a/weaknesses/MASVS-CODE/MASWE-0048.md b/weaknesses/MASVS-CODE/MASWE-0048.md index f2716eb..3857ddd 100644 --- a/weaknesses/MASVS-CODE/MASWE-0048.md +++ b/weaknesses/MASVS-CODE/MASWE-0048.md @@ -38,9 +38,9 @@ When the untrusted data reaches a dangerous sink that has not been validated or ## Modes of Introduction -- **Missing Validation at Trust Boundaries**: Consuming data from the network, backups, external interfaces, files, UI, or IPC without validating type, length, format, and range before use. -- **Untrusted Data in Queries**: Concatenating untrusted input into SQL or other queries instead of using parameterized APIs. -- **Untrusted Paths and Archives**: Using externally supplied file names or paths (e.g. from content providers or zip entries) without canonicalization and containment checks. +- **Missing Validation at Trust Boundaries**: Consuming untrusted data from the network, backups, external interfaces, files, UI, or platform IPC without validating type, length, format, and range before use. +- **Untrusted Data in Queries**: Concatenating untrusted input into queries like SQL queries instead of using parameterized APIs. +- **Untrusted Paths and Archives**: Using externally supplied file names or paths (e.g. from ZIP entries) without canonicalization and containment checks. - **Insecure Parsing**: Parsing untrusted XML with external entities enabled, or emitting untrusted data without proper output encoding. - **Insecure Deserialization**: Deserializing untrusted data into rich object types (e.g. `Serializable`, `Parcelable`, `NSCoding`, XML/JSON object mappers) without restricting the allowed types. - **Weakly Validated URI Handling**: Relying on URI parsing classes that apply little to no validation of untrusted input when making security decisions. @@ -55,9 +55,9 @@ When the untrusted data reaches a dangerous sink that has not been validated or ## Mitigations -- **Validate at Every Trust Boundary**: Treat all externally originated data as untrusted, including data received over TLS or restored from backups, and validate it against strict expectations before use. -- **Use Parameterized Queries**: Access databases exclusively through parameterized or prepared statements; never build queries by concatenating untrusted input. -- **Canonicalize and Contain Paths**: Canonicalize externally supplied file names and paths and verify they resolve inside the intended directory before any file operation, including when extracting archives. +- **Validate at Every Trust Boundary**: Treat all externally originated data as untrusted and validate it against strict expectations before use. +- **Use Parameterized Queries**: Access databases exclusively through parameterized or prepared statements. Do not build queries by concatenating untrusted input. +- **Canonicalize and Contain Paths**: Canonicalize externally supplied file names and paths and verify they resolve inside the intended directory before any file operation. - **Harden Parsers**: Disable external entity resolution for XML, apply correct output encoding for the destination context, and prefer hardened platform parsers. - **Deserialize Safely**: Avoid deserializing untrusted data into rich object graphs; prefer simple data formats and safe APIs with explicit type allow-lists. - **Distinguish Untrusted Data From Application-Generated Content**: Distinguish externally-provided values from trusted application content, especially in notifications and security-sensitive interfaces. Apply context-appropriate length, line, and formatting restrictions so untrusted data cannot obscure or alter the apparent meaning of the information presented. From 172e4e99e35c568bcd12a0a493066dc43a51c24f Mon Sep 17 00:00:00 2001 From: Carlos Holguera Date: Tue, 28 Jul 2026 09:53:49 +0200 Subject: [PATCH 61/70] Apply suggestion from @cpholguera --- weaknesses/MASVS-AUTH/MASWE-0024.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/weaknesses/MASVS-AUTH/MASWE-0024.md b/weaknesses/MASVS-AUTH/MASWE-0024.md index 4f96924..164e7b6 100644 --- a/weaknesses/MASVS-AUTH/MASWE-0024.md +++ b/weaknesses/MASVS-AUTH/MASWE-0024.md @@ -2,7 +2,8 @@ title: Lack of Auto-fill Support for Credential Providers id: MASWE-0024 alias: autofill-authenticators -requirement: "The app enables auto-fill support for credential providers." +requirement: "The app enables auto-fill support for credential providers." + platform: [android, ios] profiles: [L2] threat: MAS-THREAT-0024 From 4141b3f7e99e377031275c3050262e0c14ca23d7 Mon Sep 17 00:00:00 2001 From: Carlos Holguera Date: Tue, 28 Jul 2026 14:10:41 +0200 Subject: [PATCH 62/70] Apply suggestions from code review Co-authored-by: Jeroen Beckers --- weaknesses/MASVS-CODE/MASWE-0075.md | 6 +++--- weaknesses/MASVS-CODE/MASWE-0077.md | 8 +++++--- 2 files changed, 8 insertions(+), 6 deletions(-) diff --git a/weaknesses/MASVS-CODE/MASWE-0075.md b/weaknesses/MASVS-CODE/MASWE-0075.md index 3ff3f3e..1a3ec38 100644 --- a/weaknesses/MASVS-CODE/MASWE-0075.md +++ b/weaknesses/MASVS-CODE/MASWE-0075.md @@ -21,11 +21,11 @@ status: new This weakness occurs when an app ships with malicious code, introduced either intentionally by an insider or unintentionally through a compromised dependency, SDK, build tool, or other supply-chain attack. -Malicious code can exfiltrate data, execute hidden or backdoored functionality, display unwanted content, or perform actions against the user's interest. Because the developer is responsible for all code shipped in the app, including third-party SDKs, the codebase must be reviewed and the supply chain controlled to detect and prevent the inclusion of malicious code. This complements @MASWE-0041, which covers dependencies with known vulnerabilities, and @MASWE-0077, which covers the inability to verify what was actually built. +Malicious code can exfiltrate data, execute hidden or backdoored functionality, display unwanted content, or perform actions against the user's interest. Because the developer is responsible for all code shipped in the app, including third-party SDKs, the codebase must be reviewed and the supply chain examined to detect and prevent the inclusion of malicious code. This complements @MASWE-0041, which covers dependencies with known vulnerabilities, and @MASWE-0077, which covers the inability to verify what was actually built. ## Modes of Introduction -- **Insider-Introduced Code**: Malicious code committed intentionally by someone with access to the codebase or through a compromised developer account. +- **Malicious Developer**: Malicious code committed intentionally by someone with access to the codebase or through a compromised developer account. - **Compromised Dependencies**: Malicious or trojanized third-party SDKs and libraries pulled into the app, including through typosquatting or hijacked packages. - **Compromised Build Pipeline**: Build tools, plugins, or CI/CD infrastructure that inject code into the app during compilation or packaging. - **Hidden Functionality**: Backdoors, hidden switches, or undisclosed capabilities shipped in the app or its components. @@ -39,6 +39,6 @@ Malicious code can exfiltrate data, execute hidden or backdoored functionality, ## Mitigations - **Review Code and Changes**: Enforce code review for all changes, restrict and monitor access to the codebase, and require strong authentication for developer accounts. -- **Control the Supply Chain**: Pin dependency versions, verify package integrity and provenance, source components only from reputable publishers, and monitor them with Software Composition Analysis (see @MASWE-0041). +- **Examine the Supply Chain**: Pin dependency versions, verify package integrity and provenance, source components only from reputable publishers, and monitor them with Software Composition Analysis (see @MASWE-0041). - **Protect the Build Pipeline**: Harden and monitor CI/CD infrastructure, restrict who and what can alter build configurations, and generate build provenance attestations (see @MASWE-0077). - **Analyze the Shipped Artifact**: Scan and behaviorally analyze release builds to detect unexpected code, permissions, or network endpoints before distribution. diff --git a/weaknesses/MASVS-CODE/MASWE-0077.md b/weaknesses/MASVS-CODE/MASWE-0077.md index 3d9d7b1..1c63537 100644 --- a/weaknesses/MASVS-CODE/MASWE-0077.md +++ b/weaknesses/MASVS-CODE/MASWE-0077.md @@ -19,19 +19,20 @@ status: new ## Overview -This weakness occurs when compiling the app's source with the same build environment does not yield a bit-for-bit identical artifact, making it impossible to independently verify that a distributed binary was built from the claimed, unmodified source. +This weakness occurs when compiling the app's source with the same build environment does not yield a bit-for-bit identical binary, making it impossible to independently verify that a distributed binary was built from the claimed, unmodified source. Reproducible builds allow third parties, and the developers themselves, to detect tampering or injected malicious code by rebuilding from source and comparing the result with the released artifact. Without reproducibility, this verification is impossible, weakening supply-chain integrity. Together with build provenance and attestation frameworks (e.g. SLSA), reproducible builds let stakeholders verify the integrity of released artifacts. ## Modes of Introduction - **Non-Deterministic Build Outputs**: Embedding timestamps, absolute paths, environment data, or unstable orderings in build artifacts, so identical inputs produce differing outputs. -- **Unpinned Build Environments**: Building with undocumented or unpinned toolchains and dependencies, so no one can recreate the environment that produced a release. +- **Unpinned Build Environments**: Building with undocumented or unpinned toolchains and dependencies, so it's impossible to recreate the environment that produced a release. - **No Provenance or Attestation**: Publishing releases without provenance describing what was built, from which source, and by which pipeline. +- **Applying Non-Deterministic Obfuscation Controls**: By applying non-deterministic obfuscation controls, each build will generate a new random binary which cannot directly be compared with previous builds from the same code. ## Impact -- **Execution of Unauthorized Code**: Attackers can inject code during the build or distribution process without detection, since no independent party can verify the binary against the source, resulting in malicious code shipping to the entire user base. +- **Execution of Unauthorized Code**: Attackers can inject code during the build or distribution process without straightforward detection, since no independent party can verify the binary against the source, resulting in malicious code shipping to the entire user base. - **Loss of User Trust**: Users and auditors cannot verify that the shipped app matches the published source, resulting in weakened trust in the app, particularly for security- and privacy-sensitive apps. ## Mitigations @@ -39,3 +40,4 @@ Reproducible builds allow third parties, and the developers themselves, to detec - **Make Builds Deterministic**: Eliminate timestamps, absolute paths, environment-dependent data, and unstable orderings from build outputs, following [reproducible-builds.org](https://reproducible-builds.org/) guidance. - **Pin and Document the Build Environment**: Define the exact toolchain and dependency versions in version control so any party can recreate the build environment. - **Publish Provenance and Attestations**: Generate build provenance (e.g. per [SLSA](https://slsa.dev/)) and, where feasible, publish verification instructions so third parties can reproduce and compare releases. +- **Use Deterministic Obfuscation Techniques**: Use obfuscation techniques which will always generate the same deterministic result. From ef373cc6c497ed6f4423d6625ff024982304cae0 Mon Sep 17 00:00:00 2001 From: Carlos Holguera Date: Tue, 28 Jul 2026 14:28:29 +0200 Subject: [PATCH 63/70] Apply suggestions from code review Co-authored-by: Jeroen Beckers Co-authored-by: Stefan Co-authored-by: Carlos Holguera --- weaknesses/MASVS-PLATFORM/MASWE-0032.md | 2 +- weaknesses/MASVS-PLATFORM/MASWE-0033.md | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0032.md b/weaknesses/MASVS-PLATFORM/MASWE-0032.md index 30a46d2..bb8d996 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0032.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0032.md @@ -24,7 +24,7 @@ status: new This weakness occurs when an app handles deep links insecurely, relying on unverified schemes or trusting the attacker-controllable data they carry. -Deep links (Android App Links and custom URL schemes, iOS Universal Links and custom schemes) let other apps and websites launch the app at a specific screen and pass parameters. They become insecure when the app relies on custom URL schemes that any app can claim, does not verify App Links or Universal Links through domain association, or fails to validate and sanitize the incoming URL and its parameters. Because deep-link input is attacker-controllable, a malformed URI or parameter can trigger injection or logic abuse at various points in the app. +Deep links (Android App Links and custom URL schemes, iOS Universal Links and custom schemes) let other apps and websites launch the app, trigger an in-app action and pass parameters. They become insecure when the app relies on custom URL schemes that any app can claim, does not verify App Links or Universal Links through domain association, or fails to validate and sanitize the incoming URL and its parameters. Because deep-link input is attacker-controllable, a malformed URI or parameter can trigger injection or logic abuse at various points in the app. ## Modes of Introduction diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0033.md b/weaknesses/MASVS-PLATFORM/MASWE-0033.md index 6eb99da..fee8206 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0033.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0033.md @@ -2,7 +2,7 @@ title: Improper Use of the Clipboard id: MASWE-0033 alias: improper-clipboard -requirement: "The app avoids placing sensitive data on the system clipboard." +requirement: "The app uses the clipboard securely and only with user consent." platform: [android, ios] profiles: [L1, L2] threat: MAS-THREAT-0033 @@ -23,11 +23,11 @@ status: new This weakness occurs when an app places sensitive data on the system clipboard, or handles clipboard content insecurely, exposing that data beyond the app's control. -The clipboard is a shared resource: other apps can read its contents, and on some platforms clipboard content synchronizes to nearby devices via a universal clipboard. Copying sensitive data such as passwords, one-time codes, card numbers, or tokens to the clipboard, failing to mark it as sensitive, or leaving it there indefinitely can leak that data to other apps and devices. +The clipboard is a shared resource: other apps can read its contents, and on some platforms, clipboard content synchronizes to nearby devices via a universal clipboard. Copying sensitive data such as passwords, one-time codes, card numbers, or tokens to the clipboard, failing to mark it as sensitive, or leaving it there indefinitely can leak that data to other apps and devices. ## Modes of Introduction -- **Sensitive Data Copyable**: Allowing sensitive values such as passwords, one-time codes, or card numbers to be copied to the clipboard. +- **Sensitive Data Copyable Without User Consent**: Allowing sensitive values such as passwords, one-time codes, or card numbers to be copied to the clipboard without user consent. - **Clipboard Content Not Marked Sensitive**: Not flagging copied sensitive content as sensitive where the platform supports it (e.g. `EXTRA_IS_SENSITIVE` on Android), so previews and clipboard history show it in cleartext. - **Universal Clipboard Not Restricted**: Not restricting sensitive clipboard items to the local device or setting an expiration on iOS, letting them sync to other devices. - **Clipboard Not Cleared**: Leaving sensitive content on the clipboard after it has served its purpose. From a254cafdf6bcd6cc3e1f1bfcccf331718ab7af17 Mon Sep 17 00:00:00 2001 From: Carlos Holguera Date: Tue, 28 Jul 2026 14:44:12 +0200 Subject: [PATCH 64/70] Apply suggestions from code review Co-authored-by: Jeroen Beckers Co-authored-by: Stefan --- weaknesses/MASVS-PLATFORM/MASWE-0035.md | 5 +++-- weaknesses/MASVS-PLATFORM/MASWE-0038.md | 8 +++++--- 2 files changed, 8 insertions(+), 5 deletions(-) diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0035.md b/weaknesses/MASVS-PLATFORM/MASWE-0035.md index 06094c5..c128804 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0035.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0035.md @@ -32,7 +32,7 @@ status: new This weakness occurs when an app creates or handles Android intents insecurely, allowing other apps to intercept, redirect, or manipulate its communication. -Intents are Android's primary inter- and intra-app messaging mechanism. Insecure handling includes sending sensitive data via implicit intents that any matching app can receive, acting on untrusted intents (e.g. calling `startActivity`, `startService`, `sendBroadcast`, or `setResult` on intents received from other apps) without validation, creating PendingIntents that other apps can modify or replay, and using sticky broadcasts, which any app can read and replace. +Intents are Android's primary inter- and intra-app messaging mechanism. Insecure handling includes sending sensitive data via implicit intents that any matching app can receive, acting on untrusted intents and their extended data (e.g. calling `startActivity`, `startService`, `sendBroadcast`, or `setResult` on intents received from other apps) without validation, creating PendingIntents that other apps can modify or replay, and using sticky broadcasts, which any app can read and replace. ## Modes of Introduction @@ -52,4 +52,5 @@ Intents are Android's primary inter- and intra-app messaging mechanism. Insecure - **Use Explicit Intents Internally**: Address internal communication to explicit component targets so no other app can receive it, and never place sensitive data in implicit intents. - **Validate Redirected Intents**: Before forwarding a nested intent from untrusted input, validate its destination against an allowlist and strip unexpected flags. - **Create Immutable, Explicit PendingIntents**: Build PendingIntents with `FLAG_IMMUTABLE` over explicit base intents, and add `FLAG_ONE_SHOT` where a single use is intended. -- **Avoid Sticky Broadcasts**: Use regular broadcasts protected with permissions, or more targeted mechanisms, instead of sticky broadcasts. +- **Avoid Sticky Broadcasts**: Use regular broadcasts protected with permissions, or more targeted mechanisms, instead of [deprecated](https://developer.android.com/privacy-and-security/risks/sticky-broadcast#overview) sticky broadcasts. +-**Validate Incoming Intent Data**: Treat all extended intent data entering the app through exported components as untrusted. Validate it before further processing (@MASWE-0048). diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0038.md b/weaknesses/MASVS-PLATFORM/MASWE-0038.md index c408aef..913b7f2 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0038.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0038.md @@ -2,7 +2,7 @@ title: WebViews Loading Untrusted Content id: MASWE-0038 alias: webviews-untrusted-content -requirement: "The app does not allow WebViews to load untrusted content." +requirement: "The app only allows trusted content in WebViews." platform: [android, ios] profiles: [L1, L2] threat: MAS-THREAT-0038 @@ -23,11 +23,13 @@ status: new This weakness occurs when a WebView loads URLs, HTML, or JavaScript from untrusted sources, or lets users navigate to arbitrary sites outside the developer's control. -WebViews often run with app-specific privileges, such as JavaScript bridges, cookies, and stored sessions, so loading untrusted content into them is far more dangerous than opening it in the system browser. A URL received via an intent or deep link, or JavaScript fetched from an unverified source, can lead to cross-site scripting, including Universal XSS, allowing an attacker to steal cookies and tokens from any site, perform phishing, or trigger drive-by downloads. +WebViews run with app-specific privileges and often use JavaScript bridges to communicate between the web sandbox and the app to access contacts, local files, the device location, or its camera. Loading untrusted content into WebViews is therefore more dangerous than opening it in an external browser. + +A URL received via an intent or deep link, or JavaScript fetched from an unverified source, can lead to cross-site scripting, including Universal XSS, allowing an attacker to steal cookies and tokens from any site, perform phishing attacks, or trigger drive-by downloads. Actors can also access functionality outside the web sandbox using JavaScript bridges declared by the developers. ## Modes of Introduction -- **Unrestricted Navigation**: Not restricting which origins the WebView may load (e.g. via `WebViewClient.shouldOverrideUrlLoading` or navigation delegates), letting users or content navigate anywhere. +- **Unrestricted Navigation**: Not restricting which origins the WebView may load (e.g. via `WebViewClient.shouldOverrideUrlLoading` or navigation delegates), letting users or content navigate anywhere directly, or loading domains that can be used to navigate to attacker-controlled domains. - **Untrusted URLs from External Input**: Loading URLs received through intents, deep links, or other external input without validating them against an allowlist. - **Untrusted Script Inclusion**: Loading JavaScript from unverified sources into pages rendered by the WebView. - **Safe Browsing Disabled**: Disabling platform protections such as Safe Browsing that warn about known-malicious sites. From 549283412b911410f8b838616b52d2d38c001911 Mon Sep 17 00:00:00 2001 From: Carlos Holguera Date: Tue, 28 Jul 2026 14:47:27 +0200 Subject: [PATCH 65/70] Apply suggestion from @TheDauntless Co-authored-by: Jeroen Beckers --- weaknesses/MASVS-PLATFORM/MASWE-0037.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0037.md b/weaknesses/MASVS-PLATFORM/MASWE-0037.md index 0e0369d..ffb80e9 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0037.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0037.md @@ -2,7 +2,7 @@ title: WebViews Allow Access to Local Resources with Untrusted Content id: MASWE-0037 alias: webviews-local-resources -requirement: "The app does not allow WebViews loading untrusted content to access local resources." +requirement: "The app only allows trusted WebView content to access local resources." platform: [android, ios] profiles: [L1, L2] threat: MAS-THREAT-0037 From 8014b3f444f621466048efd19b7fdde91d16a8fb Mon Sep 17 00:00:00 2001 From: Jeroen Date: Tue, 28 Jul 2026 16:29:57 +0200 Subject: [PATCH 66/70] Update 0033 --- weaknesses/MASVS-PLATFORM/MASWE-0033.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0033.md b/weaknesses/MASVS-PLATFORM/MASWE-0033.md index fee8206..5a4519e 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0033.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0033.md @@ -23,11 +23,11 @@ status: new This weakness occurs when an app places sensitive data on the system clipboard, or handles clipboard content insecurely, exposing that data beyond the app's control. -The clipboard is a shared resource: other apps can read its contents, and on some platforms, clipboard content synchronizes to nearby devices via a universal clipboard. Copying sensitive data such as passwords, one-time codes, card numbers, or tokens to the clipboard, failing to mark it as sensitive, or leaving it there indefinitely can leak that data to other apps and devices. +The clipboard is a shared resource: other apps can read its contents, and on some platforms, clipboard content synchronizes to nearby devices via a universal clipboard. Copying sensitive data such as passwords, one-time codes, card numbers, or tokens to the clipboard, failing to mark it as sensitive, or leaving it there indefinitely can leak that data to other apps and devices. ## Modes of Introduction -- **Sensitive Data Copyable Without User Consent**: Allowing sensitive values such as passwords, one-time codes, or card numbers to be copied to the clipboard without user consent. +- **Sensitive Data Copyable Without User Consent**: Copying sensitive values such as passwords, one-time codes, or card numbers to the clipboard without user consent. - **Clipboard Content Not Marked Sensitive**: Not flagging copied sensitive content as sensitive where the platform supports it (e.g. `EXTRA_IS_SENSITIVE` on Android), so previews and clipboard history show it in cleartext. - **Universal Clipboard Not Restricted**: Not restricting sensitive clipboard items to the local device or setting an expiration on iOS, letting them sync to other devices. - **Clipboard Not Cleared**: Leaving sensitive content on the clipboard after it has served its purpose. @@ -41,6 +41,8 @@ The clipboard is a shared resource: other apps can read its contents, and on som ## Mitigations - **Avoid the Clipboard for Secrets**: Disable copying for sensitive fields and provide secure alternatives such as auto-fill (see @MASWE-0024) so users never need to copy secrets. +- **Only copy with User Consent**: If copying is required, ask the user for consent before placing sensitive data on the clipboard, or only act as a result of a user-chosen action (e.g. a "Copy" button). - **Mark Clipboard Content as Sensitive**: When sensitive content must be copied, flag it as sensitive so the platform masks previews and treats it accordingly. -- **Restrict Clipboard Scope and Lifetime**: Keep sensitive clipboard items local to the device, set expirations where supported, and clear the clipboard once the data has been used. +- **Specify an appropriate expiration**: When sensitive content must be copied, set an expiration so it is removed from the clipboard after a short time. +- **Restrict Clipboard Exposure**: When copying, follow the platform's [secure clipboard handling guidance on Android](https://developer.android.com/privacy-and-security/risks/secure-clipboard-handling) and mark the content using [`ClipDescription.EXTRA_IS_SENSITIVE`](https://developer.android.com/reference/android/content/ClipDescription#EXTRA_IS_SENSITIVE) to obscure clipboard previews. On iOS, use pasteboard options such as [`localOnly`](https://developer.apple.com/documentation/uikit/uipasteboard/optionskey/localonly) and [`expirationDate`](https://developer.apple.com/documentation/uikit/uipasteboard/optionskey/expirationdate) to limit cross-device propagation and content lifetime. - **Validate Pasted Data**: Treat clipboard content as untrusted input and validate it before use. From 1ba76597ca269669eb8448eb1912d77bbed09cba Mon Sep 17 00:00:00 2001 From: Carlos Holguera Date: Wed, 29 Jul 2026 09:12:10 +0200 Subject: [PATCH 67/70] Apply suggestions from code review Co-authored-by: Carlos Holguera --- weaknesses/MASVS-PLATFORM/MASWE-0032.md | 92 ++++++++++++------------- 1 file changed, 46 insertions(+), 46 deletions(-) diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0032.md b/weaknesses/MASVS-PLATFORM/MASWE-0032.md index bb8d996..8877361 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0032.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0032.md @@ -1,46 +1,46 @@ ---- -title: Insecure Deep Links -id: MASWE-0032 -alias: insecure-deep-links -requirement: "The app securely handles deep links." -platform: [android, ios] -profiles: [L1, L2] -threat: MAS-THREAT-0032 -attacks: [MAS-ATTACK-0046, MAS-ATTACK-0047] -mappings: - masvs-v1: [MSTG-PLATFORM-3] - masvs-v2: [MASVS-PLATFORM-1, MASVS-STORAGE-2, MASVS-CODE-4] - cwe: [939, 917] - android-risks: - - unsafe-use-of-deeplinks - maswe-beta: [MASWE-0058] -refs: -- https://developer.apple.com/documentation/technotes/tn3155-debugging-universal-links -- https://developer.android.com/training/app-links/verify-android-applinks -status: new ---- - -## Overview - -This weakness occurs when an app handles deep links insecurely, relying on unverified schemes or trusting the attacker-controllable data they carry. - -Deep links (Android App Links and custom URL schemes, iOS Universal Links and custom schemes) let other apps and websites launch the app, trigger an in-app action and pass parameters. They become insecure when the app relies on custom URL schemes that any app can claim, does not verify App Links or Universal Links through domain association, or fails to validate and sanitize the incoming URL and its parameters. Because deep-link input is attacker-controllable, a malformed URI or parameter can trigger injection or logic abuse at various points in the app. - -## Modes of Introduction - -- **Unverified Custom URL Schemes**: Relying on custom URL schemes for sensitive flows even though any installed app can claim the same scheme. -- **Missing Domain Association**: Declaring App Links without `autoVerify` and Digital Asset Links, or Universal Links without a valid apple-app-site-association file, so links are not cryptographically tied to the app's domain. -- **Unvalidated Deep-Link Input**: Passing the deep-link URL and its parameters into navigation decisions, WebViews, or queries without validation and sanitization. - -## Impact - -- **Compromise of Sensitive Data**: Attackers can intercept tokens or personal data carried in deep links, or exfiltrate data through injected parameters, resulting in unauthorized disclosure of user data. -- **Authentication or Authorization Bypass**: Attackers can capture authentication material delivered via hijacked links (e.g. login or password-reset links), resulting in account takeover. -- **Execution of Unauthorized Code**: Attackers can inject expressions or script through unsanitized deep-link parameters that reach interpreters or WebViews, resulting in attacker-controlled behavior inside the app. - -## Mitigations - -- **Use Verified Link Mechanisms**: Handle sensitive flows only through verified Android App Links (with `autoVerify` and Digital Asset Links) and iOS Universal Links, not through claimable custom schemes. -- **Validate and Sanitize Deep-Link Input**: Treat every deep-link URL and parameter as untrusted input; validate against an allowlist of expected destinations and value formats before use. -- **Validate the Source Where Possible**: Verify the calling application or referrer for custom scheme invocations when the platform allows it. -- **Keep Secrets Out of Deep Links**: Avoid transporting session tokens or other secrets in links; where unavoidable, make them single-use and short-lived. +--- +title: Insecure Deep Links +id: MASWE-0032 +alias: insecure-deep-links +requirement: "The app securely handles deep links." +platform: [android, ios] +profiles: [L1, L2] +threat: MAS-THREAT-0032 +attacks: [MAS-ATTACK-0046, MAS-ATTACK-0047] +mappings: + masvs-v1: [MSTG-PLATFORM-3] + masvs-v2: [MASVS-PLATFORM-1, MASVS-STORAGE-2, MASVS-CODE-4] + cwe: [939, 917] + android-risks: + - unsafe-use-of-deeplinks + maswe-beta: [MASWE-0058] +refs: +- https://developer.apple.com/documentation/technotes/tn3155-debugging-universal-links +- https://developer.android.com/training/app-links/verify-android-applinks +status: new +--- + +## Overview + +This weakness occurs when an app handles deep links insecurely, relying on unverified schemes or trusting the attacker-controllable data they carry. + +Deep links (Android App Links, iOS Universal Links and custom URL schemes) let other apps and websites launch the app, trigger an in-app action and pass parameters. They become insecure when the app relies on custom URL schemes that any app can claim, does not verify App Links or Universal Links through domain association, or fails to validate and sanitize the incoming URL and its parameters. Because deep link input is attacker-controllable, a malformed URI or parameter can trigger injection or logic abuse at various points in the app. + +## Modes of Introduction + +- **Unverified Custom URL Schemes**: Relying on custom URL schemes for sensitive flows even though any installed app can claim the same scheme. +- **Missing Domain Association**: Declaring App Links without `autoVerify` and Digital Asset Links, or Universal Links without a valid apple-app-site-association file, so links are not cryptographically tied to the app's domain. +- **Unvalidated Deep Link Input**: Passing the deep link URL and its parameters into navigation decisions, WebViews, or queries without validation and sanitization. + +## Impact + +- **Compromise of Sensitive Data**: Attackers can intercept tokens or personal data carried in deep links, or exfiltrate data through injected parameters, resulting in unauthorized disclosure of user data. +- **Authentication or Authorization Bypass**: Attackers can capture authentication material delivered via hijacked links (e.g. login or password-reset links), resulting in account takeover. +- **Execution of Unauthorized Code**: Attackers can inject expressions or script through unsanitized deep link parameters that reach interpreters or WebViews, resulting in attacker-controlled behavior inside the app. + +## Mitigations + +- **Use Verified Link Mechanisms**: Handle sensitive flows only through verified Android App Links (with `autoVerify` and Digital Asset Links) and iOS Universal Links, not through claimable custom schemes. +- **Validate and Sanitize Deep Link Input**: Treat every deep link URL and parameter as untrusted input; validate against an allowlist of expected destinations and value formats before use. +- **Validate the Source Where Possible**: Verify the calling application or referrer for custom scheme invocations when the platform allows it. +- **Keep Secrets Out of Deep Links**: Avoid transporting session tokens or other secrets in links; where unavoidable, make them single-use and short-lived. From 2e31f59332277e5fcc31e4f12bb0c6fffce74bbf Mon Sep 17 00:00:00 2001 From: TheDauntless Date: Wed, 29 Jul 2026 09:55:59 +0200 Subject: [PATCH 68/70] Split up 0078 --- weaknesses/MASVS-PRIVACY/MASWE-0078.md | 14 ++++---- weaknesses/MASVS-PRIVACY/MASWE-0079.md | 45 ++++++++++++++++++++++++++ 2 files changed, 51 insertions(+), 8 deletions(-) create mode 100644 weaknesses/MASVS-PRIVACY/MASWE-0079.md diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0078.md b/weaknesses/MASVS-PRIVACY/MASWE-0078.md index 6399d5d..5e07f29 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0078.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0078.md @@ -1,12 +1,12 @@ --- -title: Inadequate Awareness and Unsafe Defaults for Privacy Relevant Actions +title: Inadequate Awareness for Privacy Relevant Actions id: MASWE-0078 -alias: user-awareness-unsafe-defaults-privacy-actions -requirement: "Before completing a privacy relevant action, the app clearly communicates the affected data, destination, audience, and material privacy consequences, and defaults to the least exposing option appropriate for the requested functionality." +alias: inadequate-awareness-privacy-actions +requirement: "Before completing a privacy relevant action, the app clearly communicates the affected data, destination, audience, and material privacy consequences, and allows the user to review and control the resulting disclosure." platform: [android, ios] profiles: [P] threat: MAS-THREAT-0070 -attacks: [MAS-ATTACK-0084, MAS-ATTACK-0087] +attacks: [MAS-ATTACK-0084] mappings: masvs-v2: [MASVS-PRIVACY-2] cwe: [359] @@ -24,16 +24,15 @@ status: new ## Overview -This weakness occurs when an app performs a privacy relevant action without making its scope or material consequences reasonably apparent to the user, or when the app uses defaults that expose more data than is necessary for the expected functionality. +This weakness occurs when an app performs a privacy relevant action without making its scope or material consequences reasonably apparent to the user. Privacy relevant actions include sharing, exporting, publishing, synchronizing, backing up, changing visibility, responding to a request from another party, or moving data from private app storage to storage or services accessible by other applications, users, or third parties. -The weakness may cause users to disclose different data, disclose data to a broader audience, or create more persistent copies than they reasonably intended. It includes flows where the app honors another party's request for data without clearly showing the user what will be shared and with whom, or allowing the user to control the disclosure. It does not require the underlying processing to rely on consent. The issue is whether the interface and defaults allow the user to understand and control the resulting privacy state. +The weakness may cause users to disclose different data, disclose data to a broader audience, or create more persistent copies than they reasonably intended. It includes flows where the app honors another party's request for data without clearly showing the user what will be shared and with whom, or allowing the user to control the disclosure. It does not require the underlying processing to rely on consent. The issue is whether the interface allows the user to understand and control the resulting privacy state. ## Modes of Introduction - **Unclear Disclosure Context**: The interface or action labels do not clearly identify the affected records, files, accounts, data elements, included metadata, destination, audience, or resulting privacy state, including when responding to another party's request for data. -- **Overly Exposing Defaults**: The app preselects broader audiences, more data, longer retention, public visibility, or additional recipients when a less exposing default would satisfy the expected functionality. - **Insufficient Disclosure Review and Feedback**: The app does not allow the user to review, control, or confirm a consequential disclosure, or clearly indicate that a high impact or difficult to reverse disclosure has occurred. ## Impact @@ -45,5 +44,4 @@ The weakness may cause users to disclose different data, disclose data to a broa ## Mitigations - **Provide Clear Disclosure Context and Control**: At the point of action, show the affected data, included metadata, destination, audience, and material privacy consequences; before responding to another party's request for data, identify the requester and recipient and allow the user to approve, limit, or decline the disclosure. -- **Use Privacy Protective Defaults**: Default to the narrowest audience, smallest data set, shortest appropriate persistence, and least exposing destination that supports the requested functionality. - **Support Review and Reversal of Consequential Disclosures**: Before completion, allow users to review selected items, recipients, audience, included metadata, and visibility; make the resulting privacy state visible and provide proportionate confirmation or undo mechanisms when practical. diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0079.md b/weaknesses/MASVS-PRIVACY/MASWE-0079.md new file mode 100644 index 0000000..e3eee08 --- /dev/null +++ b/weaknesses/MASVS-PRIVACY/MASWE-0079.md @@ -0,0 +1,45 @@ +--- +title: Unsafe Defaults for Privacy Relevant Actions +id: MASWE-0079 +alias: unsafe-defaults-privacy-actions +requirement: "For privacy relevant actions, the app defaults to the least exposing option appropriate for the requested functionality." +platform: [android, ios] +profiles: [P] +threat: MAS-THREAT-0070 +attacks: [MAS-ATTACK-0084, MAS-ATTACK-0087] +mappings: + masvs-v2: [MASVS-PRIVACY-2] + cwe: [359] + maswe-beta: [MASWE-0109] +refs: +- https://cloud.google.com/sensitive-data-protection/docs/classification-redaction +- https://gdpr-info.eu/recitals/no-26/ +- https://gdpr-info.eu/recitals/no-28/ +- https://gdpr-info.eu/art-4-gdpr/ +- https://www.edpb.europa.eu/topics/ai-and-technology/anonymisation-pseudonymisation_en +- https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2014/wp216_en.pdf +- https://www.statista.com/topics/9460/app-tracking-and-mobile-privacy/ +status: new +--- + +## Overview + +This weakness occurs when an app uses defaults for a privacy relevant action that expose more data than is necessary for the expected functionality. + +Privacy relevant actions include sharing, exporting, publishing, synchronizing, backing up, changing visibility, responding to a request from another party, or moving data from private app storage to storage or services accessible by other applications, users, or third parties. + +The weakness may cause users to disclose different data, disclose data to a broader audience, or create more persistent copies than they reasonably intended. The issue is whether the default configuration results in a more exposing privacy state than is necessary for the requested functionality. + +## Modes of Introduction + +- **Overly Exposing Defaults**: The app preselects broader audiences, more data, longer retention, public visibility, or additional recipients when a less exposing default would satisfy the expected functionality. + +## Impact + +- **Violation of User Privacy**: The app can disclose personal or sensitive data to recipients who are not entitled to receive it under the user's sharing choices, resulting in unauthorized exposure of that data. +- **Loss of User Trust**: Users can discover that the app shared more data, or shared it more broadly, than they reasonably expected, resulting in reduced confidence in the app and its owner. +- **Legal and Regulatory Non-Compliance**: The app can share personal data using unnecessarily exposing defaults, resulting in violations of privacy obligations and potential enforcement action. + +## Mitigations + +- **Use Privacy Protective Defaults**: Default to the narrowest audience, smallest data set, shortest appropriate persistence, and least exposing destination that supports the requested functionality. From e570d471c41e68633d67ae3ae05013db5a5619ce Mon Sep 17 00:00:00 2001 From: TheDauntless Date: Wed, 29 Jul 2026 10:31:54 +0200 Subject: [PATCH 69/70] Rephrase --- weaknesses/MASVS-CODE/MASWE-0046.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/weaknesses/MASVS-CODE/MASWE-0046.md b/weaknesses/MASVS-CODE/MASWE-0046.md index 7a48fad..f91d936 100644 --- a/weaknesses/MASVS-CODE/MASWE-0046.md +++ b/weaknesses/MASVS-CODE/MASWE-0046.md @@ -23,7 +23,7 @@ status: new This weakness occurs when an app relies on deprecated APIs or functionality that are no longer maintained, may lack security fixes, or have been superseded by safer alternatives. -Platforms deprecate APIs for various reasons. It may be architectural changes, lack of developer adoption, reduced hardware support, or a better-designed replacement that fixes security shortcomings of the old API. Continuing to use deprecated security-relevant APIs can leave the app exposed to weaknesses the platform has already addressed. A representative example is the use of deprecated Android KeyStore implementations such as Bouncy Castle (BKS), but this weakness covers deprecated APIs and functionality in general, including cryptography, storage, networking, and platform features. +APIs may become deprecated for various reasons. This may be due to architectural changes, lack of developer adoption, reduced hardware support, or a better-designed replacement that addresses security shortcomings in the old API. Continuing to use deprecated security-relevant APIs can leave the app exposed to weaknesses that the platform has already addressed. A representative example is the use of deprecated Android KeyStore implementations such as Bouncy Castle (BKS), but this weakness covers deprecated APIs and functionality in general, including cryptography, storage, networking, and platform features. ## Modes of Introduction @@ -38,7 +38,7 @@ Platforms deprecate APIs for various reasons. It may be architectural changes, l ## Mitigations -- **Migrate Off Deprecated APIs**: Replace deprecated APIs with the platform's recommended alternatives as part of regular maintenance. Prioritize migration of security-relevant APIs. +- **Migrate Off Deprecated APIs**: Replace deprecated APIs with the platform's recommended alternatives as part of regular maintenance. Prioritize migration of security-relevant APIs. - **Treat Deprecation Warnings as Actionable**: Surface deprecation warnings in builds and reviews, and track migrations for security-relevant APIs with priority. -- **Follow Platform Release Notes**: Review each platform release's deprecation and behavior-change notes to plan migrations before old functionality is removed or breaks. -- **Test the App on All Supported Platforms**: Run the app on all platform API versions supported during development. +- **Follow Platform Release Notes**: Review each platform release's deprecation and behavior-change notes to plan migrations before old functionality is removed or breaks. +- **Test the App on All Supported Platforms**: Run the app on all platform API versions supported during development. From a1b9443bd7c143cf5ad30628538b017cab499126 Mon Sep 17 00:00:00 2001 From: Carlos Holguera Date: Thu, 30 Jul 2026 09:38:24 +0200 Subject: [PATCH 70/70] Apply suggestions from code review Co-authored-by: Carlos Holguera Co-authored-by: Jan Seredynski --- weaknesses/MASVS-PLATFORM/MASWE-0036.md | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0036.md b/weaknesses/MASVS-PLATFORM/MASWE-0036.md index 89eadde..23aae61 100644 --- a/weaknesses/MASVS-PLATFORM/MASWE-0036.md +++ b/weaknesses/MASVS-PLATFORM/MASWE-0036.md @@ -1,5 +1,5 @@ --- -title: Sensitive Functionality Exposed in WebViews +title: Sensitive Native Functionality Exposed in WebViews id: MASWE-0036 alias: js-bridges-webviews requirement: "The app does not expose sensitive native functionality to WebView content." @@ -17,20 +17,26 @@ mappings: maswe-beta: [MASWE-0068] refs: - https://support.google.com/faqs/answer/9095419 +- https://developer.android.com/develop/ui/views/layout/webapps/native-api-access-jsbridge +- https://developer.android.com/reference/androidx/webkit/WebViewCompat#addWebMessageListener(android.webkit.WebView,java.lang.String,java.util.Set%3Cjava.lang.String%3E,androidx.webkit.WebViewCompat.WebMessageListener) +- https://developer.apple.com/documentation/webkit/wkscriptmessagehandler status: new --- ## Overview -This weakness occurs when an app exposes sensitive native functionality to the web content rendered in its WebViews, most commonly through JavaScript bridges. +This weakness occurs when an app exposes sensitive native functionality to content loaded in its WebViews, most commonly through JavaScript bridges. -Bridges such as `addJavascriptInterface` on Android or script message handlers and JavaScript evaluation on iOS let web content invoke native code. When such bridges expose more capability than needed, or are reachable by untrusted content, malicious JavaScript can invoke native methods, access sensitive data, or perform privileged actions with the app's identity. +Bridges such as [`addWebMessageListener`](https://developer.android.com/reference/androidx/webkit/WebViewCompat#addWebMessageListener%28android.webkit.WebView,java.lang.String,java.util.Set%3Cjava.lang.String%3E,androidx.webkit.WebViewCompat.WebMessageListener%29) on Android and [`WKScriptMessageHandler`](https://developer.apple.com/documentation/webkit/wkscriptmessagehandler) on iOS allow web content to send messages to native code. When these bridges expose more capability than necessary, or are reachable by untrusted content, malicious JavaScript can invoke native functionality, access sensitive data, or perform privileged actions using the app's permissions and privileges. ## Modes of Introduction +- **Bridges Reachable by Untrusted Content**: Making bridge interfaces available to any page, origin, or frame the WebView loads instead of restricting them to trusted origins. +- **Unvalidated Bridge Messages**: Accepting message names, arguments, or payloads without validating their structure, types, values, authorization, and expected application state. +- **Globally Exposed Bridge Mechanisms**: Using bridge mechanisms that expose native interfaces broadly across the WebView, such as Android `addJavascriptInterface`, when origin-scoped messaging APIs are available. +- **App-Owned Bridge Scripts in the Page World**: Running injected bridge scripts in the same JavaScript execution world as page content, allowing page scripts, including third-party scripts, to access or interfere with the bridge. +- **Sensitive Data in Bridge Replies**: Returning sensitive data into the WebView JavaScript context in a way that any untrusted scripts can read, regardless of user authentication state. - **Over-Exposed Bridges**: Exposing more native functionality through the bridge than the web content actually needs. -- **Bridges Reachable by Untrusted Content**: Making bridge interfaces available to any page the WebView loads instead of restricting them to trusted origins. -- **Sensitive Data in Bridge Replies**: Returning sensitive data into the WebView's JavaScript context in a way that any content running in the page can read. ## Impact @@ -42,4 +48,5 @@ Bridges such as `addJavascriptInterface` on Android or script message handlers a - **Minimize the Bridge Surface**: Expose only the specific methods the web content needs, and strip bridges entirely from WebViews that do not need them. - **Restrict Bridges to Trusted Origins**: Attach bridges only when loading trusted content and prefer origin-scoped messaging mechanisms over global bridges. - **Validate Bridge Messages**: Treat every message arriving over the bridge as untrusted input and validate it before acting on it. -- **Return Data Through Scoped Replies**: Use reply mechanisms scoped to the calling message (e.g. script message handlers with replies) instead of injecting sensitive data into the page's global context. +- **Prefer Modern Messaging APIs**: On Android, prefer [`WebViewCompat.addWebMessageListener`](https://developer.android.com/reference/androidx/webkit/WebViewCompat#addWebMessageListener%28android.webkit.WebView,java.lang.String,java.util.Set,androidx.webkit.JavaScriptExecutionWorld,androidx.webkit.WebViewCompat.WebMessageListener%29) over the legacy [`WebView.addJavascriptInterface`](https://developer.android.com/reference/android/webkit/WebView#addJavascriptInterface%28java.lang.Object,java.lang.String%29). On iOS, use [`WKScriptMessageHandlerWithReply`](https://developer.apple.com/documentation/webkit/wkscriptmessagehandlerwithreply) when JavaScript requires a native response, and use [`WKScriptMessageHandler`](https://developer.apple.com/documentation/webkit/wkscriptmessagehandler) for one way messages. +- **Isolate App-Owned Bridge Scripts**: When the bridge is intended only for app-injected JavaScript, register the handler and injected script in a named execution world. Use [`JavaScriptExecutionWorld`](https://developer.android.com/reference/androidx/webkit/JavaScriptExecutionWorld) on Android and [`WKContentWorld`](https://developer.apple.com/documentation/webkit/wkcontentworld) on iOS, where supported. Keep origin restrictions, frame checks, and message validation in place, because execution world isolation is not origin authorization.