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.
Application Security Researcher - R&D Engineer - PhD Candidate
Secure Code Warrior está aquí para que su organización le ayude a proteger el código durante todo el ciclo de vida del desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Ya sea administrador de AppSec, desarrollador, CISO o cualquier persona relacionada con la seguridad, podemos ayudar a su organización a reducir los riesgos asociados con el código inseguro.
Reserva una demostración
Application Security Researcher - R&D Engineer - PhD Candidate
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
Haga clic en el enlace de abajo y descargue el PDF de este recurso.
Secure Code Warrior está aquí para que su organización le ayude a proteger el código durante todo el ciclo de vida del desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Ya sea administrador de AppSec, desarrollador, CISO o cualquier persona relacionada con la seguridad, podemos ayudar a su organización a reducir los riesgos asociados con el código inseguro.
Ver informeReserva una demostración
Application Security Researcher - R&D Engineer - PhD Candidate
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
Tabla de contenido
Application Security Researcher - R&D Engineer - PhD Candidate
Secure Code Warrior está aquí para que su organización le ayude a proteger el código durante todo el ciclo de vida del desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Ya sea administrador de AppSec, desarrollador, CISO o cualquier persona relacionada con la seguridad, podemos ayudar a su organización a reducir los riesgos asociados con el código inseguro.
Reserva una demostraciónDescargarRecursos para empezar
Temas y contenido de formación sobre código seguro
Nuestro contenido líder en la industria siempre está evolucionando para adaptarse al cambiante panorama del desarrollo de software teniendo en cuenta su función. Se ofrecen temas que abarcan desde la IA hasta la inyección de XQuery para distintos puestos, desde arquitectos e ingenieros hasta directores de productos y control de calidad. Obtenga un adelanto de lo que ofrece nuestro catálogo de contenido por tema y función.
%20(1).avif)
.avif)
Threat Modeling with AI: Turning Every Developer into a Threat Modeler
Walk away better equipped to help developers combine threat modeling ideas and techniques with the AI tools they're already using to strengthen security, improve collaboration, and build more resilient software from the start.
Recursos para empezar
Cybermon está de vuelta: las misiones de IA de Beat the Boss ya están disponibles bajo demanda
Cybermon 2025 Beat the Boss ya está disponible durante todo el año en SCW. Implemente desafíos de seguridad avanzados de IA y LLM para fortalecer el desarrollo seguro de la IA a gran escala.
Explicación de la Ley de Ciberresiliencia: qué significa para el desarrollo de software seguro por diseño
Descubra qué exige la Ley de Ciberresiliencia (CRA) de la UE, a quién se aplica y cómo los equipos de ingeniería pueden prepararse con prácticas de diseño seguras, prevención de vulnerabilidades y desarrollo de capacidades para desarrolladores.
Habilitador 1: Criterios de éxito definidos y medibles
Enabler 1 da inicio a nuestra serie Enablers of Success, de 10 partes, mostrando cómo vincular la codificación segura con los resultados empresariales, como la reducción del riesgo y la velocidad para lograr la madurez del programa a largo plazo.
