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.

Los paquetes PL/SQL pueden ser AUTHID DEFINER o AUTHID CURRENT_USER. Las funciones y los procedimientos de un paquete con los derechos del definidor se ejecutan con los privilegios del usuario que define el paquete. 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. En un paquete 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 la cláusula AUTHID no se proporciona, el paquete utilizará los derechos del definidor de forma predeterminada.

Por lo general, los paquetes 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.

Determinadas operaciones de Android necesitan permisos. La aplicación debe solicitar los permisos en el momento de la instalación enumerándolos en el archivo AndroidManifest.xml mediante las etiquetas <uses-permission/>. Si no se han solicitado los permisos necesarios, las operaciones que requieren esos permisos producirán errores a la vez. En algunos casos, se devuelve un java.lang.SecurityException a la aplicación. En otras ocasiones, las operaciones producen un error en silencio sin una excepción.

Ejemplo 1: el siguiente código 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);

Esta API necesita el permiso android.permission.SEND_SMS. Si la aplicación no solicita este permiso en el archivo manifest, la aplicación no podrá enviar un mensaje SMS.

Determinadas operaciones de Android necesitan permisos. La aplicación debe solicitar los permisos en el momento de la instalación enumerándolos en el archivo AndroidManifest.xml mediante las etiquetas <uses-permission/>. Si no se han solicitado los permisos necesarios, las operaciones que requieren esos permisos producirán errores a la vez. En algunos casos, se devuelve un java.lang.SecurityException a la aplicación. En otras ocasiones, las operaciones producen un error en silencio sin una excepción.

Ejemplo 1: el siguiente código lee información de los contactos almacenada en el dispositivo.

Cursor cursor = getContentResolver().query(ContactsContract.Contacts.CONTENT_URI, null, null, null, null);

Para leer los datos de este proveedor de contenido, es necesario disponer del permiso android.permission.READ_CONTACTS. Si la aplicación no solicita este permiso en el archivo manifest, esta no podrá leer la información de los contactos.

Determinadas operaciones de Android necesitan permisos. La aplicación debe solicitar los permisos en el momento de la instalación enumerándolos en el archivo AndroidManifest.xml mediante las etiquetas <uses-permission/>. Si no se han solicitado los permisos necesarios, las operaciones que requieren esos permisos producirán errores a la vez. En algunos casos, se devuelve un java.lang.SecurityException a la aplicación. En otras ocasiones, las operaciones producen un error en silencio sin una excepción.

Ejemplo 1: el siguiente código envía una finalidad con la acción android.provider.Telephony.SMS_RECEIVED.

    Intent i = new Intent("android.provider.Telephony.SMS_RECEIVED");
    context.sendBroadcast(i);

Para enviar esta finalidad, se debe disponer del permiso android.permission.BROADCAST_SMS. Si la aplicación no solicita este permiso en el archivo manifest, la aplicación no podrá enviar la finalidad.

Los principios de codificación segura abogan por hacer que los especificadores de acceso sean tan restrictivos como sea posible. Un método con un especificador de acceso public indica que todo el código externo tiene permiso para llamarlo. Los métodos públicos que realizan acciones privilegiadas pueden ser peligrosos cuando el código se comparte en bibliotecas o en entornos donde el código puede entrar de forma dinámica en el sistema (por ejemplo, inserción de código, inclusión de archivos peligrosos, carga de archivos, etc.).

Ejemplo 1: en el código siguiente, doPrivilegedOpenFile() se declara public y realiza una operación privilegiada.

public static void doPrivilegedOpenFile(final String filePath) {
final BadFileNamePrivilegedAction pa = new BadFileNamePrivilegedAction(filePath);

FileInputStream fis = null;
...
fis = (FileInputStream)AccessController.doPrivileged(pa);
...
}

Si utiliza la opción ALL PRIVILEGES o ALL otorgará al usuario todos los permisos que se pueden aplicar a un objeto. El programador no puede ser consciente de todos los privilegios que se le conceden.

Ejemplo 1: Un administrador puede que desee proporcionar a un usuario la capacidad de actualizar los datos en el procedimiento.

GRANT ALL ON employees TO john_doe;

Además de la posibilidad de seleccionar, actualizar, agregar y quitar filas, john_doe dispone ahora de permisos para cambiar la definición de la tabla.

Algunas funciones permiten a un programador especificar un valor explícito sobre si el permiso se concede o no. Esto puede ser objeto de abuso para infringir los deseos del usuario y asumir que se concedió el permiso.

Ejemplo 1: El siguiente código pide permiso para utilizar la ubicación del usuario en Android mientras se usa WebView; sin embargo, utiliza la ubicación del usuario tanto si se concede permiso para hacerlo como si no. Esto se logra invocando de forma manual la devolución de llamada con true para especificar que el permiso se concedió:

public void onGeolocationPermissionsShowPrompt(String origin, GeolocationPermissions$Callback callback){
  super.onGeolocationPermissionsShowPrompt(origin, callback);
  callback.invoke(origin, true, false);
}