Las aplicaciones para Android se pueden configurar para producir archivos binarios de depuración. Estos binarios proporcionan mensajes de depuración detallados y no deben usarse en entornos de producción. El atributo debuggable de la etiqueta <application> define si los binarios compilados deben incluir información de depuración.

El uso de binarios de depuración hace que una aplicación proporcione al usuario tanta información sobre sí misma como sea posible. Los binarios de depuración están diseñados para usarse en un entorno de desarrollo o prueba y pueden suponer un riesgo de seguridad si se implementan en producción. Los atacantes pueden valerse de información adicional que obtengan del resultado de seguimiento para planear ataques contra el marco de trabajo, la base de datos o cualquier otro recurso que la aplicación utilice.

El estándar de Java exige que las implementaciones de Object.equals(), Comparable.compareTo() y Comparator.compare() devuelvan un valor especificado si sus parámetros son null. De no cumplir el contrato se daría lugar a un comportamiento inesperado.

Ejemplo 1: La implementación siguiente del método equals() no compara su parámetro con null.

public boolean equals(Object object)
{
   return (toString().equals(object.toString()));
}

Se producen violaciones de la 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 contiene una instrucción de registro que realiza un seguimiento de los registros agregados a una base de datos almacenando el contenido en un archivo de registro.

pass = getPassword();
...
dbmsLog.println(id+":"+pass+":"+type+":"+tstamp);

El código del Example 1 registra una contraseña de texto sin formato en el sistema de archivos. Aunque muchos desarrolladores confían en el sistema de archivos 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.

La privacidad es una de las mayores preocupaciones en las plataformas móviles debido a un par de motivos. Uno de ellos es la mayor probabilidad de pérdida del dispositivo. El otro está relacionado con las comunicaciones entre procesos entre aplicaciones móviles. En las plataformas móviles, las aplicaciones se descargan desde diversos orígenes y se ejecutan junto con otras aplicaciones en el mismo dispositivo. La probabilidad de ejecutar un malware junto a una aplicación de banca es bastante alta, de modo que los autores de aplicaciones deben tener cuidado con la información que incluyen en los mensajes dirigidos a otras aplicaciones que se ejecutan en el dispositivo. La información confidencial nunca debería formar parte of las comunicaciones entre procesos entre aplicaciones móviles.

Ejemplo 2: El siguiente código lee el nombre de usuario y la contraseña de un sitio determinado de un almacén WebView de Android y los difunde a todos los destinatarios registrados.

...
webview.setWebViewClient(new WebViewClient() {
  public void onReceivedHttpAuthRequest(WebView view,
        HttpAuthHandler handler, String host, String realm) {
    String[] credentials = view.getHttpAuthUsernamePassword(host, realm);
    String username = credentials[0];
    String password = credentials[1];
    Intent i = new Intent();
    i.setAction("SEND_CREDENTIALS");
    i.putExtra("username", username);
    i.putExtra("password", password);
    view.getContext().sendBroadcast(i);
  }
});
...

Este ejemplo pone de manifiesto varios problemas. El primero de todos es que, de manera predeterminada, las credenciales de WebView se almacenan en texto sin formato y no tienen hash. Si un usuario tiene un dispositivo con acceso root (o usa un emulador), podrá leer las contraseñas almacenadas de sitios determinados. El segundo es que las credenciales de texto sin formato se difunden a todos los destinatarios registrados, lo que significa que cualquier destinatario registrado para escuchar las finalidades con la acción SEND_CREDENTIALS recibirá el mensaje. La difusión ni siquiera está protegida con un permiso para limitar el número de destinatarios, aunque en este caso no recomendamos el uso de permisos como solució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

Normalmente, en el contexto de un entorno móvil, esta información privada incluye (junto con contraseñas, SSN y otra información personal general):

- Ubicación

- Número de teléfono móvil

- Números de serie e identificadores de dispositivos

- Información del operador de red

- Información del buzón de voz


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

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.

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

Las vulnerabilidades de inyección de cadenas de consulta se producen cuando:
1. Los datos entran en un programa desde un origen que no es de confianza.



2. Los datos se utilizan para crear de forma dinámica una cadena de consulta de SimpleDB.

Ejemplo 1: el siguiente código crea y ejecuta de forma dinámica una consulta select() de SimpleDB que busca facturas que coincidan con una categoría de productos especificada por el usuario. El usuario también puede especificar la columna por la que se ordenarán los resultados. Imagine que la aplicación ya ha autenticado y establecido correctamente el valor de customerID antes de este segmento de código.

...
String customerID = getAuthenticatedCustomerID(customerName, customerCredentials);
...
AmazonSimpleDBClient sdbc = new AmazonSimpleDBClient(appAWSCredentials);
String query = "select * from invoices where productCategory = '"
            + productCategory + "' and customerID = '"
            + customerID + "' order by '"
            + sortColumn + "' asc";
SelectResult sdbResult = sdbc.select(new SelectRequest(query));
...

La consulta que este código tiene intención de ejecutar presentará un aspecto similar al siguiente:

select * from invoices
where productCategory = 'Fax Machines'
and customerID = '12345678'
order by 'price' asc

Sin embargo, debido a que la consulta se ha creado de forma dinámica mediante la concatenación de una cadena de consulta base constante y una cadena de entrada de usuario, esta solo se comportará correctamente si productCategory y price no contienen caracteres de comillas simples. Sin embargo, si un usuario malintencionado proporciona la cadena "Fax Machines' or productCategory = \"" para productCategory y la cadena "\" order by 'price" para sortColumn, la consulta se convierte en lo siguiente:

select * from invoices
where productCategory = 'Fax Machines' or productCategory = "'
and customerID = '12345678'
order by '" order by 'price' asc

o, en un formato más adecuado para la lectura humana,

select * from invoices
where productCategory = 'Fax Machines'
or productCategory = "' and customerID = '12345678' order by '"
order by 'price' asc

Estas entradas permiten a un usuario malintencionado omitir la autenticación necesaria de customerID y ver los registros de facturas que coinciden con 'Fax Machines' de todos los clientes.

Las vulnerabilidades de inyección de cadenas de consulta se producen cuando:
1. Los datos entran en un programa desde un origen que no es de confianza.



En este caso, Fortify Static Code Analyzer no pudo determinar que el origen de los datos era de confianza.

2. Los datos se utilizan para crear dinámicamente una consulta SQLite.

La inyección de cadenas de consulta SQLite permite a los usuarios malintencionados ver registros no autorizados, pero les impide modificar de cualquier modo el estado de la base de datos.

Ejemplo 1: el siguiente código crea y ejecuta dinámicamente una consulta SQLite que busca facturas asociadas a un cliente y una categoría de productos especificada por el usuario. Este también puede especificar la columna por la que deben ordenarse los resultados. Imagine que el programa ya ha realizado correctamente la autenticación y establecido el valor de customerID que antecede a este segmento de código.

  ...
  productCategory = this.getIntent().getExtras().getString("productCategory");
  sortColumn = this.getIntent().getExtras().getString("sortColumn");
  customerID = getAuthenticatedCustomerID(customerName, customerCredentials);
  c = invoicesDB.query(Uri.parse(invoices), columns, "productCategory = '" + productCategory + "' and customerID = '" + customerID + "'", null, null, null, "'" + sortColumn + "'asc", null);
  ...
  

La consulta que este código tiene intención de ejecutar presentará un aspecto similar al siguiente:

  select * from invoices
  where productCategory = 'Fax Machines'
  and customerID = '12345678'
  order by 'price' asc
  

Sin embargo, la consulta se crea de forma dinámica mediante la concatenación de una cadena de consulta base constante y una cadena de entrada de usuario productCategory. Por lo tanto, la consulta solo presentará el comportamiento correcto si productCategory y sortColumn no contienen caracteres de comillas simples. Si un usuario malintencionado proporciona la cadena "Fax Machines' or productCategory = \"" para productCategory, y la cadena "\" order by 'price" para sortColumn, la consulta se convierte en:

  select * from invoices
  where productCategory = 'Fax Machines' or productCategory = "'
  and customerID = '12345678'
  order by '" order by 'price' asc
  

o bien en un formato más legible,

  select * from invoices
  where productCategory = 'Fax Machines'
  or productCategory = "' and customerID = '12345678' order by '"
  order by 'price' asc
  

Estas entradas permiten a un usuario malintencionado omitir la autenticación necesaria para customerID y ver registros de facturas que coincidan con 'Fax Machines' de todos los clientes.