Técnica de codificación segura: el problema de los permisos personalizados
Cuando se desarrollan para dispositivos móviles, las aplicaciones a menudo tienen que solicitar algunos permisos al sistema. Es posible que necesiten acceder a los contactos del usuario, a la conexión Bluetooth o poder enviar mensajes SMS. Todos los permisos mencionados anteriormente son permisos de plataforma, definidos por el marco de Android.
Sin embargo, hay casos en los que estos no son suficientes y la aplicación necesita definir su propio permiso personalizado. Usaré nuestra propia empresa como ejemplo. Secure Code Warrior podría crear una aplicación que guarde algunos datos privados como parte de un perfil, incluido el rendimiento del usuario en la plataforma SCW. Y nos gustaría permitir que otra aplicación de formación en seguridad, por ejemplo DevTrainer, utilice estos datos si el usuario le da permiso para hacerlo. Se trata de datos confidenciales, el usuario no querría que cualquiera lo supiera, pero el SCWApp no debería ocultarlos ni protegerlos por completo, ya que podría resultar útil. Por lo tanto, queremos que el usuario tenga el control sobre ellos. Aquí es donde entran en juego los permisos personalizados.
El SCWApp crea un permiso personalizado, DevTrainer solicita este permiso y el usuario puede decidir si quiere permitírselo o no. Esta es una práctica habitual y una buena forma de restringir el acceso a las aplicaciones incluidas en la lista blanca.
Desafortunadamente, hay algunos comportamientos poco intuitivos en torno a los permisos personalizados que los hacen riesgosos desde el punto de vista de la seguridad. Cualquier aplicación puede definir permisos concretos y personalizados en cualquier momento, y «el primero gana», y esta estrategia tiene algunas consecuencias.
Para el siguiente escenario, definimos dos perfiles de aplicación que presentamos anteriormente (todas estas aplicaciones son ficticias con fines demostrativos):
1. Aplicación SCW: la aplicación que define un permiso personalizado y defiende un componente con este permiso.
2. Entrenador de desarrollo: esta aplicación define el mismo permiso que SCWApp y declara al usuario que desea tener este permiso.
Este es un escenario común denominado Peer Apps Case. Si la aplicación DevTrainer fuera solo un complemento para la SCWApp, no tendría que definir el permiso personalizado. En este caso, se supone que SCWApp se instalará antes que DevTrainer y que no se producirá ningún comportamiento inesperado. Si, de alguna manera, el usuario instala DevTrainer primero, no se le informa de la solicitud del permiso. Si el usuario instala SCWApp más adelante, DevTrainer no recibe el permiso de forma retroactiva, por lo que los intentos de la aplicación DevTrainer de utilizar el componente seguro fallarán.
Aquí es donde entra en juego el caso de la aplicación Peers. En algunos casos, no puede esperar que una aplicación se instale antes que la otra. Supongamos que si Facebook y Twitter quieren usar los componentes del otro, tienen que definir los permisos personalizados de cada uno.
Sin embargo, aquí es donde se pone difícil. Si la aplicación DevTrainer se instala primero, el usuario no recibe información sobre su solicitud de permiso personalizado. En este momento, aunque el usuario no haya sido informado, DevTrainer tiene el permiso personalizado y puede acceder al componente seguro.
Se hace aún más difícil. La aplicación DevTrainer puede cambiar el nivel de protección de los permisos. Android no usa el nivel de protección del defensor, sino el nivel de protección que se define primero, lo que significa que la aplicación que se haya instalado primero puede definirlo. Esto significa que si DevTrainer cambia el nivel de permiso a normal, las futuras aplicaciones que soliciten este permiso no tendrán que ser confirmadas por el usuario, sino que se les concederá el acceso automáticamente.
Este escenario se inspiró en la explicación de este problema que se encuentra en el cwac-security github.
La estrategia de «el primero gana» tiene algunas consecuencias peligrosas y, si no conoce su comportamiento, el desarrollador puede tomar decisiones de seguridad basadas en datos no confiables y permitir que aplicaciones no deseadas accedan a datos confidenciales o servicios protegidos. Para obtener más información sobre cómo evitar tomar decisiones de seguridad mediante entradas que no sean de confianza, visita nuestra plataforma. Este comportamiento se modificó a partir de Android 5.0 (Lollipop). Pero desde la actualidad, más del 22% Si los dispositivos Android siguen ejecutando una versión inferior de Android, es importante mitigar los riesgos del comportamiento original de la aplicación. Comprueba si el permiso ya se definió en la primera ejecución de la aplicación y, si es así, toma las medidas adecuadas para resolver cualquier riesgo de seguridad.
¡Buena suerte programando y nos vemos la semana que viene!
Al definir permisos personalizados, una aplicación puede compartir sus recursos y capacidades con otras aplicaciones.
https://developer.android.com/guide/topics/permissions/defining.html
Al definir permisos personalizados, una aplicación puede compartir sus recursos y capacidades con otras aplicaciones.
应用安全研究员-研发工程师-博士生
Secure Code Warrior 您的组织在软件开发全生命周期中保护代码安全，并营造将网络安全置于首位的企业文化。无论您是应用安全管理员、开发人员、首席信息安全官，还是任何与安全相关的工作人员，我们都能助力您的组织降低不安全代码带来的风险。
预约演示
应用安全研究员-研发工程师-博士生
Cuando se desarrollan para dispositivos móviles, las aplicaciones a menudo tienen que solicitar algunos permisos al sistema. Es posible que necesiten acceder a los contactos del usuario, a la conexión Bluetooth o poder enviar mensajes SMS. Todos los permisos mencionados anteriormente son permisos de plataforma, definidos por el marco de Android.
Sin embargo, hay casos en los que estos no son suficientes y la aplicación necesita definir su propio permiso personalizado. Usaré nuestra propia empresa como ejemplo. Secure Code Warrior podría crear una aplicación que guarde algunos datos privados como parte de un perfil, incluido el rendimiento del usuario en la plataforma SCW. Y nos gustaría permitir que otra aplicación de formación en seguridad, por ejemplo DevTrainer, utilice estos datos si el usuario le da permiso para hacerlo. Se trata de datos confidenciales, el usuario no querría que cualquiera lo supiera, pero el SCWApp no debería ocultarlos ni protegerlos por completo, ya que podría resultar útil. Por lo tanto, queremos que el usuario tenga el control sobre ellos. Aquí es donde entran en juego los permisos personalizados.
El SCWApp crea un permiso personalizado, DevTrainer solicita este permiso y el usuario puede decidir si quiere permitírselo o no. Esta es una práctica habitual y una buena forma de restringir el acceso a las aplicaciones incluidas en la lista blanca.
Desafortunadamente, hay algunos comportamientos poco intuitivos en torno a los permisos personalizados que los hacen riesgosos desde el punto de vista de la seguridad. Cualquier aplicación puede definir permisos concretos y personalizados en cualquier momento, y «el primero gana», y esta estrategia tiene algunas consecuencias.
Para el siguiente escenario, definimos dos perfiles de aplicación que presentamos anteriormente (todas estas aplicaciones son ficticias con fines demostrativos):
1. Aplicación SCW: la aplicación que define un permiso personalizado y defiende un componente con este permiso.
2. Entrenador de desarrollo: esta aplicación define el mismo permiso que SCWApp y declara al usuario que desea tener este permiso.
Este es un escenario común denominado Peer Apps Case. Si la aplicación DevTrainer fuera solo un complemento para la SCWApp, no tendría que definir el permiso personalizado. En este caso, se supone que SCWApp se instalará antes que DevTrainer y que no se producirá ningún comportamiento inesperado. Si, de alguna manera, el usuario instala DevTrainer primero, no se le informa de la solicitud del permiso. Si el usuario instala SCWApp más adelante, DevTrainer no recibe el permiso de forma retroactiva, por lo que los intentos de la aplicación DevTrainer de utilizar el componente seguro fallarán.
Aquí es donde entra en juego el caso de la aplicación Peers. En algunos casos, no puede esperar que una aplicación se instale antes que la otra. Supongamos que si Facebook y Twitter quieren usar los componentes del otro, tienen que definir los permisos personalizados de cada uno.
Sin embargo, aquí es donde se pone difícil. Si la aplicación DevTrainer se instala primero, el usuario no recibe información sobre su solicitud de permiso personalizado. En este momento, aunque el usuario no haya sido informado, DevTrainer tiene el permiso personalizado y puede acceder al componente seguro.
Se hace aún más difícil. La aplicación DevTrainer puede cambiar el nivel de protección de los permisos. Android no usa el nivel de protección del defensor, sino el nivel de protección que se define primero, lo que significa que la aplicación que se haya instalado primero puede definirlo. Esto significa que si DevTrainer cambia el nivel de permiso a normal, las futuras aplicaciones que soliciten este permiso no tendrán que ser confirmadas por el usuario, sino que se les concederá el acceso automáticamente.
Este escenario se inspiró en la explicación de este problema que se encuentra en el cwac-security github.
La estrategia de «el primero gana» tiene algunas consecuencias peligrosas y, si no conoce su comportamiento, el desarrollador puede tomar decisiones de seguridad basadas en datos no confiables y permitir que aplicaciones no deseadas accedan a datos confidenciales o servicios protegidos. Para obtener más información sobre cómo evitar tomar decisiones de seguridad mediante entradas que no sean de confianza, visita nuestra plataforma. Este comportamiento se modificó a partir de Android 5.0 (Lollipop). Pero desde la actualidad, más del 22% Si los dispositivos Android siguen ejecutando una versión inferior de Android, es importante mitigar los riesgos del comportamiento original de la aplicación. Comprueba si el permiso ya se definió en la primera ejecución de la aplicación y, si es así, toma las medidas adecuadas para resolver cualquier riesgo de seguridad.
¡Buena suerte programando y nos vemos la semana que viene!
Al definir permisos personalizados, una aplicación puede compartir sus recursos y capacidades con otras aplicaciones.
https://developer.android.com/guide/topics/permissions/defining.html
Cuando se desarrollan para dispositivos móviles, las aplicaciones a menudo tienen que solicitar algunos permisos al sistema. Es posible que necesiten acceder a los contactos del usuario, a la conexión Bluetooth o poder enviar mensajes SMS. Todos los permisos mencionados anteriormente son permisos de plataforma, definidos por el marco de Android.
Sin embargo, hay casos en los que estos no son suficientes y la aplicación necesita definir su propio permiso personalizado. Usaré nuestra propia empresa como ejemplo. Secure Code Warrior podría crear una aplicación que guarde algunos datos privados como parte de un perfil, incluido el rendimiento del usuario en la plataforma SCW. Y nos gustaría permitir que otra aplicación de formación en seguridad, por ejemplo DevTrainer, utilice estos datos si el usuario le da permiso para hacerlo. Se trata de datos confidenciales, el usuario no querría que cualquiera lo supiera, pero el SCWApp no debería ocultarlos ni protegerlos por completo, ya que podría resultar útil. Por lo tanto, queremos que el usuario tenga el control sobre ellos. Aquí es donde entran en juego los permisos personalizados.
El SCWApp crea un permiso personalizado, DevTrainer solicita este permiso y el usuario puede decidir si quiere permitírselo o no. Esta es una práctica habitual y una buena forma de restringir el acceso a las aplicaciones incluidas en la lista blanca.
Desafortunadamente, hay algunos comportamientos poco intuitivos en torno a los permisos personalizados que los hacen riesgosos desde el punto de vista de la seguridad. Cualquier aplicación puede definir permisos concretos y personalizados en cualquier momento, y «el primero gana», y esta estrategia tiene algunas consecuencias.
Para el siguiente escenario, definimos dos perfiles de aplicación que presentamos anteriormente (todas estas aplicaciones son ficticias con fines demostrativos):
1. Aplicación SCW: la aplicación que define un permiso personalizado y defiende un componente con este permiso.
2. Entrenador de desarrollo: esta aplicación define el mismo permiso que SCWApp y declara al usuario que desea tener este permiso.
Este es un escenario común denominado Peer Apps Case. Si la aplicación DevTrainer fuera solo un complemento para la SCWApp, no tendría que definir el permiso personalizado. En este caso, se supone que SCWApp se instalará antes que DevTrainer y que no se producirá ningún comportamiento inesperado. Si, de alguna manera, el usuario instala DevTrainer primero, no se le informa de la solicitud del permiso. Si el usuario instala SCWApp más adelante, DevTrainer no recibe el permiso de forma retroactiva, por lo que los intentos de la aplicación DevTrainer de utilizar el componente seguro fallarán.
Aquí es donde entra en juego el caso de la aplicación Peers. En algunos casos, no puede esperar que una aplicación se instale antes que la otra. Supongamos que si Facebook y Twitter quieren usar los componentes del otro, tienen que definir los permisos personalizados de cada uno.
Sin embargo, aquí es donde se pone difícil. Si la aplicación DevTrainer se instala primero, el usuario no recibe información sobre su solicitud de permiso personalizado. En este momento, aunque el usuario no haya sido informado, DevTrainer tiene el permiso personalizado y puede acceder al componente seguro.
Se hace aún más difícil. La aplicación DevTrainer puede cambiar el nivel de protección de los permisos. Android no usa el nivel de protección del defensor, sino el nivel de protección que se define primero, lo que significa que la aplicación que se haya instalado primero puede definirlo. Esto significa que si DevTrainer cambia el nivel de permiso a normal, las futuras aplicaciones que soliciten este permiso no tendrán que ser confirmadas por el usuario, sino que se les concederá el acceso automáticamente.
Este escenario se inspiró en la explicación de este problema que se encuentra en el cwac-security github.
La estrategia de «el primero gana» tiene algunas consecuencias peligrosas y, si no conoce su comportamiento, el desarrollador puede tomar decisiones de seguridad basadas en datos no confiables y permitir que aplicaciones no deseadas accedan a datos confidenciales o servicios protegidos. Para obtener más información sobre cómo evitar tomar decisiones de seguridad mediante entradas que no sean de confianza, visita nuestra plataforma. Este comportamiento se modificó a partir de Android 5.0 (Lollipop). Pero desde la actualidad, más del 22% Si los dispositivos Android siguen ejecutando una versión inferior de Android, es importante mitigar los riesgos del comportamiento original de la aplicación. Comprueba si el permiso ya se definió en la primera ejecución de la aplicación y, si es así, toma las medidas adecuadas para resolver cualquier riesgo de seguridad.
¡Buena suerte programando y nos vemos la semana que viene!
Al definir permisos personalizados, una aplicación puede compartir sus recursos y capacidades con otras aplicaciones.
https://developer.android.com/guide/topics/permissions/defining.html
Cuando se desarrollan para dispositivos móviles, las aplicaciones a menudo tienen que solicitar algunos permisos al sistema. Es posible que necesiten acceder a los contactos del usuario, a la conexión Bluetooth o poder enviar mensajes SMS. Todos los permisos mencionados anteriormente son permisos de plataforma, definidos por el marco de Android.
Sin embargo, hay casos en los que estos no son suficientes y la aplicación necesita definir su propio permiso personalizado. Usaré nuestra propia empresa como ejemplo. Secure Code Warrior podría crear una aplicación que guarde algunos datos privados como parte de un perfil, incluido el rendimiento del usuario en la plataforma SCW. Y nos gustaría permitir que otra aplicación de formación en seguridad, por ejemplo DevTrainer, utilice estos datos si el usuario le da permiso para hacerlo. Se trata de datos confidenciales, el usuario no querría que cualquiera lo supiera, pero el SCWApp no debería ocultarlos ni protegerlos por completo, ya que podría resultar útil. Por lo tanto, queremos que el usuario tenga el control sobre ellos. Aquí es donde entran en juego los permisos personalizados.
El SCWApp crea un permiso personalizado, DevTrainer solicita este permiso y el usuario puede decidir si quiere permitírselo o no. Esta es una práctica habitual y una buena forma de restringir el acceso a las aplicaciones incluidas en la lista blanca.
Desafortunadamente, hay algunos comportamientos poco intuitivos en torno a los permisos personalizados que los hacen riesgosos desde el punto de vista de la seguridad. Cualquier aplicación puede definir permisos concretos y personalizados en cualquier momento, y «el primero gana», y esta estrategia tiene algunas consecuencias.
Para el siguiente escenario, definimos dos perfiles de aplicación que presentamos anteriormente (todas estas aplicaciones son ficticias con fines demostrativos):
1. Aplicación SCW: la aplicación que define un permiso personalizado y defiende un componente con este permiso.
2. Entrenador de desarrollo: esta aplicación define el mismo permiso que SCWApp y declara al usuario que desea tener este permiso.
Este es un escenario común denominado Peer Apps Case. Si la aplicación DevTrainer fuera solo un complemento para la SCWApp, no tendría que definir el permiso personalizado. En este caso, se supone que SCWApp se instalará antes que DevTrainer y que no se producirá ningún comportamiento inesperado. Si, de alguna manera, el usuario instala DevTrainer primero, no se le informa de la solicitud del permiso. Si el usuario instala SCWApp más adelante, DevTrainer no recibe el permiso de forma retroactiva, por lo que los intentos de la aplicación DevTrainer de utilizar el componente seguro fallarán.
Aquí es donde entra en juego el caso de la aplicación Peers. En algunos casos, no puede esperar que una aplicación se instale antes que la otra. Supongamos que si Facebook y Twitter quieren usar los componentes del otro, tienen que definir los permisos personalizados de cada uno.
Sin embargo, aquí es donde se pone difícil. Si la aplicación DevTrainer se instala primero, el usuario no recibe información sobre su solicitud de permiso personalizado. En este momento, aunque el usuario no haya sido informado, DevTrainer tiene el permiso personalizado y puede acceder al componente seguro.
Se hace aún más difícil. La aplicación DevTrainer puede cambiar el nivel de protección de los permisos. Android no usa el nivel de protección del defensor, sino el nivel de protección que se define primero, lo que significa que la aplicación que se haya instalado primero puede definirlo. Esto significa que si DevTrainer cambia el nivel de permiso a normal, las futuras aplicaciones que soliciten este permiso no tendrán que ser confirmadas por el usuario, sino que se les concederá el acceso automáticamente.
Este escenario se inspiró en la explicación de este problema que se encuentra en el cwac-security github.
La estrategia de «el primero gana» tiene algunas consecuencias peligrosas y, si no conoce su comportamiento, el desarrollador puede tomar decisiones de seguridad basadas en datos no confiables y permitir que aplicaciones no deseadas accedan a datos confidenciales o servicios protegidos. Para obtener más información sobre cómo evitar tomar decisiones de seguridad mediante entradas que no sean de confianza, visita nuestra plataforma. Este comportamiento se modificó a partir de Android 5.0 (Lollipop). Pero desde la actualidad, más del 22% Si los dispositivos Android siguen ejecutando una versión inferior de Android, es importante mitigar los riesgos del comportamiento original de la aplicación. Comprueba si el permiso ya se definió en la primera ejecución de la aplicación y, si es así, toma las medidas adecuadas para resolver cualquier riesgo de seguridad.
¡Buena suerte programando y nos vemos la semana que viene!
Al definir permisos personalizados, una aplicación puede compartir sus recursos y capacidades con otras aplicaciones.
https://developer.android.com/guide/topics/permissions/defining.html
%20(1).avif)
.avif)
