Reino: Security Features
La seguridad de un software no es un software de seguridad. Nos preocupamos de cuestiones como la autenticación, el control de acceso, la confidencialidad, la criptografía y la gestión de privilegios.
Privacy Violation: Screen Caching
Abstract
De forma automática, iOS tomará una captura de pantalla antes de que una aplicación pase a segundo plano (es decir, al presionar el botón de "Inicio" cuando la aplicación está activa). Si hay información confidencial en pantalla cuando esto ocurre, se puede poner en riesgo la privacidad del usuario.
Explanation
La subclase UIViewController identificada no implementa los métodos adecuados que se utilizan para ocultar los elementos de la pantalla antes de que iOS almacene en caché el contenido de la pantalla. Por tanto, se revela información confidencial introducida en los controles de entrada antes de que una aplicación pase a segundo plano.
Ejemplo 1: la entrada especificada en los controles de texto de iOS puede almacenarse en una captura de pantalla que se toma cuando una aplicación pasa a segundo plano (es decir, el botón "Inicio" se presiona mientras la aplicación está activa).
El código del
Los datos privados se pueden escribir en un programa de varias formas:
- Directamente desde el usuario en forma de una contraseña o información personal.
- La aplicación accede desde una base de datos u otro almacén de datos.
- Indirectamente desde un asociado de negocios u otra tercera parte.
- Obtenido de almacenes de datos móviles entre los que se incluyen: libreta de direcciones, fotos tomadas, ubicación geográfica, archivos de configuración, mensajes SMS archivados, etc.
A veces los datos que no están etiquetados como privados pueden tener una implicación de privacidad en un contexto diferente. Por ejemplo, los números de identificación de alumnos generalmente no se consideran privados porque no hay ninguna asignación explícita y disponible públicamente a la información personal de un alumno. Sin embargo, si un centro educativo genera identificaciones de estudiantes según sus números de la seguridad social, los números de identificación deben considerarse privados.
Las preocupaciones de seguridad y privacidad a menudo parece que compiten entre sí. Desde una perspectiva de seguridad, debería registrar todas las operaciones importantes de modo que posteriormente se pueda identificar cualquier actividad anómala. Sin embargo, cuando se trata de datos privados, esta práctica puede crear riesgos adicionales.
Aunque hay muchas maneras de tratar los datos privados de forma no segura, un riesgo común se deriva de la confianza mal depositada. Los programadores a menudo confían en el entorno operativo en el que se ejecuta un programa, y por lo tanto, creemos que es aceptable para almacenar información privada en el sistema de archivos, en el registro o en otros recursos controlados localmente. No obstante, incluso si el acceso a ciertos recursos está restringido, esto no garantiza que se puedan confiar ciertos datos a las personas con acceso. Por ejemplo, en el año 2004, un empleado sin escrúpulos de AOL vendió aproximadamente 92 millones de direcciones de correo electrónico privadas de los clientes a un remitente de marketing de correo electrónico no deseado, un sitio web de juegos de azar ubicado en el extranjero [1].
En respuesta a dichos ataques de alto perfil, la recopilación y gestión de datos privados se está convirtiendo en algo cada vez más regulado. Dependiendo de su ubicación, el tipo de negocio que desarrolle y la naturaleza de los datos privados que controle, una organización puede verse obligada a cumplir uno o varios de los siguientes reglamentos federales y estatales:
- Marco de privacidad de Safe Harbor [3]
- Ley Gramm-Leach Bliley (GLBA) [4]
- Ley de portabilidad y responsabilidad de seguros médicos (Health Insurance Portability and Accountability Act, HIPAA) [5]
- California SB-1386 [6]
A pesar de estas regulaciones, se siguen produciendo con alarmante frecuencia violaciones de la privacidad.
Ejemplo 1: la entrada especificada en los controles de texto de iOS puede almacenarse en una captura de pantalla que se toma cuando una aplicación pasa a segundo plano (es decir, el botón "Inicio" se presiona mientras la aplicación está activa).
ViewController.h
...
@property (nonatomic, retain) IBOutlet UITextField *ssnField;
...
El código del
Example 1 indica que la aplicación utiliza un control de entrada diseñado para recopilar información confidencial. Cuando iOS realiza una captura de pantalla de la vista activa de una aplicación al pasar a segundo plano para mejorar el rendimiento de la animación, la información que se muestra en tales controles de entrada durante el evento de segundo plano se puede almacenar en caché en una imagen que se guarda en el sistema de archivos. Debido a que las capturas de caché de pantalla se almacenan en el dispositivo, estas capturas de pantalla se puede recuperar si se extravía el dispositivo, lo cual revela la información confidencial que contiene.Los datos privados se pueden escribir en un programa de varias formas:
- Directamente desde el usuario en forma de una contraseña o información personal.
- La aplicación accede desde una base de datos u otro almacén de datos.
- Indirectamente desde un asociado de negocios u otra tercera parte.
- Obtenido de almacenes de datos móviles entre los que se incluyen: libreta de direcciones, fotos tomadas, ubicación geográfica, archivos de configuración, mensajes SMS archivados, etc.
A veces los datos que no están etiquetados como privados pueden tener una implicación de privacidad en un contexto diferente. Por ejemplo, los números de identificación de alumnos generalmente no se consideran privados porque no hay ninguna asignación explícita y disponible públicamente a la información personal de un alumno. Sin embargo, si un centro educativo genera identificaciones de estudiantes según sus números de la seguridad social, los números de identificación deben considerarse privados.
Las preocupaciones de seguridad y privacidad a menudo parece que compiten entre sí. Desde una perspectiva de seguridad, debería registrar todas las operaciones importantes de modo que posteriormente se pueda identificar cualquier actividad anómala. Sin embargo, cuando se trata de datos privados, esta práctica puede crear riesgos adicionales.
Aunque hay muchas maneras de tratar los datos privados de forma no segura, un riesgo común se deriva de la confianza mal depositada. Los programadores a menudo confían en el entorno operativo en el que se ejecuta un programa, y por lo tanto, creemos que es aceptable para almacenar información privada en el sistema de archivos, en el registro o en otros recursos controlados localmente. No obstante, incluso si el acceso a ciertos recursos está restringido, esto no garantiza que se puedan confiar ciertos datos a las personas con acceso. Por ejemplo, en el año 2004, un empleado sin escrúpulos de AOL vendió aproximadamente 92 millones de direcciones de correo electrónico privadas de los clientes a un remitente de marketing de correo electrónico no deseado, un sitio web de juegos de azar ubicado en el extranjero [1].
En respuesta a dichos ataques de alto perfil, la recopilación y gestión de datos privados se está convirtiendo en algo cada vez más regulado. Dependiendo de su ubicación, el tipo de negocio que desarrolle y la naturaleza de los datos privados que controle, una organización puede verse obligada a cumplir uno o varios de los siguientes reglamentos federales y estatales:
- Marco de privacidad de Safe Harbor [3]
- Ley Gramm-Leach Bliley (GLBA) [4]
- Ley de portabilidad y responsabilidad de seguros médicos (Health Insurance Portability and Accountability Act, HIPAA) [5]
- California SB-1386 [6]
A pesar de estas regulaciones, se siguen produciendo con alarmante frecuencia violaciones de la privacidad.
References
[1] J. Oates AOL man pleads guilty to selling 92m email addies The Register
[2] Privacy Initiatives U.S. Federal Trade Commission
[3] Safe Harbor Privacy Framework U.S. Department of Commerce
[4] Financial Privacy: The Gramm-Leach Bliley Act (GLBA) Federal Trade Commission
[5] Health Insurance Portability and Accountability Act (HIPAA) U.S. Department of Human Services
[6] California SB-1386 Government of the State of California
[7] Standards Mapping - Common Weakness Enumeration 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 - Common Weakness Enumeration Top 25 2024 [17] CWE ID 200
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000196, CCI-001090
[13] Standards Mapping - General Data Protection Regulation (GDPR) Privacy Violation
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1), IA-5 Authenticator Management (P1), SC-4 Information in Shared Resources (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement, IA-5 Authenticator Management, SC-4 Information in Shared System Resources
[16] 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)
[17] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[18] Standards Mapping - OWASP Mobile 2024 M6 Inadequate Privacy Controls
[19] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-2
[20] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[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 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 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 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 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 8.3.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.1, Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 4.2.2, 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, Control Objective 7 - Use of Cryptography
[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 7 - Use of Cryptography
[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 7 - Use of Cryptography
[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.2 APSC-DV-001740 CAT I, APSC-DV-002380 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001740 CAT I, APSC-DV-002380 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001740 CAT I, APSC-DV-002380 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001740 CAT I, APSC-DV-002380 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001740 CAT I, APSC-DV-002380 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001740 CAT I, APSC-DV-002380 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001740 CAT I, APSC-DV-002380 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001740 CAT I, APSC-DV-002380 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001740 CAT I, APSC-DV-002380 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001740 CAT I, APSC-DV-002380 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001740 CAT I, APSC-DV-002380 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001740 CAT I, APSC-DV-002380 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001740 CAT I, APSC-DV-002380 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001740 CAT I, APSC-DV-002380 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-001740 CAT I, APSC-DV-002380 CAT II
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[59] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.structural.objc.privacy_violation_screen_caching
Abstract
De forma automática, iOS tomará una captura de pantalla antes de que una aplicación pase a segundo plano (es decir, al presionar el botón de "Inicio" cuando la aplicación está activa). Si hay información confidencial en pantalla cuando esto ocurre, se puede poner en riesgo la privacidad del usuario.
Explanation
La subclase UIViewController identificada no implementa los métodos adecuados que se utilizan para ocultar los elementos de la pantalla antes de que iOS almacene en caché el contenido de la pantalla. Por tanto, se revela información confidencial introducida en los controles de entrada antes de que una aplicación pase a segundo plano.
Ejemplo 1: la entrada especificada en los controles de texto de iOS puede almacenarse en una captura de pantalla que se toma cuando una aplicación pasa a segundo plano (es decir, el botón "Inicio" se presiona mientras la aplicación está activa).
El código del
Los datos privados se pueden escribir en un programa de varias formas:
- Directamente desde el usuario en forma de una contraseña o información personal.
- La aplicación accede desde una base de datos u otro almacén de datos.
- Indirectamente desde un asociado de negocios u otra tercera parte.
- Obtenido de almacenes de datos móviles entre los que se incluyen: libreta de direcciones, fotos tomadas, ubicación geográfica, archivos de configuración, mensajes SMS archivados, etc.
A veces los datos que no están etiquetados como privados pueden tener una implicación de privacidad en un contexto diferente. Por ejemplo, los números de identificación de alumnos generalmente no se consideran privados porque no hay ninguna asignación explícita y disponible públicamente a la información personal de un alumno. Sin embargo, si un centro educativo genera identificaciones de estudiantes según sus números de la seguridad social, los números de identificación deben considerarse privados.
Las preocupaciones de seguridad y privacidad a menudo parece que compiten entre sí. Desde una perspectiva de seguridad, debería registrar todas las operaciones importantes de modo que posteriormente se pueda identificar cualquier actividad anómala. Sin embargo, cuando se trata de datos privados, esta práctica puede crear riesgos adicionales.
Aunque hay muchas maneras de tratar los datos privados de forma no segura, un riesgo común se deriva de la confianza mal depositada. Los programadores a menudo confían en el entorno operativo en el que se ejecuta un programa, y por lo tanto, creemos que es aceptable para almacenar información privada en el sistema de archivos, en el registro o en otros recursos controlados localmente. No obstante, incluso si el acceso a ciertos recursos está restringido, esto no garantiza que se puedan confiar ciertos datos a las personas con acceso. Por ejemplo, en el año 2004, un empleado sin escrúpulos de AOL vendió aproximadamente 92 millones de direcciones de correo electrónico privadas de los clientes a un remitente de marketing de correo electrónico no deseado, un sitio web de juegos de azar ubicado en el extranjero [1].
En respuesta a dichos ataques de alto perfil, la recopilación y gestión de datos privados se está convirtiendo en algo cada vez más regulado. Dependiendo de su ubicación, el tipo de negocio que desarrolle y la naturaleza de los datos privados que controle, una organización puede verse obligada a cumplir uno o varios de los siguientes reglamentos federales y estatales:
- Marco de privacidad de Safe Harbor [3]
- Ley Gramm-Leach Bliley (GLBA) [4]
- Ley de portabilidad y responsabilidad de seguros médicos (Health Insurance Portability and Accountability Act, HIPAA) [5]
- California SB-1386 [6]
A pesar de estas regulaciones, se siguen produciendo con alarmante frecuencia violaciones de la privacidad.
Ejemplo 1: la entrada especificada en los controles de texto de iOS puede almacenarse en una captura de pantalla que se toma cuando una aplicación pasa a segundo plano (es decir, el botón "Inicio" se presiona mientras la aplicación está activa).
...
@IBOutlet weak var ssnField: UITextField!
...
El código del
Example 1 indica que la aplicación utiliza un control de entrada diseñado para recopilar información confidencial. Cuando iOS realiza una captura de pantalla de la vista activa de una aplicación al pasar a segundo plano para mejorar el rendimiento de la animación, la información que se muestra en tales controles de entrada durante el evento de segundo plano se puede almacenar en caché en una imagen que se guarda en el sistema de archivos. Debido a que las capturas de caché de pantalla se almacenan en el dispositivo, estas capturas de pantalla se puede recuperar si se extravía el dispositivo, lo cual revela la información confidencial que contiene.Los datos privados se pueden escribir en un programa de varias formas:
- Directamente desde el usuario en forma de una contraseña o información personal.
- La aplicación accede desde una base de datos u otro almacén de datos.
- Indirectamente desde un asociado de negocios u otra tercera parte.
- Obtenido de almacenes de datos móviles entre los que se incluyen: libreta de direcciones, fotos tomadas, ubicación geográfica, archivos de configuración, mensajes SMS archivados, etc.
A veces los datos que no están etiquetados como privados pueden tener una implicación de privacidad en un contexto diferente. Por ejemplo, los números de identificación de alumnos generalmente no se consideran privados porque no hay ninguna asignación explícita y disponible públicamente a la información personal de un alumno. Sin embargo, si un centro educativo genera identificaciones de estudiantes según sus números de la seguridad social, los números de identificación deben considerarse privados.
Las preocupaciones de seguridad y privacidad a menudo parece que compiten entre sí. Desde una perspectiva de seguridad, debería registrar todas las operaciones importantes de modo que posteriormente se pueda identificar cualquier actividad anómala. Sin embargo, cuando se trata de datos privados, esta práctica puede crear riesgos adicionales.
Aunque hay muchas maneras de tratar los datos privados de forma no segura, un riesgo común se deriva de la confianza mal depositada. Los programadores a menudo confían en el entorno operativo en el que se ejecuta un programa, y por lo tanto, creemos que es aceptable para almacenar información privada en el sistema de archivos, en el registro o en otros recursos controlados localmente. No obstante, incluso si el acceso a ciertos recursos está restringido, esto no garantiza que se puedan confiar ciertos datos a las personas con acceso. Por ejemplo, en el año 2004, un empleado sin escrúpulos de AOL vendió aproximadamente 92 millones de direcciones de correo electrónico privadas de los clientes a un remitente de marketing de correo electrónico no deseado, un sitio web de juegos de azar ubicado en el extranjero [1].
En respuesta a dichos ataques de alto perfil, la recopilación y gestión de datos privados se está convirtiendo en algo cada vez más regulado. Dependiendo de su ubicación, el tipo de negocio que desarrolle y la naturaleza de los datos privados que controle, una organización puede verse obligada a cumplir uno o varios de los siguientes reglamentos federales y estatales:
- Marco de privacidad de Safe Harbor [3]
- Ley Gramm-Leach Bliley (GLBA) [4]
- Ley de portabilidad y responsabilidad de seguros médicos (Health Insurance Portability and Accountability Act, HIPAA) [5]
- California SB-1386 [6]
A pesar de estas regulaciones, se siguen produciendo con alarmante frecuencia violaciones de la privacidad.
References
[1] J. Oates AOL man pleads guilty to selling 92m email addies The Register
[2] Privacy Initiatives U.S. Federal Trade Commission
[3] Safe Harbor Privacy Framework U.S. Department of Commerce
[4] Financial Privacy: The Gramm-Leach Bliley Act (GLBA) Federal Trade Commission
[5] Health Insurance Portability and Accountability Act (HIPAA) U.S. Department of Human Services
[6] California SB-1386 Government of the State of California
[7] Standards Mapping - Common Weakness Enumeration 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 - Common Weakness Enumeration Top 25 2024 [17] CWE ID 200
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000196, CCI-001090
[13] Standards Mapping - General Data Protection Regulation (GDPR) Privacy Violation
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1), IA-5 Authenticator Management (P1), SC-4 Information in Shared Resources (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement, IA-5 Authenticator Management, SC-4 Information in Shared System Resources
[16] 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)
[17] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[18] Standards Mapping - OWASP Mobile 2024 M6 Inadequate Privacy Controls
[19] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-2
[20] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[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 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 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 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 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 8.3.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.1, Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 4.2.2, 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, Control Objective 7 - Use of Cryptography
[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 7 - Use of Cryptography
[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 7 - Use of Cryptography
[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.2 APSC-DV-001740 CAT I, APSC-DV-002380 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001740 CAT I, APSC-DV-002380 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001740 CAT I, APSC-DV-002380 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001740 CAT I, APSC-DV-002380 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001740 CAT I, APSC-DV-002380 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001740 CAT I, APSC-DV-002380 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001740 CAT I, APSC-DV-002380 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001740 CAT I, APSC-DV-002380 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001740 CAT I, APSC-DV-002380 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001740 CAT I, APSC-DV-002380 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001740 CAT I, APSC-DV-002380 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001740 CAT I, APSC-DV-002380 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001740 CAT I, APSC-DV-002380 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001740 CAT I, APSC-DV-002380 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-001740 CAT I, APSC-DV-002380 CAT II
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[59] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.structural.swift.privacy_violation_screen_caching