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.
Chercheur en sécurité applicative - Ingénieur R&D - Doctorant
Secure Code Warrior là pour aider votre organisation à protéger le code tout au long du cycle de vie du développement logiciel et à créer une culture où la cybersécurité est une priorité. Que vous soyez administrateur AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Veuillez réserver une démonstration.
Chercheur en sécurité applicative - Ingénieur R&D - Doctorant
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
Veuillez cliquer sur le lien ci-dessous et télécharger le PDF de cette ressource.
Secure Code Warrior là pour aider votre organisation à protéger le code tout au long du cycle de vie du développement logiciel et à créer une culture où la cybersécurité est une priorité. Que vous soyez administrateur AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Veuillez consulter le rapportVeuillez réserver une démonstration.
Chercheur en sécurité applicative - Ingénieur R&D - Doctorant
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
Table des matières
Chercheur en sécurité applicative - Ingénieur R&D - Doctorant
Secure Code Warrior là pour aider votre organisation à protéger le code tout au long du cycle de vie du développement logiciel et à créer une culture où la cybersécurité est une priorité. Que vous soyez administrateur AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Veuillez réserver une démonstration.TéléchargerRessources pour débuter
Thèmes et contenu de la formation sur le code sécurisé
Notre contenu de pointe évolue constamment afin de s'adapter au paysage changeant du développement logiciel, en tenant compte de votre rôle. Nous proposons des thèmes allant de l'IA à l'injection XQuery pour différents postes, des architectes et ingénieurs aux chefs de produit et responsables de l'assurance qualité. Découvrez un aperçu de ce que notre catalogue de contenu a à offrir par thème et par fonction.
La Chambre de commerce établit la norme en matière de sécurité à grande échelle axée sur les développeurs
La Chambre de commerce néerlandaise explique comment elle a intégré le codage sécurisé dans le développement quotidien grâce à des certifications basées sur les rôles, à l'évaluation comparative du Trust Score et à une culture de responsabilité partagée en matière de sécurité.
%20(1).avif)
.avif)
Modélisation des menaces avec l'IA : transformer chaque développeur en modélisateur de menaces
Vous repartirez mieux équipé pour aider les développeurs à combiner les idées et les techniques de modélisation des menaces avec les outils d'IA qu'ils utilisent déjà pour renforcer la sécurité, améliorer la collaboration et créer des logiciels plus résilients dès le départ.
Ressources pour débuter
Cybermon est de retour : les missions IA de Beat the Boss sont désormais disponibles à la demande.
Cybermon 2025 Beat the Boss est désormais disponible toute l'année chez SCW. Mettez en œuvre des défis de sécurité avancés basés sur l'IA et le LLM afin de renforcer le développement sécurisé de l'IA à grande échelle.
Explication de la loi sur la cyber-résilience : implications pour le développement de logiciels sécurisés dès leur conception
Découvrez les exigences de la loi européenne sur la cyber-résilience (CRA), à qui elle s'applique et comment les équipes d'ingénierie peuvent se préparer grâce à des pratiques de conception sécurisées, à la prévention des vulnérabilités et au développement des compétences des développeurs.
Facilitateur 1 : Critères de réussite définis et mesurables
Le catalyseur n° 1 inaugure notre série en 10 parties intitulée « Les catalyseurs de la réussite », qui montre comment relier la codification sécurisée aux résultats commerciaux, tels que la réduction des risques et la rapidité d'atteinte de la maturité du programme à long terme.
