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 1: 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 1: 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 1: 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);

Las funciones y los procedimientos PL/SQL pueden ser AUTHID DEFINER o AUTHID CURRENT_USER. Las funciones y los procedimientos con los derechos del definidor se ejecutan con los privilegios del usuario que define el código. De este modo se podrán implementar las actualizaciones y obtener acceso a datos específicos sin permitir el acceso a todo el contenido de las tablas o los esquemas. Con los derechos del invocador o AUTHID CURRENT_USER, las funciones y los procedimientos se ejecutan con los privilegios del usuario que los invoca. Así, un usuario no tendrá acceso a los datos a los que aún no podía acceder. Si no se proporciona ninguna cláusula AUTHID, la función o el procedimiento utilizará los derechos del definidor de forma predeterminada.

Por lo general, las funciones y los procedimientos se definen mediante SYS u otro usuario con privilegios elevados, lo cual hace que las vulnerabilidades de seguridad del código sean potencialmente más peligrosas.