Técnica de codificación segura: El problema de los permisos personalizados
Al desarrollar para móviles, las aplicaciones suelen tener que solicitar algunos permisos al sistema. Pueden necesitar acceso a los contactos del usuario, a la conexión Bluetooth o la capacidad de enviar mensajes SMS. Todos los permisos mencionados anteriormente son permisos de plataforma, definidos por el framework de Android.
Pero hay casos en los que estos no son suficientes y la aplicación necesita definir su propio permiso personalizado. Utilizaré nuestra propia empresa como ejemplo. Secure Code Warrior puede crear una aplicación que guarde algunos datos privados como parte de un perfil, incluyendo el rendimiento del usuario en la plataforma SCW. Y nos gustaría permitir que otra aplicación de formación en seguridad, digamos DevTrainer, utilice estos datos si el usuario le da permiso para hacerlo. Se trata de datos sensibles, el usuario ciertamente no querría que cualquiera los conociera, pero la SCWApp no debería ocultarlos y protegerlos completamente, ya que podrían ser útiles. Por lo tanto, deseamos que el usuario tenga control sobre ella. Aquí es donde entran los permisos personalizados.
La SCWApp crea un permiso personalizado, DevTrainer solicita este permiso y el usuario puede decidir si quiere permitirlo o no. Esta es una práctica común y una buena manera de restringir el acceso a las aplicaciones de la lista blanca.
Lamentablemente, hay algunos comportamientos poco intuitivos en torno a los permisos personalizados que los hacen arriesgados desde el punto de vista de la seguridad. Concretamente, los permisos personalizados pueden ser definidos por cualquier app en cualquier momento, y "el primero gana", y esta estrategia viene con algunas consecuencias.
Para el siguiente escenario, definimos dos perfiles de aplicaciones que hemos introducido anteriormente (todas estas aplicaciones son ficticias a efectos demostrativos):
1. SCWApp: la aplicación que define un permiso personalizado y defiende un componente utilizando este permiso.
2. DevTrainer: esta aplicación define el mismo permiso que SCWApp y declara al usuario que desea tener este permiso.
Este es un escenario común acuñado como el caso de las Peer Apps. Si la aplicación DevTrainer fuera sólo un plugin para la SCWApp no tendría que definir el permiso personalizado. La suposición, en este caso, es que SCWApp se instalaría antes que DevTrainer y no se produciría ningún comportamiento inesperado. Si de alguna manera el usuario instala primero DevTrainer, no se le informa de la solicitud del permiso. Si el usuario instala más tarde SCWApp, no se concede el permiso a DevTrainer 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 se puede esperar que una aplicación se instale antes que la otra. Digamos que si Facebook y Twitter quieren utilizar los componentes del otro, tienen que definir los permisos personalizados del otro.
Sin embargo, aquí es donde la cosa se complica. Si la aplicación DevTrainer se instala primero, el usuario no es informado de su solicitud de permiso personalizado. En este punto, aunque el usuario no haya sido informado, DevTrainer tiene el permiso personalizado y puede acceder al componente protegido.
La cosa se complica aún más. La aplicación DevTrainer puede cambiar el nivel de protección de los permisos. Android no utiliza 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 instaló primero puede definirlo. Esto significa que si DevTrainer cambia el nivel de permiso a normal, entonces cualquier aplicación futura que solicite este permiso no tendrá que ser confirmada por el usuario, sino que se le concederá automáticamente el acceso.
Este escenario está inspirado en la explicación de este problema que se encuentra en el github de cwac-security.
La estrategia "el primero gana" tiene algunas consecuencias peligrosas y el desconocimiento de su comportamiento puede llevar al desarrollador a tomar decisiones de seguridad basadas en entradas no fiables y permitir que aplicaciones no deseadas accedan a datos sensibles o servicios protegidos. Para obtener más información sobre cómo evitar las decisiones de seguridad a través de entradas no fiables, visite nuestra plataforma. Este comportamiento se modificó a partir de Android 5.0 (Lollipop). Pero como actualmente, más del 22% de los dispositivos Android siguen ejecutando una versión inferior de Android es importante mitigar los riesgos del comportamiento original en tu aplicación. Comprueba si el permiso ya se ha definido en la primera ejecución de tu app y toma las medidas adecuadas si es el caso para resolver cualquier riesgo de seguridad.
Buena suerte con la codificación y hasta la semana que viene.
Al definir los 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 los permisos personalizados, una aplicación puede compartir sus recursos y capacidades con otras aplicaciones.
Investigador de seguridad de aplicaciones - Ingeniero de I+D - Candidato a doctor
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Reservar una demostración
Investigador de seguridad de aplicaciones - Ingeniero de I+D - Candidato a doctor
Al desarrollar para móviles, las aplicaciones suelen tener que solicitar algunos permisos al sistema. Pueden necesitar acceso a los contactos del usuario, a la conexión Bluetooth o la capacidad de enviar mensajes SMS. Todos los permisos mencionados anteriormente son permisos de plataforma, definidos por el framework de Android.
Pero hay casos en los que estos no son suficientes y la aplicación necesita definir su propio permiso personalizado. Utilizaré nuestra propia empresa como ejemplo. Secure Code Warrior puede crear una aplicación que guarde algunos datos privados como parte de un perfil, incluyendo el rendimiento del usuario en la plataforma SCW. Y nos gustaría permitir que otra aplicación de formación en seguridad, digamos DevTrainer, utilice estos datos si el usuario le da permiso para hacerlo. Se trata de datos sensibles, el usuario ciertamente no querría que cualquiera los conociera, pero la SCWApp no debería ocultarlos y protegerlos completamente, ya que podrían ser útiles. Por lo tanto, deseamos que el usuario tenga control sobre ella. Aquí es donde entran los permisos personalizados.
La SCWApp crea un permiso personalizado, DevTrainer solicita este permiso y el usuario puede decidir si quiere permitirlo o no. Esta es una práctica común y una buena manera de restringir el acceso a las aplicaciones de la lista blanca.
Lamentablemente, hay algunos comportamientos poco intuitivos en torno a los permisos personalizados que los hacen arriesgados desde el punto de vista de la seguridad. Concretamente, los permisos personalizados pueden ser definidos por cualquier app en cualquier momento, y "el primero gana", y esta estrategia viene con algunas consecuencias.
Para el siguiente escenario, definimos dos perfiles de aplicaciones que hemos introducido anteriormente (todas estas aplicaciones son ficticias a efectos demostrativos):
1. SCWApp: la aplicación que define un permiso personalizado y defiende un componente utilizando este permiso.
2. DevTrainer: esta aplicación define el mismo permiso que SCWApp y declara al usuario que desea tener este permiso.
Este es un escenario común acuñado como el caso de las Peer Apps. Si la aplicación DevTrainer fuera sólo un plugin para la SCWApp no tendría que definir el permiso personalizado. La suposición, en este caso, es que SCWApp se instalaría antes que DevTrainer y no se produciría ningún comportamiento inesperado. Si de alguna manera el usuario instala primero DevTrainer, no se le informa de la solicitud del permiso. Si el usuario instala más tarde SCWApp, no se concede el permiso a DevTrainer 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 se puede esperar que una aplicación se instale antes que la otra. Digamos que si Facebook y Twitter quieren utilizar los componentes del otro, tienen que definir los permisos personalizados del otro.
Sin embargo, aquí es donde la cosa se complica. Si la aplicación DevTrainer se instala primero, el usuario no es informado de su solicitud de permiso personalizado. En este punto, aunque el usuario no haya sido informado, DevTrainer tiene el permiso personalizado y puede acceder al componente protegido.
La cosa se complica aún más. La aplicación DevTrainer puede cambiar el nivel de protección de los permisos. Android no utiliza 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 instaló primero puede definirlo. Esto significa que si DevTrainer cambia el nivel de permiso a normal, entonces cualquier aplicación futura que solicite este permiso no tendrá que ser confirmada por el usuario, sino que se le concederá automáticamente el acceso.
Este escenario está inspirado en la explicación de este problema que se encuentra en el github de cwac-security.
La estrategia "el primero gana" tiene algunas consecuencias peligrosas y el desconocimiento de su comportamiento puede llevar al desarrollador a tomar decisiones de seguridad basadas en entradas no fiables y permitir que aplicaciones no deseadas accedan a datos sensibles o servicios protegidos. Para obtener más información sobre cómo evitar las decisiones de seguridad a través de entradas no fiables, visite nuestra plataforma. Este comportamiento se modificó a partir de Android 5.0 (Lollipop). Pero como actualmente, más del 22% de los dispositivos Android siguen ejecutando una versión inferior de Android es importante mitigar los riesgos del comportamiento original en tu aplicación. Comprueba si el permiso ya se ha definido en la primera ejecución de tu app y toma las medidas adecuadas si es el caso para resolver cualquier riesgo de seguridad.
Buena suerte con la codificación y hasta la semana que viene.
Al definir los permisos personalizados, una aplicación puede compartir sus recursos y capacidades con otras aplicaciones.
https://developer.android.com/guide/topics/permissions/defining.html
Al desarrollar para móviles, las aplicaciones suelen tener que solicitar algunos permisos al sistema. Pueden necesitar acceso a los contactos del usuario, a la conexión Bluetooth o la capacidad de enviar mensajes SMS. Todos los permisos mencionados anteriormente son permisos de plataforma, definidos por el framework de Android.
Pero hay casos en los que estos no son suficientes y la aplicación necesita definir su propio permiso personalizado. Utilizaré nuestra propia empresa como ejemplo. Secure Code Warrior puede crear una aplicación que guarde algunos datos privados como parte de un perfil, incluyendo el rendimiento del usuario en la plataforma SCW. Y nos gustaría permitir que otra aplicación de formación en seguridad, digamos DevTrainer, utilice estos datos si el usuario le da permiso para hacerlo. Se trata de datos sensibles, el usuario ciertamente no querría que cualquiera los conociera, pero la SCWApp no debería ocultarlos y protegerlos completamente, ya que podrían ser útiles. Por lo tanto, deseamos que el usuario tenga control sobre ella. Aquí es donde entran los permisos personalizados.
La SCWApp crea un permiso personalizado, DevTrainer solicita este permiso y el usuario puede decidir si quiere permitirlo o no. Esta es una práctica común y una buena manera de restringir el acceso a las aplicaciones de la lista blanca.
Lamentablemente, hay algunos comportamientos poco intuitivos en torno a los permisos personalizados que los hacen arriesgados desde el punto de vista de la seguridad. Concretamente, los permisos personalizados pueden ser definidos por cualquier app en cualquier momento, y "el primero gana", y esta estrategia viene con algunas consecuencias.
Para el siguiente escenario, definimos dos perfiles de aplicaciones que hemos introducido anteriormente (todas estas aplicaciones son ficticias a efectos demostrativos):
1. SCWApp: la aplicación que define un permiso personalizado y defiende un componente utilizando este permiso.
2. DevTrainer: esta aplicación define el mismo permiso que SCWApp y declara al usuario que desea tener este permiso.
Este es un escenario común acuñado como el caso de las Peer Apps. Si la aplicación DevTrainer fuera sólo un plugin para la SCWApp no tendría que definir el permiso personalizado. La suposición, en este caso, es que SCWApp se instalaría antes que DevTrainer y no se produciría ningún comportamiento inesperado. Si de alguna manera el usuario instala primero DevTrainer, no se le informa de la solicitud del permiso. Si el usuario instala más tarde SCWApp, no se concede el permiso a DevTrainer 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 se puede esperar que una aplicación se instale antes que la otra. Digamos que si Facebook y Twitter quieren utilizar los componentes del otro, tienen que definir los permisos personalizados del otro.
Sin embargo, aquí es donde la cosa se complica. Si la aplicación DevTrainer se instala primero, el usuario no es informado de su solicitud de permiso personalizado. En este punto, aunque el usuario no haya sido informado, DevTrainer tiene el permiso personalizado y puede acceder al componente protegido.
La cosa se complica aún más. La aplicación DevTrainer puede cambiar el nivel de protección de los permisos. Android no utiliza 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 instaló primero puede definirlo. Esto significa que si DevTrainer cambia el nivel de permiso a normal, entonces cualquier aplicación futura que solicite este permiso no tendrá que ser confirmada por el usuario, sino que se le concederá automáticamente el acceso.
Este escenario está inspirado en la explicación de este problema que se encuentra en el github de cwac-security.
La estrategia "el primero gana" tiene algunas consecuencias peligrosas y el desconocimiento de su comportamiento puede llevar al desarrollador a tomar decisiones de seguridad basadas en entradas no fiables y permitir que aplicaciones no deseadas accedan a datos sensibles o servicios protegidos. Para obtener más información sobre cómo evitar las decisiones de seguridad a través de entradas no fiables, visite nuestra plataforma. Este comportamiento se modificó a partir de Android 5.0 (Lollipop). Pero como actualmente, más del 22% de los dispositivos Android siguen ejecutando una versión inferior de Android es importante mitigar los riesgos del comportamiento original en tu aplicación. Comprueba si el permiso ya se ha definido en la primera ejecución de tu app y toma las medidas adecuadas si es el caso para resolver cualquier riesgo de seguridad.
Buena suerte con la codificación y hasta la semana que viene.
Al definir los 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 siguiente enlace y descargue el PDF de este recurso.
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Ver el informeReservar una demostración
Investigador de seguridad de aplicaciones - Ingeniero de I+D - Candidato a doctor
Al desarrollar para móviles, las aplicaciones suelen tener que solicitar algunos permisos al sistema. Pueden necesitar acceso a los contactos del usuario, a la conexión Bluetooth o la capacidad de enviar mensajes SMS. Todos los permisos mencionados anteriormente son permisos de plataforma, definidos por el framework de Android.
Pero hay casos en los que estos no son suficientes y la aplicación necesita definir su propio permiso personalizado. Utilizaré nuestra propia empresa como ejemplo. Secure Code Warrior puede crear una aplicación que guarde algunos datos privados como parte de un perfil, incluyendo el rendimiento del usuario en la plataforma SCW. Y nos gustaría permitir que otra aplicación de formación en seguridad, digamos DevTrainer, utilice estos datos si el usuario le da permiso para hacerlo. Se trata de datos sensibles, el usuario ciertamente no querría que cualquiera los conociera, pero la SCWApp no debería ocultarlos y protegerlos completamente, ya que podrían ser útiles. Por lo tanto, deseamos que el usuario tenga control sobre ella. Aquí es donde entran los permisos personalizados.
La SCWApp crea un permiso personalizado, DevTrainer solicita este permiso y el usuario puede decidir si quiere permitirlo o no. Esta es una práctica común y una buena manera de restringir el acceso a las aplicaciones de la lista blanca.
Lamentablemente, hay algunos comportamientos poco intuitivos en torno a los permisos personalizados que los hacen arriesgados desde el punto de vista de la seguridad. Concretamente, los permisos personalizados pueden ser definidos por cualquier app en cualquier momento, y "el primero gana", y esta estrategia viene con algunas consecuencias.
Para el siguiente escenario, definimos dos perfiles de aplicaciones que hemos introducido anteriormente (todas estas aplicaciones son ficticias a efectos demostrativos):
1. SCWApp: la aplicación que define un permiso personalizado y defiende un componente utilizando este permiso.
2. DevTrainer: esta aplicación define el mismo permiso que SCWApp y declara al usuario que desea tener este permiso.
Este es un escenario común acuñado como el caso de las Peer Apps. Si la aplicación DevTrainer fuera sólo un plugin para la SCWApp no tendría que definir el permiso personalizado. La suposición, en este caso, es que SCWApp se instalaría antes que DevTrainer y no se produciría ningún comportamiento inesperado. Si de alguna manera el usuario instala primero DevTrainer, no se le informa de la solicitud del permiso. Si el usuario instala más tarde SCWApp, no se concede el permiso a DevTrainer 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 se puede esperar que una aplicación se instale antes que la otra. Digamos que si Facebook y Twitter quieren utilizar los componentes del otro, tienen que definir los permisos personalizados del otro.
Sin embargo, aquí es donde la cosa se complica. Si la aplicación DevTrainer se instala primero, el usuario no es informado de su solicitud de permiso personalizado. En este punto, aunque el usuario no haya sido informado, DevTrainer tiene el permiso personalizado y puede acceder al componente protegido.
La cosa se complica aún más. La aplicación DevTrainer puede cambiar el nivel de protección de los permisos. Android no utiliza 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 instaló primero puede definirlo. Esto significa que si DevTrainer cambia el nivel de permiso a normal, entonces cualquier aplicación futura que solicite este permiso no tendrá que ser confirmada por el usuario, sino que se le concederá automáticamente el acceso.
Este escenario está inspirado en la explicación de este problema que se encuentra en el github de cwac-security.
La estrategia "el primero gana" tiene algunas consecuencias peligrosas y el desconocimiento de su comportamiento puede llevar al desarrollador a tomar decisiones de seguridad basadas en entradas no fiables y permitir que aplicaciones no deseadas accedan a datos sensibles o servicios protegidos. Para obtener más información sobre cómo evitar las decisiones de seguridad a través de entradas no fiables, visite nuestra plataforma. Este comportamiento se modificó a partir de Android 5.0 (Lollipop). Pero como actualmente, más del 22% de los dispositivos Android siguen ejecutando una versión inferior de Android es importante mitigar los riesgos del comportamiento original en tu aplicación. Comprueba si el permiso ya se ha definido en la primera ejecución de tu app y toma las medidas adecuadas si es el caso para resolver cualquier riesgo de seguridad.
Buena suerte con la codificación y hasta la semana que viene.
Al definir los permisos personalizados, una aplicación puede compartir sus recursos y capacidades con otras aplicaciones.
https://developer.android.com/guide/topics/permissions/defining.html
Índice
Investigador de seguridad de aplicaciones - Ingeniero de I+D - Candidato a doctor
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Reservar una demostraciónDescargarRecursos para empezar
Panorama de la gestión de riesgos de los promotores
La gestión de riesgos del desarrollador es un enfoque holístico y proactivo de la seguridad de las aplicaciones, centrado en quienes contribuyen al código y no en los bits y bytes de la propia capa de la aplicación.
Seguridad desde el diseño: Definición de las mejores prácticas, capacitación de los desarrolladores y evaluación comparativa de los resultados de la seguridad preventiva
En este documento de investigación, los cofundadores Secure Code Warrior , Pieter Danhieux y el Dr. Matias Madou, Ph.D., junto con los expertos colaboradores, Chris Inglis, ex Director Nacional Cibernético de EE.UU. (ahora Asesor Estratégico de Paladin Capital Group), y Devin Lynch, Director Senior, Paladin Global Institute, revelarán los hallazgos clave de más de veinte entrevistas en profundidad con líderes de seguridad empresarial, incluyendo CISOs, un VP de Seguridad de Aplicaciones y profesionales de seguridad de software.
Evaluación comparativa de las competencias en materia de seguridad: optimización del diseño seguro en la empresa
Encontrar datos significativos sobre el éxito de las iniciativas Secure-by-Design es notoriamente difícil. Los responsables de la seguridad de la información se enfrentan a menudo al reto de demostrar el rendimiento de la inversión (ROI) y el valor empresarial de las actividades de los programas de seguridad, tanto a nivel de las personas como de la empresa. Por no mencionar que a las empresas les resulta especialmente difícil obtener información sobre cómo se comparan sus organizaciones con los estándares actuales del sector. La Estrategia Nacional de Ciberseguridad del Presidente desafió a las partes interesadas a "adoptar la seguridad y la resiliencia desde el diseño". La clave para que las iniciativas de seguridad por diseño funcionen no es sólo dotar a los desarrolladores de las habilidades necesarias para garantizar un código seguro, sino también garantizar a los reguladores que esas habilidades están en su lugar. En esta presentación, compartimos una miríada de datos cualitativos y cuantitativos, derivados de múltiples fuentes primarias, incluidos puntos de datos internos recogidos de más de 250.000 desarrolladores, opiniones de clientes basadas en datos y estudios públicos. Aprovechando esta agregación de puntos de datos, pretendemos comunicar una visión del estado actual de las iniciativas Secure-by-Design en múltiples verticales. El informe detalla por qué este espacio está actualmente infrautilizado, el impacto significativo que un programa de mejora de las competencias puede tener en la mitigación de los riesgos de ciberseguridad y el potencial para eliminar categorías de vulnerabilidades de un código base.
Servicios profesionales - Acelerar con experiencia
El equipo de servicios de estrategia de programas (PSS) de Secure Code Warriorle ayuda a crear, mejorar y optimizar su programa de codificación segura. Tanto si empieza de cero como si está perfeccionando su enfoque, nuestros expertos le proporcionarán orientación personalizada.
Recursos para empezar
Revelado: Cómo define el sector cibernético la seguridad por diseño
En nuestro último libro blanco, nuestros cofundadores, Pieter Danhieux y el doctor Matias Madou, se sentaron con más de veinte líderes de seguridad empresarial, incluidos CISO, líderes de AppSec y profesionales de la seguridad, para averiguar las piezas clave de este rompecabezas y descubrir la realidad detrás del movimiento Secure by Design. Se trata de una ambición compartida por todos los equipos de seguridad, pero no de un libro de jugadas compartido.
¿Vibe Coding va a convertir tu código en una fiesta de fraternidad?
Vibe Coding es como una fiesta de fraternidad universitaria, y la IA es la pieza central de todos los festejos, el barril. Es muy divertido dar rienda suelta a la creatividad y ver adónde te lleva tu imaginación, pero después de unas cuantas borracheras, beber (o usar IA) con moderación es, sin duda, la solución más segura a largo plazo.
Codificación orientada al desarrollador.
Con seguridad.
Póngase en contacto con nosotros hoy mismo y haga de la seguridad del software una parte intrínseca de su proceso de desarrollo.
