El ataque de Reconocimiento y Exfiltración del navegador a través de compresión adaptativa del hipertexto (BREACH) es un tipo de ataque del lado del canal que permite a los usuarios malintencionados robar información confidencial contenida en respuestas HTTP transferidas a través de un canal habilitado para SSL/TLS. Todos los cifrados y las versiones de SSL/TLS existentes son vulnerables a este ataque. Si se cumplen las tres condiciones siguientes, un atacante podría llevar a cabo con éxito un ataque de BREACH contra la aplicación:

1. La aplicación transmite un secreto (por ejemplo, un token contra CSRF) en la respuesta.
2. La aplicación refleja una entrada del usuario en la misma respuesta que contiene un secreto.
3. El servidor web se configura para utilizar compresión HTTP.

El tamaño de una respuesta comprimida con gzip se determina por la cantidad de repeticiones observadas dentro de su contenido. Por lo tanto, cuando los caracteres se repiten con más frecuencia, menor se vuelve el tamaño de la respuesta. Esto permite que un usuario malintencionado utilice la compresión HTTP como oráculo que puede indicar si una suposición proporcionada por un usuario malintencionado a la aplicación a través del valor de parámetro reflejado es correcta o no. Si el carácter de la suposición coincide con el carácter correspondiente en el secreto, el tamaño de la respuesta comprimida es más pequeño. El atacante podría utilizar este proceso para obtener todo el secreto carácter por carácter a través del análisis de la relación de compresión de cada solicitud.

Un atacante podría utilizar esta técnica para extraer un secreto de las respuestas HTTP incluso si la aplicación está configurada para facilitar contenido a través de un canal seguro.

Para evaluar si la aplicación es vulnerable al ataque de BREACH, primero revise si la aplicación está configurada para habilitar compresión HTTP. Si es así, para cada respuesta que contenga un secreto para proteger, evalúe si hay una entrada del usuario incluida dentro de esta.

Este problema se informa porque la aplicación de Django se configura para utilizar tokens de CSRF y compresión GZip:

MIDDLEWARE = (
  ...
  'django.middleware.csrf.CsrfViewMiddleware',
  'django.middleware.gzip.GZipMiddleware',
  ...
)

Se filtra la información médica privada cuando:

1. La información médica 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 recupera la información de tipo sanguíneo de la tienda HealthKit y la envía a un servidor mientras la registra en el dispositivo. Aunque muchos desarrolladores confían en los archivos de registro como una ubicación segura de almacenamiento para todos los datos, el usuario no debería confiar absolutamente, en especial, cuando la privacidad es una preocupación.

    ...
    HKHealthStore healthStore = new HKHealthStore();
    HKBloodTypeObject blood = healthStore.GetBloodType(null);

    NSLog("%@", blood.BloodType);

	var urlWithParams = String.format(TOKEN_URL, block.BloodType);
	var responseString = await client.GetStringAsync(urlWithParams);
    ...

Nota: La API de inicio de sesión de Apple, que está en un nivel inferior a la función NSLog, permite que un diseñador cree una aplicación que pueda leer todos los registros del dispositivo (aunque no sea propietario de las otras aplicaciones).

Otros motivos de preocupación en relación con el mantenimiento de la privacidad de los datos de usuario surgen cuando se pierde o se roba un dispositivo. Una vez en posesión de un dispositivo iOS, un atacante puede acceder a gran cantidad de datos conectando el dispositivo por USB. Los archivos de tipo Lista de propiedades de iOS (plists) y las bases de datos de SQLite son fácilmente accesibles y pueden revelar información personal. Como regla general, los detalles privados relacionados con la salud no debe almacenarse sin protección en el sistema de archivos.

Ejemplo 2: El siguiente código añade el tipo sanguíneo del usuario a la lista de valores predeterminados de usuario y los almacena seguidamente en un archivo Lista de propiedades.

    ...
    HKHealthStore healthStore = new HKHealthStore();
    HKBloodTypeObject blood = healthStore.GetBloodType(null);

    // Add blood type to user defaults
	NSUserDefaults.StandardUserDefaults.SetString(blood.BloodType, "bloodType");
    ...

En respuesta al uso incorrecto de los datos privados, la recopilación y administración de los datos privados cada vez está sujeta a una mayor regulación. Con respecto a la información médica, podrá exigirse a las organizaciones que cumplan con una o más de las siguientes regulaciones federales y estatales:

- Marco de privacidad de Safe Harbor [2]

- Ley Gramm-Leach Bliley (GLBA) [3]

- Ley de portabilidad y responsabilidad de seguros médicos (Health Insurance Portability and Accountability Act, HIPAA) [4]

- California SB-1386 [5]

A pesar de estas regulaciones, se siguen produciendo con alarmante frecuencia violaciones de la privacidad.

Los datos confidenciales (como contraseñas, números de la seguridad social, números de tarjetas de crédito, etc.) almacenados en la memoria se podrían perder si no se limpia la memoria después de usarla. Sin embargo, a menudo se utilizan Strings para almacenar datos confidenciales porque los objetos String son inmutables; solo el recopilador de elementos no utilizados JVM puede eliminar el valor de un String de la memoria. No es necesario ejecutar el recopilador de elementos no utilizados a menos que la JVM tenga poca memoria, por lo que no hay garantía de cuándo se llevará a cabo la recopilación de elementos no utilizados. En caso de que una aplicación falle, un volcado de memoria de la misma podría revelar datos confidenciales.

Ejemplo 1: el código siguiente convierte una contraseña desde una matriz de carácter a una String.

private JPasswordField pf;
...
final char[] password = pf.getPassword();
...
String passwordAsString = new String(password);

Las solicitudes de HTTP que utilizan el método GET permiten que los parámetros de solicitud y URL se almacenen en los registros del servidor, los proxies intermedios y la caché de direcciones URL del explorador. Esto podría exponer la información confidencial a personas que no tienen los derechos adecuados a los datos.
Ejemplo 1: el siguiente código realiza una solicitud HTTP utilizando el método GET HTTP en lugar de POST.

...
	NSString * const USER_URL = @"https://www.somesvr.com/someapp/user";
...
	NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:USER_URL]];
	[request setHTTPMethod:@"GET"];
...

Ejemplo 2: si la aplicación utiliza NSURLRequest, el método HTTP predeterminado será GET.

...
	NSURLRequest *theRequest=[NSURLRequest requestWithURL:[NSURL URLWithString:@"http://www.apple.com/"]
                        cachePolicy:NSURLRequestUseProtocolCachePolicy
                    timeoutInterval:60.0];
	NSURLConnection *theConnection=[[NSURLConnection alloc] initWithRequest:theRequest delegate:self];
	if (theConnection) {
    	// Create the NSMutableData to hold the received data.
    	// receivedData is an instance variable declared elsewhere.
    		receivedData = [[NSMutableData data] retain];
	} else {
...

Cuando se crea una instancia de NSURLCredential que contiene las credenciales del usuario en forma de un par nombre de usuario/contraseña o un certificado de cliente, debe definirse un atributo de persistencia. Los valores posibles son los siguientes:

- NSURLCredentialPersistenceNone: no se debe almacenar la credencial.
- NSURLCredentialPersistenceForSession: solo se debe almacenar la credencial para esta sesión.
- NSURLCredentialPersistencePermanent: la credencial debe almacenarse en las llaves.
- NSURLCredentialPersistenceSynchronizable: la credencial debe almacenarse de manera permanente en las llaves y, además, debe distribuirse a otros dispositivos basándose en la ID de Apple de propietario.

El atributo NSURLCredentialPersistenceSynchronizable implica la distribución de la credencial y su almacenamiento en el entorno de la nube de Apple. Según los requisitos de privacidad de la aplicación, el almacenamiento de la credencial en el entorno de la nube de Apple puede no ser aceptable.

Ejemplo 1: el siguiente fragmento de código crea una credencial que puede sincronizarse y que se distribuirá a otros dispositivos y en iCloud:

    ...
    NSURLCredential *credential = [NSURLCredential credentialWithUser:user password:password persistence:NSURLCredentialPersistenceSynchronizable]; 
    NSURLCredentialStorage *shared = [NSURLCredentialStorage sharedCredentialStorage];
    [shared setDefaultCredential:credential forProtectionSpace:protectionSpace]; 
    ...

Las infracciones de privacidad se producen cuando se almacenan datos confidenciales con un formato no cifrado.


Ejemplo 1: en el siguiente código ASPX, se crea una instancia de un control DataVisualization que genera un gráfico de información financiera confidencial del origen de datos XML SensitiveXMLData:

        <asp:Chart ID="Chart1" runat="server" ImageLocation="~/Temporary/Graph"
            ImageType="Jpeg" DataSourceID="SensitiveXMLData" ImageStorageMode="UseImageLocation">
            <series>
                .
                .
                .
            </series>
            <chartareas>
                <asp:ChartArea Name="ChartArea1">
                </asp:ChartArea>
            </chartareas>
        </asp:Chart>
  

El código del Example 1 indica al control de Chart que genere una imagen JPEG del gráfico de barras y lo escriba en el directorio temporal ~/Temporary/Graph. Una vez que el control escribe la imagen en el disco, el explorador del usuario realizará la consiguiente solicitud del archivo y lo mostrará al usuario. La imagen no se escribe de forma segura en el disco. Además, el código presupone que la infraestructura subyacente protegerá el archivo frente al acceso no autorizado por parte de otro usuario.

Cuando se crea una instancia de NSURLCredential que contiene las credenciales del usuario en forma de un par nombre de usuario/contraseña o un certificado de cliente, debe definirse un atributo de persistencia. Los valores posibles son los siguientes:

- NSURLCredentialPersistenceNone: no se debe almacenar la credencial.
- NSURLCredentialPersistenceForSession: solo se debe almacenar la credencial para esta sesión.
- NSURLCredentialPersistencePermanent: la credencial debe almacenarse en las llaves.
- NSURLCredentialPersistenceSynchronizable: la credencial debe almacenarse de manera permanente en las llaves y, además, debe distribuirse a otros dispositivos basándose en la ID de Apple de propietario.

Debido a que las credenciales de NSURLCredentialPersistenceSynchronizable se distribuyen a otros dispositivos y en iCloud, si no se quitan completamente de todos los sitios, quedarán instancias que podrían filtrarse.

Ejemplo 1: el siguiente fragmento de código crea una credencial que puede sincronizarse, la usa y luego la quita de manera local, pero no la quita de los demás dispositivos ni de iCloud:

    ...
    // Create the credential
	NSURLCredential *credential = [NSURLCredential credentialWithUser:user password:password persistence:NSURLCredentialPersistenceSynchronizable]; 
    NSURLCredentialStorage *shared = [NSURLCredentialStorage sharedCredentialStorage];
    [shared setDefaultCredential:credential forProtectionSpace:protectionSpace]; 

    // Use the credential as needed
    ...

    // Removes the credential
    [shared removeCredential:credential forProtectionSpace:protectionSpace];
    ...

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

El campo identificado no deshabilita el mecanismo de almacenamiento en caché del teclado de iOS. Por tanto, iOS almacena en caché la información confidencial introducida en el campo recientemente para mejorar su característica de autocorrección.

Ejemplo 1: la entrada especificada en un campo de texto confidencial se almacena en la caché del teclado del sistema.

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 almacena en caché las entradas en campos de texto para mejorar el rendimiento de la característica de autocorrección, puede que la información introducida recientemente en tal control de entrada se almacene en un archivo caché del teclado, el cual se guarda en el sistema de archivos. Debido a que el archivo caché de teclado se almacena en el dispositivo, este archivo 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.

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).

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.

El objetivo del directorio Documents es almacenar datos de aplicaciones no transitorios, como el contenido creado por el usuario o información local que le permite a la aplicación ejecutarse en modo sin conexión. Si se establece UIFileSharingEnabled en el archivo Info.plist de su aplicación, se podrá acceder a los archivos de esta ubicación a través de iTunes. Cuando se escriben datos confidenciales en el directorio Documents, es posible que los datos queden expuestos en las copias de seguridad no cifradas o a través de la interfaz de iTunes.

Ejemplo 1: el siguiente fragmento de código escribe la contraseña del usuario en texto sin cifrar dentro del directorio Documents:

    ...
    NSString *docsDirectory = [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES) objectAtIndex:0];
    NSString *passwd_path = [docsDirectory stringByAppendingPathComponent:@"passwords.txt"];

    NSString *password = [user password];
    [password writeToFile:passwd_path atomically:YES encoding:NSUTF8StringEncoding error:nil];
    ...

Algunas API que recopilan información confidencial pueden tratarla incorrectamente devolviéndola al usuario.

Ejemplo 1: El siguiente código muestra cómo crear instancias de un objeto de devolución de llamada de contraseña que no oculta la contraseña de un usuario cuando la escribe en el indicador de entrada:

PasswordCallback pc = new PasswordCallback("Please enter your password: ", true);

Dado que pc en el Example 1había creado una instancia con su segundo parámetro, onEcho, establecido en true, la contraseña del usuario no se ocultará cuando la introduzca en el mensaje "Introduzca su contraseña:" .

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"/>