Se producen infracciones de privacidad cuando:

1. La información privada del usuario entra en el programa.
2. Los datos se escriben en una ubicación externa, como la consola, el sistema de archivos o la red.

Ejemplo 1: El siguiente código vulnerable contiene una declaración de configuración que permite que el secreto "admin_password" se registre sin ofuscar.

from oslo_config import cfg
 ...
opts = [
  cfg.StrOpt('admin_password',secret=False,
               help="User's password")]
 ...              
grp = cfg.OptGroup('mygroup')
cfg.CONF.register_opts(opts, group=grp)
 ...
logger.warning("Adding %s" % cfg.CONF.mygroup.admin_password)

El código en Example 1 escribe admin_password en texto sin formato (sin ofuscar) en la salida del registro, ya que el valor de secret se establece en False. Aunque muchos desarrolladores confían en el registro de eventos como una ubicación segura de almacenamiento para los datos, el usuario no debería confiar absolutamente, en especial, cuando la privacidad es una preocupación.

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

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 crear riesgos.

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, creemos que es aceptable para almacenar información privada en el sistema de archivos, en el registro o en otros recursos controlados localmente. Sin embargo, incluso si se restringe el acceso a determinados recursos, esto no garantiza que se pueda confiar en las personas que tienen 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.

Los atacantes pueden explotar las vulnerabilidades no comprobadas de la siguiente forma:

1. Los datos entran en la aplicación desde una fuente no confiable.

2. Los datos se utilizan para representar el identificador de grupo o usuario, la lista de permisos o el recurso al que se ha aplicado el permiso sin someterse a comprobaciones de integridad previas. A continuación, la aplicación utiliza los datos no comprobados para editar la configuración de permisos.

Este premiso tiene un nivel de protección "peligroso". Los permisos clasificados como peligrosos implican un riesgo adicional para la privacidad de datos del usuario o para el uso del dispositivo. En este caso, el acceso a la información sobre la actividad física puede suponer un riesgo para la privacidad del usuario y la seguridad personal. Las aplicaciones que requieren el acceso a la información de la actividad física del usuario tienen que gestionarse con el mayor nivel de precaución.

Ejemplo 1: El elemento <uses-permission .../> de AndroidManifest.xml declara el uso del permiso de ACTIVITY_RECOGNITION, que permite a una aplicación introducir reconocer la actividad física del usuario.

 <uses-permission android:name="android.permission.ACTIVITY_RECOGNITION"/> 

Este premiso tiene un nivel de protección "peligroso". Los permisos clasificados como peligrosos implican un riesgo adicional para la privacidad de datos del usuario o para el uso del dispositivo. En este caso, el acceso al calendario del usuario puede suponer un riesgo para la privacidad del usuario y la seguridad personal. Las aplicaciones tienen que tratar los datos del calendario como información confidencial y gestionarlos con el mayor nivel de precaución para mantener la privacidad.

Ejemplo 1: El elemento <uses-permission .../> de AndroidManifest.xml declara el uso del permiso de READ_CALENDAR, que permite a una aplicación leer los datos del calendario del usuario.

 <uses-permission android:name="android.permission.READ_CALENDAR"/> 

Ejemplo 2: El elemento <uses-permission .../> de AndroidManifest.xml declara el uso del permiso de WRITE_CALENDAR, que permite a una aplicación introducir datos en los datos del calendario del usuario.

 <uses-permission android:name="android.permission.WRITE_CALENDAR"/> 

Este premiso tiene un nivel de protección "peligroso". Los permisos clasificados como peligrosos implican un riesgo adicional para la privacidad de datos del usuario o para el uso del dispositivo. En este caso, el acceso al registro de llamadas puede suponer un riesgo para la privacidad del usuario y la seguridad personal. Las aplicaciones que requieren el acceso al registro de llamadas tienen que gestionarse con el mayor nivel de precaución.

Ejemplo 1: El elemento <uses-permission .../> de AndroidManifest.xml declara el uso del permiso de READ_CALL_LOG, que permite a una aplicación leer el registro de llamadas del usuario.

 <uses-permission android:name="android.permission.READ_CALL_LOG"/> 

Ejemplo 2: El elemento <uses-permission .../> de AndroidManifest.xml declara el uso del permiso de WRITE_CALL_LOG, que permite a una aplicación introducir datos en el registro de llamadas del usuario.

 <uses-permission android:name="android.permission.WRITE_CALL_LOG"/> 

Este premiso tiene un nivel de protección "peligroso". Los permisos clasificados como peligrosos implican un riesgo adicional para la privacidad de datos del usuario o para el uso del dispositivo. En este caso, el acceso a la cámara puede suponer un riesgo para la privacidad del usuario y la seguridad personal. Las aplicaciones que requieren el acceso a la cámara tienen que gestionarse con el mayor nivel de precaución.

Ejemplo 1: El elemento <uses-permission .../> de AndroidManifest.xml declara el uso del permiso de CAMERA, que permite a una aplicación acceder a la cámara del dispositivo.

 <uses-permission android:name="android.permission.CAMERA"/> 

Este premiso tiene un nivel de protección "peligroso". Los permisos clasificados como peligrosos implican un riesgo adicional para la privacidad de datos del usuario o para el uso del dispositivo. En este caso, el acceso a la información de los contactos puede suponer un riesgo para la privacidad del usuario y la seguridad personal. Las aplicaciones tienen que tratar los datos de los contactos como información confidencial y gestionarlos con el mayor nivel de precaución.

Ejemplo 1: El elemento <uses-permission .../> de AndroidManifest.xml declara el uso del permiso de READ_CONTACTS, que permite a una aplicación leer los datos de los contactos del usuario.

 <uses-permission android:name="android.permission.READ_CONTACTS"/> 

Ejemplo 2: El elemento <uses-permission .../> de AndroidManifest.xml declara el uso del permiso de WRITE_CONTACTS, que permite a una aplicación introducir datos en los datos de los contactos del usuario.

 <uses-permission android:name="android.permission.WRITE_CONTACTS"/> 

Ejemplo 3: El elemento <uses-permission .../> de AndroidManifest.xml declara el uso del permiso de GET_ACCOUNTS, que permite a una aplicación acceder al correo electrónico del usuario y a las cuentas en línea almacenadas en el Gestor de cuentas. Con este permiso se puede acceder a datos confidenciales, como identificadores de cuentas, direcciones de correo electrónico y números de teléfono.

 <uses-permission android:name="android.permission.GET_ACCOUNTS"/> 

Los archivos escritos en almacenamiento externo son legibles y los programas y usuarios arbitrarios pueden escribir en ellos. Los programas nunca deben escribir información confidencial en un almacenamiento externo; por ejemplo, información de identificación personal. Cuando conecta el dispositivo Android a través de USB a un PC u otro dispositivo, se habilita el modo de almacenamiento masivo USB. Cualquier archivo escrito en un almacenamiento externo se puede leer y modificar en este modo. Además, los archivos del almacenamiento externo permanecerán allí incluso después de que se desinstale la aplicación que los escribió, lo que aumenta aún más el riesgo de que cualquier información confidencial almacenada en ellos se vea comprometida.

Ejemplo 1:El elemento <uses-permission .../> de AndroidManifest.xml declara el uso del permiso de WRITE_EXTERNAL_STORAGE, que permite a una aplicación introducir datos en un almacenamiento externo.

 <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/> 

Ejemplo 2: El elemento <uses-permission .../> de AndroidManifest.xml declara el uso del permiso de READ_EXTERNAL_STORAGE, que permite a una aplicación leer en un almacenamiento externo.

 <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE"/> 

No hay una buena razón para solicitar u otorgar un permiso que desconecte el dispositivo.

Ejemplo 1: Un programa no debe solicitar este permiso. Nunca.

 <uses-permission android:name="android.permission.BRICK"/> 

El acceso a la información de localización GPS puede comprometer la seguridad personal y la privacidad de un usuario. Los programas que acceden a la información de ubicación GPS deben tener cuidado y administrar esta información con la máxima precaución.

Ejemplo: el siguiente código solicita la recepción de actualizaciones a los cambios de la ubicación del teléfono.

lm.requestLocationUpdates(LocationManager.GPS_PROVIDER, 1000, 0, locationListener);

Las operaciones de SMS no deben realizarse sin una causa o consideración. El software malintencionado explota estas API para robar dinero y datos a usuarios incautos.

Ejemplo: en este caso, el programa envía un mensaje SMS basado en texto.

sms.sendTextMessage(recipient, null, message, PendingIntent.getBroadcast(SmsMessaging.this, 0, new Intent(ACTION_SMS_SENT), 0), null);

Este premiso tiene un nivel de protección "peligroso". Los permisos clasificados como peligrosos implican un riesgo adicional para la privacidad de datos del usuario o para el uso del dispositivo. En este caso, el acceso al micrófono del dispositivo puede suponer un riesgo para la privacidad del usuario y la seguridad personal. Las aplicaciones que requieren el acceso al micrófono tienen que gestionarse con el mayor nivel de precaución.

Ejemplo 1: El elemento <uses-permission .../> de AndroidManifest.xml declara el uso del permiso de RECORD_AUDIO, que permite a una aplicación grabar audios utilizando el micrófono del dispositivo.

 <uses-permission android:name="android.permission.RECORD_AUDIO"/> 

Este premiso tiene un nivel de protección "peligroso". Los permisos clasificados como peligrosos implican un riesgo adicional para la privacidad de datos del usuario o para el uso del dispositivo. En este caso, el acceso a dispositivos cercanos mediante Bluetooth representa un peligro para la privacidad y la seguridad personal del usuario, ya que los actores maliciosos pueden usar la funcionalidad Bluetooth para conocer la ubicación del dispositivo o explotar vulnerabilidades para espiar y recopilar datos. Las aplicaciones que requieren el acceso Bluetooth a dispositivos cercanos tienen que gestionarse con el mayor nivel de precaución.

Ejemplo 1: El elemento <uses-permission .../> de AndroidManifest.xml declara el uso del permiso BLUETOOTH_ADVERTISE, que permite que una aplicación se anuncie en dispositivos Bluetooth cercanos.

 <uses-permission android:name="android.permission.BLUETOOTH_ADVERTISE"/> 

Este premiso tiene un nivel de protección "peligroso". Los permisos clasificados como peligrosos implican un riesgo adicional para la privacidad de datos del usuario o para el uso del dispositivo. En este caso, el acceso a las notificaciones puede suponer un peligro para la privacidad y la seguridad personal del usuario si se incluye información sensible en las notificaciones enviadas. Las aplicaciones que requieren acceso para enviar notificaciones deben administrarlo con la máxima precaución y tomar precauciones para evitar la fuga de datos confidenciales en los mensajes de notificación.

Ejemplo 1: El elemento <uses-permission .../> de AndroidManifest.xml declara el uso del permiso POST_NOTIFICATIONS, que permite que una aplicación envíe notificaciones al usuario del dispositivo.

 <uses-permission android:name="android.permission.POST_NOTIFICATIONS"/> 

Este premiso tiene un nivel de protección "peligroso". Los permisos clasificados como peligrosos implican un riesgo adicional para la privacidad de datos del usuario o para el uso del dispositivo. En este caso, el acceso a los archivos de audio puede suponer un riesgo para la privacidad y la seguridad personal del usuario. Las aplicaciones que requieren el acceso a los archivos de audio tienen que gestionarse con el mayor nivel de precaución.

Ejemplo 1: El elemento <uses-permission .../> de AndroidManifest.xml declara el uso del permiso READ_MEDIA_AUDIO, que permite que una aplicación lea archivos de música y audio en el dispositivo.

 <uses-permission android:name="android.permission.READ_MEDIA_AUDIO"/> 

Este premiso tiene un nivel de protección "peligroso". Los permisos clasificados como peligrosos implican un riesgo adicional para la privacidad de datos del usuario o para el uso del dispositivo. En este caso, el acceso a las fotos y los vídeos puede suponer un riesgo para la privacidad y la seguridad personal del usuario. Las aplicaciones que requieren el acceso a las fotos y los vídeos tienen que gestionarse con el mayor nivel de precaución.

Ejemplo 1: El elemento <uses-permission .../> de AndroidManifest.xml declara el uso del permiso READ_MEDIA_VIDEO, que permite que una aplicación lea archivos de vídeo en el dispositivo.

 <uses-permission android:name="android.permission.READ_MEDIA_VIDEO"/> 

Las operaciones de grabación de audio no deben realizarse sin una causa o consideración. El software malintencionado explota estas API para robar dinero y datos a usuarios incautos.

Este premiso tiene un nivel de protección "peligroso". Los permisos clasificados como peligrosos implican un riesgo adicional para la privacidad de datos del usuario o para el uso del dispositivo. En este caso, el acceso a los sensores corporales puede suponer un riesgo para la privacidad del usuario y la seguridad personal. Las aplicaciones que requieren el acceso a los sensores corporales tienen que gestionarse con el mayor nivel de precaución.

Ejemplo 1: El elemento <uses-permission .../> de AndroidManifest.xml declara el uso del permiso de BODY_SENSORS, que permite a una aplicación acceder a los datos de los sensores corporales o medioambientales en el dispositivo o a los elementos conectados al mismo.

 <uses-permission android:name="android.permission.BODY_SENSORS"/> 

Las operaciones relacionadas con la realización y la recepción de llamadas telefónicas no deben llevarse a cabo sin una causa o consideración. El software malintencionado explota estas API para llamar a un número de pago extraordinario, y así, robarles dinero a los usuarios incautos.

Ejemplo: el código siguiente solicita el número completo de correo de voz.

number = tm.getCompleteVoiceMailNumber(); 

La función de algunos permisos en Intents es conceder permisos a programas externos que normalmente carecen de esos permisos, como FLAG_GRANT_READ_URI_PERMISSION o FLAG_GRANT_WRITE_URI_PERMISSION. Si un programa malintencionado consigue interceptar esta finalidad, obtendrá permiso para leer o escribir en el URI especificado. A menudo, las finalidades implícitas serán más susceptibles de ser interceptadas que las explícitas.

Ejemplo 1: el siguiente código establece la marca de permiso para activar la escritura en un URI dentro del Intent.

  myIntent.setFlags(Intent.FLAG_GRANT_WRITE_URI_PERMISSION);