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.
Anwendungssicherheitsforscher - F&E-Ingenieur - PhD-Kandidat
Secure Code Warrior hier, um Ihrem Unternehmen dabei zu helfen, den Code während des gesamten Lebenszyklus der Softwareentwicklung zu schützen und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie AppSec-Administrator, Entwickler, CISO oder in einem anderen Bereich der Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Eine Vorführung buchen
Anwendungssicherheitsforscher - F&E-Ingenieur - PhD-Kandidat
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
Klicken Sie auf den untenstehenden Link und laden Sie die PDF-Datei dieser Ressource herunter.
Secure Code Warrior hier, um Ihrem Unternehmen dabei zu helfen, den Code während des gesamten Lebenszyklus der Softwareentwicklung zu schützen und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie AppSec-Administrator, Entwickler, CISO oder in einem anderen Bereich der Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht anzeigenEine Vorführung buchen
Anwendungssicherheitsforscher - F&E-Ingenieur - PhD-Kandidat
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
Inhaltsverzeichnis
Anwendungssicherheitsforscher - F&E-Ingenieur - PhD-Kandidat
Secure Code Warrior hier, um Ihrem Unternehmen dabei zu helfen, den Code während des gesamten Lebenszyklus der Softwareentwicklung zu schützen und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie AppSec-Administrator, Entwickler, CISO oder in einem anderen Bereich der Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Eine Vorführung buchenHerunterladenRessourcen für den Einstieg
Themen und Inhalte der Schulung zum Thema sicherer Code
Unsere branchenführenden Inhalte werden ständig weiterentwickelt, um sich an die sich wandelnde Landschaft der Softwareentwicklung anzupassen und dabei Ihre Rolle zu berücksichtigen. Es werden Themen angeboten, die von KI bis hin zu XQuery-Injektion reichen und sich an verschiedene Positionen richten, von Architekten und Ingenieuren bis hin zu Produktmanagern und Qualitätskontrolleuren. Verschaffen Sie sich einen Überblick über unser Angebot an Inhalten nach Thema und Funktion.
Die Kamer van Koophandel setzt Maßstäbe für entwicklergesteuerte Sicherheit in großem Maßstab
Die Kamer van Koophandel berichtet, wie sie sicheres Codieren durch rollenbasierte Zertifizierungen, Trust Score-Benchmarking und eine Kultur der gemeinsamen Verantwortung für Sicherheit in die tägliche Entwicklungsarbeit integriert hat.
%20(1).avif)
.avif)
Bedrohungsmodellierung mit KI: So wird jeder Entwickler zum Bedrohungsmodellierer
Sie werden besser gerüstet sein, um Entwicklern dabei zu helfen, Ideen und Techniken zur Bedrohungsmodellierung mit den KI-Tools zu kombinieren, die sie bereits verwenden, um die Sicherheit zu erhöhen, die Zusammenarbeit zu verbessern und von Anfang an widerstandsfähigere Software zu entwickeln.
Ressourcen für den Einstieg
Cybermon ist zurück: Die KI-Missionen von Beat the Boss sind jetzt auf Abruf verfügbar.
Cybermon 2025 Beat the Boss ist jetzt das ganze Jahr über bei SCW verfügbar. Implementieren Sie fortschrittliche KI- und LLM-Sicherheitsherausforderungen, um die sichere Entwicklung von KI in großem Maßstab zu stärken.
Erläuterung des Gesetzes zur Cyberresilienz: Was bedeutet es für die Entwicklung sicherer Software?
Entdecken Sie, was das EU-Gesetz zur Cyberresilienz (CRA) verlangt, für wen es gilt und wie sich Ingenieurteams mit sicheren Designpraktiken, der Vermeidung von Schwachstellen und der Entwicklung von Fähigkeiten für Entwickler darauf vorbereiten können.
SCW feiert sein 11-jähriges Bestehen: eine Lektion in Echtzeit über Anpassungsfähigkeit und kontinuierliche Verbesserung
2025 war ein großartiges Jahr für KI, Cybersicherheit und SCW. Ich gehe mit ruhiger Zuversicht und dem Optimismus, den nur harte und lohnende Arbeit mit sich bringen kann, auf das Jahr 2026 zu.