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: iOS Property List
Abstract
La información privada que está almacenada y no está protegida, como contraseñas en un archivo de texto sin cifrar, pone en peligro la seguridad del sistema.
Explanation
Las infracciones a la privacidad ocurren cuando la información privada del usuario se almacena en una ubicación desprotegida.
Ejemplo 1: El siguiente XML contiene información privada de un usuario dentro de un archivo Lista de propiedades. Entre otros valores que se almacenan, la clave
El código del
Los datos privados se pueden escribir en un programa de varias formas:
- Lo puede hacer directamente el usuario en forma de una contraseña o información personal.
- La aplicación accede a ellos desde una base de datos u otro almacén de datos
- Lo puede hacer indirectamente un asociado u otro tercero.
- Se pueden recuperar de almacenes de datos móviles, por ejemplo: libreta de direcciones, fotos tomadas, geolocalización, archivos de configuración (incluido plist), mensajes SMS archivados, etc.
En ocasiones, 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 no se suelen considerar privados, ya que no hay ninguna asignación explícita y disponible públicamente a la información personal de un alumno. Sin embargo, si una escuela genera números de identificación basados en los números de seguridad social de los alumnos, los números de identificación se deberán considerar privados.
A menudo, las preocupaciones de seguridad y privacidad parecen competir 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 suponer riesgos adicionales.
Si bien existen muchas maneras de administrar los datos privados de forma no segura, un riesgo común procede 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, creen que es aceptable almacenar información privada en el sistema de archivos, en el registro dentro de archivos Lista de propiedades o en otros recursos controlados localmente. Sin embargo, incluso si el acceso a ciertos recursos está restringido, no garantiza que se puedan confiar los 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 (Gramm-Leach Bliley Act, GLBA) [4]
- Ley de transferencia y responsabilidad de seguros de salud (HIPAA) [5]
- California SB-1386 [6]
A pesar de estas regulaciones, se siguen produciendo infracciones de privacidad con alarmante frecuencia.
Ejemplo 1: El siguiente XML contiene información privada de un usuario dentro de un archivo Lista de propiedades. Entre otros valores que se almacenan, la clave
MyCreditCard
almacena un número de tarjeta de crédito en texto sin cifrar que ha suministrado el usuario asociado a la cuenta.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>password</key>
<string>BASICSECRET</string>
<key>credentials</key>
<dict>
<key>pin</key>
<string>2345</string>
<key>MyCreditCard</key>
<string>1111 11 2321 1112</string>
<key>MysSn</key>
<string>1111-22-3333</string>
<key>ssn</key>
<string>2345-22-3345</string>
<key>userid</key>
<string>12345</string>
</dict>
</dict>
</plist>
El código del
Example 1
almacena información de usuario privada del dispositivo móvil en un archivo Lista de propiedades desprotegido almacenado en el dispositivo. Aunque muchos desarrolladores confían en los archivos Lista de propiedades como ubicaciones de almacenamiento seguro para cualquier dato y para todos los datos, no se debería depender implícitamente de ellos, en concreto cuando la privacidad del sistema es una preocupación, ya que estos archivos los puede leer cualquiera que esté en posesión del dispositivo.Los datos privados se pueden escribir en un programa de varias formas:
- Lo puede hacer directamente el usuario en forma de una contraseña o información personal.
- La aplicación accede a ellos desde una base de datos u otro almacén de datos
- Lo puede hacer indirectamente un asociado u otro tercero.
- Se pueden recuperar de almacenes de datos móviles, por ejemplo: libreta de direcciones, fotos tomadas, geolocalización, archivos de configuración (incluido plist), mensajes SMS archivados, etc.
En ocasiones, 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 no se suelen considerar privados, ya que no hay ninguna asignación explícita y disponible públicamente a la información personal de un alumno. Sin embargo, si una escuela genera números de identificación basados en los números de seguridad social de los alumnos, los números de identificación se deberán considerar privados.
A menudo, las preocupaciones de seguridad y privacidad parecen competir 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 suponer riesgos adicionales.
Si bien existen muchas maneras de administrar los datos privados de forma no segura, un riesgo común procede 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, creen que es aceptable almacenar información privada en el sistema de archivos, en el registro dentro de archivos Lista de propiedades o en otros recursos controlados localmente. Sin embargo, incluso si el acceso a ciertos recursos está restringido, no garantiza que se puedan confiar los 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 (Gramm-Leach Bliley Act, GLBA) [4]
- Ley de transferencia y responsabilidad de seguros de salud (HIPAA) [5]
- California SB-1386 [6]
A pesar de estas regulaciones, se siguen produciendo infracciones de privacidad con alarmante frecuencia.
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] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
[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 - Common Weakness Enumeration Top 25 2024 [17] CWE ID 200
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000196, CCI-004062
[14] Standards Mapping - General Data Protection Regulation (GDPR) Privacy Violation
[15] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1), IA-5 Authenticator Management (P1)
[16] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement, IA-5 Authenticator Management
[17] 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)
[18] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[19] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[20] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[21] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[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 A02 Cryptographic Failures
[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 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 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 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 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 8.3.1
[33] 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
[34] 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
[35] 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
[36] 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
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3310 CAT I, APP3340 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3340 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3340 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3340 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3340 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3340 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3340 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001740 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001740 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001740 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001740 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001740 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001740 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001740 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001740 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001740 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001740 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001740 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001740 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001740 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001740 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-001740 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[60] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.config.objc.privacy_violation_ios_property_list