A diferencia de la mayoría de las vulnerabilidades del top ten de APIs de OWASP, la gestión inadecuada de activos no se centra específicamente en defectos de codificación. En cambio, esta vulnerabilidad es más bien un problema humano o de gestión que permite que las APIs más antiguas sigan vigentes mucho tiempo después de que deban ser reemplazadas por versiones más nuevas y seguras. También puede ocurrir si las APIs que todavía están en desarrollo se exponen al entorno de producción antes de que estén completamente reforzadas contra las amenazas.

Esta vulnerabilidad es especialmente difícil de gestionar debido a la llegada de los microservicios y la computación en nube. En ese entorno, los nuevos servicios pueden ponerse en marcha rápidamente para satisfacer una necesidad temporal y luego olvidarse de ellos y no retirarlos nunca. Si las APIs más antiguas se dejan conectadas al entorno de producción, se puede poner en peligro toda la red.

¿Quieres probar un desafío gamificado sobre este fallo de seguridad? Entra en nuestra arena: [Empieza aquí]

¿Cómo afectan los fallos de gestión de activos a las APIs?

El defecto de la gestión de activos inadecuados es un producto de los tiempos modernos. Las organizaciones que se mueven a la velocidad del negocio pueden a veces poner en marcha cientos o miles de servicios y microservicios cada día. Esto se hace a menudo rápidamente y sin la creación de ninguna documentación de acompañamiento, ni ninguna explicación de para qué se utilizan las APIs asociadas, cuánto tiempo se necesitarán o su criticidad. Esto puede generar rápidamente una proliferación de APIs que podría volverse incontrolable con el tiempo, especialmente si no hay políticas generales para definir cuánto tiempo pueden existir las APIs.

En ese entorno, es muy posible que algunas APIs se pierdan, se olviden o nunca se den de baja.

Los usuarios con permiso para crear nuevos servicios fuera del proceso normal también son a veces culpables. Por ejemplo, un grupo de marketing puede crear un servicio para apoyar un evento próximo, como el lanzamiento de un producto, y luego no retirarlo una vez finalizado el evento. Alguien que vea ese servicio y sus APIs asociadas más tarde podría no tener ni idea de por qué existen, y si no hay documentación, podría seguir siendo un misterio. Puede que no se sientan cómodos eliminando esas APIs del entorno de producción o incluso actualizándolas a versiones más nuevas porque no tienen ni idea de lo críticas que son o de lo que hacen.

La vulnerabilidad se vuelve peligrosa porque la seguridad de las APIs en los frameworks mejora con el tiempo. Un investigador puede descubrir una vulnerabilidad, o se puede añadir seguridad adicional para detener un tipo de ataque cada vez más popular. Las APIs más antiguas pueden seguir siendo vulnerables a esos ataques a menos que se actualicen, por lo que los hackers suelen buscarlas o utilizar herramientas automatizadas para buscarlas.

En un ejemplo del mundo real proporcionado por OWASP, una empresa actualizó sus APIs utilizadas para buscar en bases de datos de usuarios para parchear un fallo crítico. Pero dejaron las antiguas APIs en su lugar por error.

Un atacante se dio cuenta de que la ubicación de la nueva API era algo así como (api.criticalservice.com/v2). Reemplazando la URL por (api.criticalservice.com/v1) pudieron utilizar la antigua API con la vulnerabilidad conocida. Esto finalmente expuso los registros personales de más de 100 millones de usuarios.

Eliminación de los defectos de gestión de activos inadecuados

La única manera de eliminar el defecto de gestión de activos inadecuados de su entorno es mantener un inventario estricto de todas las APIs, sus usos y versiones. Esto debe comenzar con un inventario de las APIs existentes, centrándose en factores como el entorno en el que deben desplegarse, como producción o desarrollo, quién debe tener acceso a la red y, por supuesto, su versión.

Una vez que se haya completado, es necesario implementar un proceso en el que la documentación se añada automáticamente a cualquier nueva API o servicio que se cree. Esto debería incluir todos los aspectos de la API, incluyendo la limitación de la tasa, cómo maneja las solicitudes y las respuestas, los recursos compartidos, los puntos finales a los que se puede conectar, cualquier política relevante que se aplique, además de cualquier otra cosa que sea necesaria para auditarlas posteriormente. También hay que evitar utilizar nunca en producción APIs que no sean de producción o del entorno de desarrollo. Considera también la posibilidad de añadir un límite de tiempo a las APIs en el que su uso continuado deba ser justificado por sus propietarios para evitar el desmantelamiento automático.

Siempre que estén disponibles nuevas versiones de las APIs activas, realice un riesgo assessment para determinar si debe actualizar, y cómo debe llevarse a cabo ese proceso para evitar la interrupción del entorno de producción. Una vez que hayas migrado a las nuevas APIs, elimina las antiguas por completo del entorno.

Hacer todo esto puede ayudar a evitar que la vulnerabilidad de la gestión de activos inadecuada perjudique a su organización, a los usuarios o a la red. Consulte las páginas del Secure Code Warrior páginas del blog para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otros fallos de seguridad. También puede probar una demostración de la plataforma de formación Secure Code Warrior para mantener todos sus conocimientos de ciberseguridad perfeccionados y actualizados.

‍

En una entrada anterior del blog se describía el Gotcha de Java "Bitwise vs Boolean Operator".

• Gotchas de Java - Operador Bitwise vs Boolean

Hemos añadido una variante de esto, y algunos otros Gotchas de Java en un pequeño y divertido concurso llamado "Challenge The Sensei".

• scw.typeform.com/to/rgw7q7OE

Si has leído la entrada del blog anterior, estarás en una buena posición para superar al menos una de las preguntas.

Pero es posible que tus amigos no lo hagan, así que si el cuestionario te parece divertido, puedes compartirlo con ellos y ver si obtienen la misma puntuación que tú.

Ya que no queremos limitarnos a hacer pruebas. Queremos tratar de usar esto para ayudar a educar y codificar el conocimiento. Así que hemos creado un repositorio de Github que tiene ejemplos de código ejecutables para el problema, y la solución.

• github.com/SecureCodeWarrior/challenge-the-sensei

Esta es una Sensei repo habilitado.

Cuando clones el repo y lo cargues en IntelliJ, asumiendo que tienes el Secure Code Warrior Sensei Plugin de IntelliJ instalado, entonces verá automáticamente que tienes una carpeta .sensei , y cargará las recetas de Sensei .

Cuando navegues por el código en el IDE deberías ver que IntelliJ te indica que el error existe en el código, y esto debería facilitarte ver el gotcha en el código:

• Pase el ratón por encima del código resaltado y verá un aviso que le indicará el error
• Utiliza la tecla de acción contextual: alt+entrada (Windows) opción+entrada (macOS) y es posible que tengamos un QuickFix disponible que pueda arreglar el código.

Se han añadido recetas deSensei para:

• Operadores Bitwise
• Dirección IP dividida
• Orden de afirmación

En el futuro añadiremos más recetas y más texto explicativo para cubrir el resto del código... pero no dejes que eso te impida echar un vistazo al código y detectar el error por ti mismo.

Y recuerda probar el test y"desafiar a la Sensei"

Gotchas de Java - Operadores Bitwise vs Boolean

> "Java Gotcha" - un patrón de error común que es fácil de implementar accidentalmente.

Un Gotcha de Java bastante sencillo en el que se puede caer accidentalmente es: utilizar un operador Bitwise en lugar de un operador de Comparación Booleana.

Por ejemplo, un simple error tipográfico puede hacer que se escriba "&" cuando en realidad se quería escribir "&&".

Una heurística común que aprendemos al revisar el código es:

> "&" o "|" cuando se utiliza en una declaración condicional probablemente no se pretende.

En esta entrada del blog, exploraremos la heurística e identificaremos las formas en que podemos identificar y solucionar este problema de codificación.

¿Cuál es el problema? Las operaciones Bitwise funcionan bien con los booleanos

El uso de operadores Bitwise con booleanos es perfectamente válido, por lo que Java no informará de un error de sintaxis.

Si construyo una prueba JUnit para explorar una tabla de verdad para ambos operadores Bitwise OR (|) y Bitwise AND (&) entonces veremos que las salidas del operador Bitwise coinciden con la tabla de verdad. Dado esto, podríamos pensar que el uso de los operadores Bitwise no es un problema.

Tabla de verdad AND

@Test
    void bitwiseOperatorsAndTruthTable(){
          Assertions.assertEquals(true, true & true);
          Assertions.assertEquals(false, true & false);
          Assertions.assertEquals(false, false & true);
          Assertions.assertEquals(false, false & false);
    }

La prueba pasa, esto es Java perfectamente válido.

Tabla de verdad de OR

   @Test
    void bitwiseOperatorsOrTruthTable(){
        Assertions.assertEquals(true, true | true);
        Assertions.assertEquals(true, true | false);
        Assertions.assertEquals(true, false | true);
        Assertions.assertEquals(false, false | false);
    }

Esta prueba también pasa, ¿por qué preferimos "&&'y "||'?

Las imágenes de la tabla de verdad se crearon con la herramienta herramienta de tabla de verdad de web.standfor.edu.

Problema: Funcionamiento en cortocircuito

El verdadero problema es la diferencia de comportamiento entre los operadores Bitwise (&, |) y Boolean (&&, ||).

Un operador booleano es un operador de cortocircuito y sólo evalúa lo necesario.

Por ejemplo

if (args != null & args.length() > 23) {
    System.out.println(args);
}

En el código anterior, ambas condiciones booleanas se evaluarán, porque se ha utilizado el operador Bitwise:

• args != null
• args.length() > 23

Esto deja mi código abierto a una NullPointerException si args es null porque siempre realizaremos la comprobación de args.length, incluso cuando args es null porque ambas condiciones booleanas tienen que ser evaluadas.

Operadores booleanos Evaluación de cortocircuitos

Cuando se utiliza un &&, por ejemplo

if (args != null && args.length() > 23) {
    System.out.println(args);
}

Tan pronto como sepamos que args != null se evalúa como falso, la evaluación de la expresión de la condición se detiene.

No necesitamos evaluar el lado derecho.

Sea cual sea el resultado de la condición del lado derecho, el valor final de la expresión booleana será falso.

Pero esto nunca ocurriría en el código de producción

Este es un error bastante fácil de cometer y no siempre es detectado por las herramientas de análisis estático.

Utilicé el siguiente Google Dork para ver si podía encontrar algún ejemplo público de este patrón:

filetype:java if "!=null & "
Esta búsqueda trajo un código de Android en el RootWindowContainer
isDocument = intent != null & intent.isDocument()

Este es el tipo de código que podría pasar una revisión de código porque a menudo usamos operadores Bitwise en las sentencias de asignación para enmascarar valores. Pero en este caso, el resultado es el mismo que el ejemplo de la sentencia if anterior. Si la intención es alguna vez nula, entonces se lanzará una NullPointerException.

Muy a menudo nos libramos de esta construcción porque solemos codificar a la defensiva y escribir código redundante. La comprobación de != null puede ser redundante en la mayoría de los casos de uso.

Este es un error cometido por los programadores en el código de producción.

No sé cómo de actuales son los resultados de la búsqueda, pero cuando ejecuté la búsqueda había resultados de vuelta con código de: Google, Amazon, Apache... y yo.

Un reciente pull request en uno de mis proyectos de código abierto fue para solucionar exactamente este error.

if(type!=null & type.trim().length()>0){
    acceptMediaTypeDefinitionsList.add(type.trim());
}

Cómo encontrarlo

Cuando comprobé mi código de muestra en unos cuantos analizadores estáticos, ninguno de ellos detectó este código de autodestrucción oculto.

Como equipo en Secure Code Warrior, creamos y revisamos una receta bastante simple de Sensei que podría recoger esto.

Dado que los operadores Bitwise son perfectamente válidos, y se utilizan a menudo en las asignaciones, nos centramos en el caso de uso de las sentencias if, y en el uso de Bitwise &, para encontrar el código problemático.

search:
  expression:
    anyOf:
    - in:
        condition: {}
    value:
      caseSensitive: false
      matches: ".* & .*"

Utiliza una expresión regular para que coincida con " & " cuando se utiliza como expresión de condición, por ejemplo, en una sentencia if.

Para solucionarlo, volvimos a recurrir a las expresiones regulares. Esta vez usando la función sed en el QuickFix para reemplazar globalmente el & en la expresión con &&.

availableFixes:
  - name: "Replace bitwise AND operator to logical AND operator"
    actions:
      - rewrite:
          to: "{{#sed}}s/&/&&/g,{{{ . }}}{{/sed}}"

Notas finales

Esto cubre el uso erróneo más común de un operador Bitwise, es decir, cuando se pretendía un operador Booleano.

Hay otras situaciones en las que esto podría surgir, por ejemplo, el ejemplo de la asignación, pero al escribir las recetas tenemos que intentar evitar la identificación falsa-positiva, de lo contrario las recetas serán ignoradas o desactivadas. Construimos las recetas para que coincidan con las ocurrencias más comunes. A medida que Sensei evolucione, es posible que añadamos más especificidad a la función de búsqueda para cubrir más condiciones de coincidencia.

En su forma actual, esta receta identificaría muchos de los casos de uso en vivo, y lo más importante, el que fue reportado en mi proyecto.

NOTA: Unos cuantos guerreros del código han contribuido a este ejemplo y a la revisión de la receta: Charlie Eriksen, Matthieu Calie, Robin Claerhaut, Brysen Ackx, Nathan Desmet, Downey Robersscheuten. Gracias por su ayuda.

---

Puedes instalar Sensei desde IntelliJ usando "Preferencias \N-Plugins" (Mac) o "Ajustes \N-Plugins" (Windows) y luego sólo busca "sensei secure code"

Tenemos un montón de código fuente y recetas para estas entradas del blog (incluyendo esta) en el repositorio `sensei-blog-examples` en la cuenta de GitHub de Secure Code Warrior .

https://github.com/securecodewarrior/sensei-blog-examples

Más información sobre Sensei

¿Qué es el análisis estático?

El análisis estático es el análisis automatizado del código fuente sin ejecutar la aplicación.

Cuando el análisis se realiza durante la ejecución del programa, se conoce como Análisis Dinámico.

El análisis estático se utiliza a menudo para detectar:

• Vulnerabilidades de seguridad.
• Problemas de rendimiento.
• Incumplimiento de las normas.
• Uso de construcciones de programación obsoletas.

¿Cómo funciona una herramienta de análisis estático?

El concepto básico común a todas las herramientas de análisis estático es buscar en el código fuente para identificar patrones de codificación específicos que tengan algún tipo de advertencia o información asociada.

Esto podría ser tan simple como "Las clases de prueba de JUnit 5 no necesitan ser 'públicas'". O algo complejo de identificar como "Se está utilizando una entrada de cadena no fiable en una sentencia de ejecución SQL".

Las herramientas de análisis estático varían en la forma de implementar esta funcionalidad.

• tecnología de análisis de código fuente para crear un árbol de sintaxis abstracta (AST),
• texto Coincidencia de expresiones regulares,
• una combinación de las anteriores.

La concordancia de expresiones regulares en el texto es muy flexible, fácil de escribir reglas de concordancia, pero a menudo puede conducir a una gran cantidad de falsos positivos y las reglas de concordancia ignoran el contexto del código circundante.

La concordancia AST trata el código fuente como código de programa, y no sólo como archivos llenos de texto, lo que permite una concordancia más específica y contextual y puede reducir el número de falsos positivos reportados contra el código.

Análisis estático en la integración continua

El análisis estático se realiza a menudo durante el proceso de integración continua (CI) para generar un informe de los problemas de conformidad que puede ser revisado para recibir una visión objetiva de la base de código a lo largo del tiempo.

Algunas personas utilizan el análisis estático como una medida objetiva de la calidad de su código configurando la herramienta de análisis estático para que sólo mida partes específicas del código y sólo informe sobre un subconjunto de reglas.

La objetividad la proporcionan las reglas utilizadas, ya que éstas no varían en su evaluación del código a lo largo del tiempo. Evidentemente, la combinación de reglas utilizadas y su configuración es una decisión subjetiva y diferentes equipos deciden utilizar diferentes reglas en diferentes momentos.

Hacer que el análisis estático se realice en CI es útil, pero podría retrasar la retroalimentación al programador. Los programadores no reciben retroalimentación cuando codifican, reciben retroalimentación más tarde cuando el código se ejecuta a través de la herramienta de Análisis Estático. Otro efecto secundario de ejecutar el Análisis Estático en CI es que los resultados son más fáciles de ignorar.

Para ayudar a que los equipos presten más atención a los resultados del Análisis Estático suele ser posible configurar una métrica de umbral en el proceso de construcción para que falle la construcción si se supera la métrica, por ejemplo, un número de reglas disparadas.

Análisis estático en el IDE

Para recibir la retroalimentación más rápidamente, hay muchos plugins de IDE que ejecutan las reglas de Análisis Estático en el IDE bajo demanda, o periódicamente a medida que el código cambia.

Las violaciones de las reglas se pueden ver en el IDE mientras el programador está escribiendo el código, y para hacer que las reglas sean más difíciles de ignorar, las violaciones se pueden configurar para que se muestren como código subrayado en el editor.

Personalmente encuentro que es una forma útil de mejorar mi codificación, particularmente cuando se trabaja con una nueva biblioteca que está cubierta por la herramienta de Análisis Estático. Aunque puede ser 'ruidoso' con falsos positivos, o reglas que no te interesan. Pero esto se soluciona dando el paso extra de configurar la herramienta de Análisis Estático para ignorar ciertas reglas.

Corrección de código basada en reglas de análisis estático

Con la mayoría de las herramientas de Análisis Estático, la fijación de la regla se deja al programador, por lo que éste tiene que entender la causa de la violación de la regla y cómo solucionarla.

Muy pocas herramientas de análisis estático incluyen también la posibilidad de corregir las infracciones porque la corrección suele ser contextual al equipo y a la tecnología utilizada y a sus estilos de codificación acordados.

Normas por defecto

La falsa confianza en la calidad de las reglas puede surgir cuando las herramientas de análisis estático vienen con reglas por defecto, es tentador creer que cubren todos los problemas que un programador puede encontrar, y todas las circunstancias en las que esa regla debería aplicarse. A veces, las circunstancias en las que debería aplicarse una regla pueden ser sutiles y no ser fáciles de detectar.

La esperanza es que, al utilizar una herramienta de análisis estático e investigar las reglas y las violaciones con más detalle, los programadores desarrollen la habilidad de detectar y evitar el problema en el contexto de su dominio específico.

Cuando el dominio requiere reglas contextuales, es posible que las herramientas de análisis estático no tengan ninguna regla que coincida con su dominio o biblioteca y, además, las herramientas pueden ser a menudo difíciles de configurar y ampliar.

Molestias

Ninguna de estas "molestias" es insuperable:

• falsos positivos
• falta de arreglos
• configuración para ignorar las reglas
• añadir reglas específicas del contexto

Pero a menudo se utilizan como excusas para evitar el uso de herramientas de Análisis Estático en primer lugar, lo cual es una pena porque el uso del Análisis Estático puede ser enormemente útil, como una forma de:

• destacar los mejores enfoques para los desarrolladores junior
• Obtenga información rápida sobre las infracciones claras de la codificación
• identificar problemas oscuros que el programador no ha encontrado antes
• reforzar que el programador ha adoptado un buen enfoque de codificación (cuando no se denuncian infracciones)

Herramientas de análisis estático basadas en IDE

Como colaborador individual de un proyecto, me gusta utilizar herramientas de análisis estático que se ejecutan desde el IDE para recibir rápidamente información sobre mi código.

Esto complementa cualquier proceso de revisión de solicitudes de extracción y la integración de CI que pueda tener un proyecto.

Intento identificar las herramientas que me dan ventaja y mejoran mi flujo de trabajo individual.

Cuando las herramientas se ejecutan en el IDE, debido a que tienden a compartir la misma interfaz gráfica de usuario y el mismo enfoque de configuración, puede ser tentador verlas indistintamente.

Las herramientas pueden tener funcionalidades o conjuntos de reglas que se solapan, pero para obtener el máximo provecho instalo varias herramientas para aprovechar sus puntos fuertes.

Las herramientas IDE de análisis estático que utilizo activamente cuando codifico se enumeran a continuación:

• las inspecciones incorporadas de IntelliJ - patrones de codificación comunes
• SpotBugs - errores comunes
• SonarLint - patrones de uso comunes
• CheckStyle - patrones de estilo comunes
• Sensei de Secure Code Warrior - creación de reglas personalizadas

Los utilizo todos porque funcionan bien juntos para aumentar y complementar a los demás.

Inspecciones de IntelliJ

Si utiliza IntelliJ entonces ya está utilizando sus Inspecciones.

Son reglas de Análisis Estático que se marcan en el IDE. Algunas de ellas también tienen opciones de QuickFix para reescribir el código y solucionar el problema.

Las reglas son configurables en encendido y apagado, y para elegir el nivel de error utilizado para resaltarlo en el IDE.

Hay un montón de buenas inspecciones de IntelliJ. Lo sé porque las he leído mientras escribía esto. Yo utilizo las inspecciones de IntelliJ por defecto y no las he configurado, pero para obtener todo el valor de las inspecciones deberías leerlas, identificar las que son relevantes para tu estilo de codificación y configurar el nivel de advertencia para que las notes en el código.

Lo bueno de las inspecciones de IntelliJ es que vienen gratis con el IDE y ayudan a construir la memoria muscular de:

• notar las advertencias y los errores en el código fuente mientras se escribe el código
• pasar el ratón por encima del código marcado para conocer las infracciones de las normas
• usando alt+enter para aplicar una solución rápida al problema

SpotBugs

El plugin SpotBugs IntelliJ utiliza el Análisis Estático para tratar de alertarle de los errores en su código.

SpotBugs puede ser configurado desde las Preferencias de IntelliJ para escanear su código, las reglas reales utilizadas se pueden encontrar en la pestaña de Detector.

Suelo utilizar SpotBugs después de haber escrito y revisado mi código, entonces ejecutaré el 'Analyze Project Files Including Test Sources'.

Esto me ayuda a identificar errores, código muerto y optimizaciones obvias. También me obliga a investigar algunas de las violaciones marcadas para ayudarme a decidir qué hacer.

SpotBugs encontrará problemas pero no ofrece ninguna acción de QuickFix para intentar resolverlos.

SpotBugs es fácil de configurar y me parece una segunda opinión objetiva útil para consultar en mi IDE.

SonarLint

El plugin SonarLint.

SonarLint se puede configurar desde las Preferencias de IntelliJ para seleccionar las reglas con las que se valida el código.

Por defecto, SonarLint se ejecuta en tiempo real y muestra los problemas del código actual que se está editando.

SonarLint no ofrece soluciones rápidas, pero la documentación asociada a los informes de infracción suele ser clara y estar bien documentada.

En el pasado, SonarLint me resultó útil para alertarme de las nuevas características de Java que conocía en las nuevas versiones de Java.

CheckStyle

El plugin CheckStyle ofrece una mezcla de reglas de formato y de calidad de código.

El plugin CheckStyle viene con 'Sun Checks' y 'Google Checks'.

Las definiciones de las mismas se pueden encontrar fácilmente en Internet.

CheckStyle añade el mayor valor cuando un proyecto ha dedicado tiempo a crear su propio conjunto de reglas. Entonces el plugin del IDE puede ser configurado para usar ese conjunto de reglas y los programadores pueden realizar un análisis, antes de enviar el código a CI.

CheckStyle se utiliza muy a menudo como un plugin de fallo de construcción para los procesos de CI cuando el número de violaciones de CheckStyle supera un umbral.

Sensei

Sensei utiliza el análisis estático basado en un árbol de sintaxis abstracto (AST) para cotejar el código y crear QuickFixes, lo que permite identificar de forma muy específica el código con problemas.

El AST permite que los QuickFixes asociados a una receta entiendan el código circundante, por ejemplo, cuando se añade una nueva clase en el código, cualquier importación para esa clase sólo se añadirá al archivo fuente una vez, y no para cada sustitución.

Sensei se creó para facilitar la creación de reglas de concordancia personalizadas que pueden no existir, o que serían difíciles de configurar, en otras herramientas. 

En lugar de modificar un archivo de configuración, toda la configuración puede realizarse en la GUI. Al crear nuevas recetas, la interfaz gráfica de usuario permite ver fácilmente a qué código corresponde la receta. Y al definir las QuickFixes se puede comparar inmediatamente el estado del código antes y después. Esto facilita la creación de recetas muy contextuales, es decir, únicas para equipos, o tecnología, e incluso para programadores individuales.

Utilizo Sensei en combinación con otras herramientas de Análisis Estático, por ejemplo, la mayoría de las herramientas de Análisis Estático encontrarán problemas, pero no los arreglarán. Un caso de uso común para Sensei es replicar la búsqueda de coincidencias de la otra herramienta en Sensei, y ampliarla con una corrección rápida. Esto tiene la ventaja de que la corrección personalizada aplicada ya cumple con los estándares de codificación para su proyecto.

Periódicamente me encuentro creando Sensei recetas que ya existen en el conjunto de IntelliJ Intensions porque el informe de Intension no coincide del todo con el contexto que he creado o porque el QuickFix proporcionado por IntelliJ no coincide con el patrón de código que quiero utilizar.

Aumento las herramientas existentes, en lugar de intentar sustituirlas por completo.

Sensei también puede ser muy útil cuando se identifica una variante contextual de una regla común, por ejemplo, si se utiliza una biblioteca SQL no soportada por la herramienta de Análisis Estático, pero las reglas SQL comunes en el motor de Análisis Estático siguen siendo aplicables, entonces se pueden crear variantes específicas de la biblioteca de esas reglas utilizando Sensei.

Sensei no viene de fábrica con un montón de recetas genéricas como las herramientas de análisis estático mencionadas, su punto fuerte es facilitar la creación de nuevas recetas, completas con QuickFixes configuradas para adaptarse a su estilo de codificación y casos de uso específicos.

NOTA: estamos trabajando en un repositorio público de recetas para cubrir casos de uso genéricos, y puede encontrarlo aquí.

Resumen

Tiendo a elegir herramientas que funcionen juntas, que sean configurables y que sean fáciles de ampliar para adaptarse a mi contexto específico. Llevo años utilizando herramientas de análisis estático en el IDE para ayudarme a identificar problemas y aprender más sobre los lenguajes de programación y las bibliotecas que utilizo.

Utilizo todas las herramientas mencionadas en combinación:

• IntelliJ Intentions ayuda a señalar los problemas de código más comunes desde el principio, a menudo con QuickFixes asociados.
• SpotBugs encuentra errores sencillos que podría haber pasado por alto y me avisa de los problemas de rendimiento.
• SonarLint identifica características de Java que desconocía y me indica formas adicionales de modelar mi código.
• CheckStyle me ayuda a ajustarme a un estilo de codificación acordado que también se aplica durante la IC.
• Sensei me ayuda a crear QuickFixes para aumentar los escenarios comunes encontrados por las herramientas de Análisis Estático y crear recetas específicas de proyectos o tecnologías que pueden ser difíciles de configurar en otra herramienta.

---

Instale Sensei desde IntelliJ usando "Preferences \ Plugins" (Mac) o "Settings \ Plugins" (Windows) y luego sólo busque "sensei secure code".

Puedes encontrar un repositorio de código de ejemplo y recetas para casos de uso comunes en la cuenta de GitHub de Secure Code Warrior , en el proyecto `sensei-blog-examples`.

https://github.com/securecodewarrior/sensei-blog-examples

Más información sobre Sensei

El propio proyecto Sensei tiene su propio conjunto de recetas que se han ido construyendo con el tiempo. Esta entrada del blog es un ejemplo de uno de los escenarios para los que el equipo de Sensei construyó una receta. Una configuración errónea de Guice, que llevó a que se reportara una NullPointerException en tiempo de ejecución durante las pruebas.

Esto se puede generalizar a muchos escenarios de Inyección de Dependencia donde el código es sintácticamente correcto, pero debido a que la configuración del cableado era incorrecta, se cuela un error.

Esto suele ocurrir cuando estamos aprendiendo la tecnología, y seguimos cometiendo el simple error de olvidarnos de cablear las cosas. Pero esto también le ocurre a los profesionales con experiencia porque, bueno... todos cometemos errores, y puede que no tengamos Unit Tests para cubrir todo.

Excepciones en tiempo de ejecución por cableado incorrecto de inyección de dependencia

El código siguiente falla en tiempo de ejecución con una NullPointerException.

‍

injector = Guice.createInjector(new SystemOutModule());
CountReporter reporter = injector.getInstance(CountReporter.class);
String [] lines5 = {"1: line", "2: line", "3: line", "4: line", "5: line"};
reporter.reportThisMany(Arrays.asList(lines5));
Assertions.assertEquals(5, reporter.getCount());

El código es sintácticamente correcto, pero falla porque hemos omitido una requestStaticInjection en nuestra configuración de SystemOutModule.

‍

public class SystemOutModule extends AbstractModule {
    @Override
    protected void configure() {
        binder().bind(ILineReporter.class).to(SystemOutReporter.class);
    }
}

Cuando intentamos utilizar el reportero, creado con el Injector, no se instancian completamente y recibimos una NullPointerException cuando llamamos a reportThisMany.

Puede que se nos haya pasado en la revisión del código, o que no hayamos hecho pruebas unitarias que activen la inyección de dependencias, y se nos haya escapado en la compilación.

‍

Señales de advertencia

En este caso, hay una señal de advertencia, el CountReporter tiene un campo estático anotado con @Inject pero... la propia clase CountReporter es paquete privado.

En una base de código complicada, esto podría ser una señal de advertencia de que el código es incorrecto porque la clase del módulo que configura los enlaces debe estar en el mismo paquete para que esto funcione.

‍

class CountReporter {
    @Inject
    private static ILineReporter reporter;

Otro error que cometimos, y que podríamos haber detectado en una revisión de código, es que nos olvidamos de vincular realmente los campos en el método SystemOutModule configure.

binder().requestStaticInjection(CountReporter.class);

Si hubiéramos escrito el código de requestStaticInjection entonces el Error de Sintaxis generado al intentar usar el CountReporter nos habría alertado del simple error.

> 'reporters.CountReporter' no es público en 'reporters'. No se puede acceder desde fuera del paquete

‍

Lamentablemente. Nos olvidamos y no había señales de advertencia sintáctica en el código.

¿Cómo puede ayudar Sensei ?

Probablemente no usaríamos Sensei para recoger el requestStaticInjection que falta, ya que todo nuestro cableado de configuración de Guice necesitaría usar ese método, y no podemos garantizar que todo el cableado vaya a ser tan simple como este caso de uso.

Podríamos escribir una regla en Sensei para buscar algunas señales de advertencia de que nuestro código no está a la altura.

En este caso eso significaría:

• Encontrar cualquier clase con campos anotados @Inject
• Donde las clases no son públicas.

Lo anterior fue la señal de advertencia de que era poco probable que estuvieran conectados.

Al crear una receta, entonces tendremos una señal de alerta temprana, durante la codificación, y reduciremos la dependencia de nuestros pull requests o de la resolución de nuestra deuda tecnológica para permitirnos añadir Unit Tests.

¿Cómo crear una receta?

La tarea que quiero completar es:

• Crear una receta que coincida con los campos anotados con @Inject que están en clases privadas protegidas

Eso debería darnos suficiente aviso para identificar cualquier módulo que lo utilice y añadir el código de cableado que falta.

En mi clase CountReporter, usaré Alt+Enter para crear una nueva receta y empezaré desde cero

Le pondré un nombre y añadiré una descripción:

Nombre: Guice: Campo inyectado no público
Descripción: Si el campo inyectado no es público el código podría no estar conectado
Nivel: Advertencia

La búsqueda que escribo busca una clase con un campo anotado como Inject, pero que no ha sido delimitado como público.

búsqueda:
campo:
con:
anotación:
tipo: "com.google.inject.Inject"
en:
clase:
sin:
modificador: "public"

Fijar

El QuickFix de la receta modificará la clase inyectada cambiando el ámbito. Pero ese no es el único código que tengo que cambiar.

availableFixes:

- nombre: "Cambiar la clase a pública. Recuerda solicitar también la inyección en esta clase"
actions:
- changeModifiers:
visibility: "public"
target: "parentClass"

Cuando la receta se dispara todavía tengo que realizar un paso manual en mi código, añadiendo la línea que contiene requestStaticInjection para instanciar completamente el objeto.

public class SystemOutModule extends AbstractModule {
    @Override
    protected void configure() {
        binder().bind(ILineReporter.class).to(SystemOutReporter.class);
        // instantiate via dependency injection
        binder().requestStaticInjection(CountReporter.class);
    }
}

Potencialmente podría escribir otra receta para recoger esto. Probablemente no lo haría a menos que olvidar añadir la inyección estática se convirtiera en un error semi-regular que cometiera al codificar.

‍

Resumen

Si alguna vez nos encontramos cometiendo un error con un patrón de raíz común, entonces Sensei puede ayudar a codificar el conocimiento en torno a la detección y corrección del problema, y entonces, con suerte, no se deslizará a través de las revisiones de código y en la producción.

A veces, las recetas que escribimos identifican patrones heurísticos, es decir, que su coincidencia no garantiza que haya un problema, pero es probable que lo haya.

Además, las recetas y los QuickFixes que escribimos no tienen que ser totalmente exhaustivos, sino que tienen que ser lo suficientemente buenos como para ayudarnos a identificar y solucionar los problemas sin ser demasiado complicados. Porque cuando se complican en exceso se vuelven más difíciles de entender y de mantener.

---

Puede instalar Sensei desde IntelliJ usando "Preferences \ Plugins" (Mac) o "Settings \ Plugins" (Windows) y luego sólo busque "sensei secure code".

El código fuente y las recetas de este post se encuentran en el repositorio `sensei-blog-examples` de la cuenta de GitHub de Secure Code Warrior , en el módulo `guiceexamples`.

https://github.com/securecodewarrior/sensei-blog-examples

Más información sobre Sensei

Modificación de la visibilidad de métodos y clases para JUnit 5

Una de las alegrías de la programación es el aprendizaje constante que se requiere para mantenerse al día. Uno de los problemas es que acumulamos familiaridad y patrones de uso que pueden afectar a la adopción de nuevos enfoques. Sensei puede ayudar a la migración identificando patrones obsoletos e indicándonos la solución que debemos utilizar en el futuro.

Como ejemplo, cuando migré de JUnit 4 a JUnit 5, estaba acostumbrado a escribir todas mis clases y métodos de prueba como públicos. Pero con JUnit 5 pueden ser paquetes privados.

Por ejemplo, en lugar de:

public class Junit5VisibilityTest {
    @Test
    public void thisDoesNotNeedToBePublic(){
        Assertions.assertTrue(true);
    }
}

Tengo muchas ganas de escribir:

class Junit5VisibilityTest {
    @Test
    void thisDoesNotNeedToBePublic(){
        Assertions.assertTrue(true);
    }
}

Me llevó un tiempo crear la memoria muscular para codificar con esto, y todavía me equivoco de vez en cuando.

Utilizando Sensei

Con Sensei puedo crear recetas que encuentren los métodos y clases públicas, y modifiquen las declaraciones para que sean privadas del paquete automáticamente.

Para ello, he creado una receta:

Nombre - JUnit: Los métodos de prueba de JUnit 5 no necesitan ser públicos
Descripción - Los métodos de prueba de JUnit 5 no necesitan visibilidad pública
Nivel - Error

Lo he clasificado como Error porque quiero acabar con esta práctica de codificación y quiero que el problema sea más visible cuando esté escribiendo código en el IDE.

Modificación de la declaración de clase

Para encontrar las clases, busco cualquier clase que tenga una anotación hija de @Test de Junit 5, es decir, org.junit.jupiter.api.Test

Y donde la clase tiene el modificador public:

search:
class:
with:
child:
annotation:
type: "org.junit.jupiter.api.Test"
modifier: "public"

Entonces la solución rápida cambia el modificador para eliminar la visibilidad para que sea la predeterminada, y la predeterminada es paquete privado que es lo que estoy buscando.

availableFixes:
- name: "remove public visibility from JUnit 5 Test class"
actions:
- changeModifiers:
visibility: ""

Modificación de las declaraciones de métodos

La receta de modificación de la declaración del método es muy parecida a la receta de la clase.

Primero busco los métodos públicos anotados con @Test de JUnit 5.

search:
method:
annotation:
type: "org.junit.jupiter.api.Test"
modificador: "public"

Y luego cambio el modificador para que sea la visibilidad por defecto.

availableFixes:
- name: "Remove @Test method public visibility"
actions:
- changeModifiers:
visibility: ""

Sugerencia: Modificación de varios métodos

Sensei tiene la capacidad de aplicar el QuickFix a todas las violaciones en el archivo actual.

Cuando uso alt+enter para aplicar el QuickFix.

Si despliego el menú de nombres de QuickFix, puedo ver una opción para:

"Arreglar todo: 'JUnit: Los métodos de prueba de JUnit 5 no necesitan ser públicos' problemas en el archivo"

Si selecciono esa opción, Sensei modificará todas las incidencias del problema, no sólo la que yo seleccione.

Modificación de la clase

De la misma manera que un método no necesita ser público, tampoco lo necesita la clase.

Puedo crear una receta y un QuckFix para modificar la clase.

Nombre - JUnit: Las clases de prueba de Junit 5 no necesitan ser públicas
Descripción - Las clases de prueba de Junit 5 no necesitan ser públicas
Nivel - Error

Cuando encuentro una clase que es pública y tiene un método con una anotación @Test. Entonces quiero cambiar la visibilidad.

búsqueda:
clase:
modificador: "public"
anyOf:
- child:
method:
annotation:
type: "Test"

Puedo volver a realizar el cambio en la definición de la clase con la acción changeModifiers.

availableFixes:
- name: "Remove @Test class public visibility"
actions:
- changeModifiers:
visibility: ""

Resumen

Una herramienta de análisis estático me alertó inicialmente de este enfoque recomendado en JUnit. Pero la herramienta de análisis estático no me ayudó a construir la memoria muscular para cambiar mi código mientras programo.

Utiliza el 'Nivel' para alertarte. Cuando se trata de un problema que estoy tratando de eliminar en mi codificación, inicialmente lo pongo como 'Error' y luego lo reduzco a medida que me alejo del enfoque de la codificación.

Recuerde que puede utilizar Sensei para arreglar todos los problemas del archivo actual al mismo tiempo, utilizando la opción del menú desplegable al aplicar el QuickFix.

Al crear una receta en Sensei , puedo ver mi antiguo enfoque de codificación en tiempo real. Y QuickFix, para reforzar el enfoque si de vez en cuando me equivoco en la codificación.

---

Puede instalar Sensei desde IntelliJ usando "Preferences \ Plugins" (Mac) o "Settings \ Plugins" (Windows) y luego sólo busque "sensei secure code".

El código fuente y las recetas para esto se pueden encontrar en el repositorio `sensei-blog-examples` en la cuenta GitHub de Secure Code Warrior , en el módulo `junitexamples`.

• https://github.com/securecodewarrior/sensei-blog-examples

Añadir automáticamente un constructor privado con Sensei

En una clase de utilidad, cuando los campos y métodos son estáticos, no hay ninguna razón obvia por la que la instanciaría.

Por ejemplo, UtilityClass utility = new UtilityClass();

El código siguiente es una implementación sencilla de una clase Utility.

public class UtilityClass {
    public static final Boolean ULTIMATE_TRUTH = true;
    public static boolean getTrue(){
        return ULTIMATE_TRUTH;
    }
}

Este es el tipo de patrón de codificación que las herramientas de análisis estático pueden detectar, pero a menudo no ofrecen la posibilidad de solucionar el problema.

Puedo usar Sensei para identificar el patrón de codificación, y generar automáticamente un constructor privado para que me sea imposible instanciar la clase.

Búsqueda de la clase

Voy a añadir una nueva receta en la clase de Utilidad llamada:

•  Clases estáticas: crear constructor privado.

Y en un principio, crearé un simple matcher para buscar una clase.

buscar:

  class: {}

Esto coincidirá con cualquier clase, lo que es suficiente para permitirme empezar a escribir un Quick Fix. Una vez que tenga un Quick Fix que funcione, perfeccionaré la búsqueda para que destaque cuando sea más probable que haya una clase que requiera un constructor privado.

Solución rápida

Para el Quick Fix, voy a querer generar un constructor privado.

En la clase de ejemplo esto se vería así:

   private UtilityClass(){}

Para añadir el código anterior a mi clase, mi Quick Fix añadirá un Método, y el nombre del método será una plantilla Mustache que utiliza el nombre de la clase.

availableFixes:

- name: "add private constructor"
  actions:
  - addMethod:
      method: "private {{{ name }}}(){}"

En el Editor GUI, utilizo la opción Mostrar Variables para crear la plantilla Bigote y luego edito el campo para añadir el modificador privado, los corchetes y las llaves para que sea sintácticamente correcto.

Esto me permitiría ahora añadir un constructor privado a cualquier clase.

La vista previa de QuickFix me ayuda porque puedo ver el código generado mientras escribo la plantilla Mustache.

Ahora que sé que puedo solucionar el problema. Afinaré las condiciones de búsqueda para mostrar la receta cuando sea más apropiado.

Búsqueda de constructores desaparecidos

Idealmente, no quiero crear una receta que marque un error contra cada clase. Así que voy a añadir algunas condiciones adicionales en la búsqueda para que sólo coincidan en las clases que no tienen un constructor.

buscar:

  clase:
sin:
hijo:
método:
constructor: true

El YAML es ligeramente diferente del GUI.

En la GUI lo configuro para que busque una clase sin un método hijo que sea un constructor 'yes'. Usamos 'yes' en la GUI en lugar de 'true' para hacer la GUI un poco más amigable.

Esta receta ahora sólo se revelará para cualquier clase sin un constructor.

Búsqueda estrecha de los posibles culpables

Así que podría ir más allá y buscar la presencia de métodos o campos estáticos.

Busco cualquier clase sin constructor y que tenga todos los campos estáticos públicos o todos los métodos estáticos públicos.

buscar:

  class:
with:
anyOf:
- child:
method:
allOf:
- modifier: "public"
- modificador: "static"
- child:
field:
allOf:
- modifier: "static"
- modificador: "public"
sin:
child:
method:
constructor: true

Dado que Sensei se utiliza para ayudarme, como programador, en el IDE, más que para analizar estáticamente el código e informar de todos los errores, este filtro es lo suficientemente bueno como para descartar la mayoría de las clases de mi base de código en las que podría tener una buena razón para tener un constructor público por defecto.

En algunos proyectos, esto podría ser un paso demasiado lejos porque las clases de utilidad podrían tener métodos privados, por lo que podría optar por buscar la presencia de "cualquier" método estático público, en lugar de "todos".

       - child:
field:
anyOf:
- modifier: "static"
- modificador: "público"

Consejos

Sensei no está diseñado para sustituir a una herramienta de Análisis Estático. Sensei puede aumentar una herramienta de Análisis Estático para problemas comunes asociados con su proceso de codificación, o tecnología. Reproduciendo una cantidad suficiente de coincidencias para poner de relieve un problema, y apoyando el proceso de desarrollo mediante la generación del código QuickFix.

Lo que trato de hacer es crear una receta lo suficientemente simple que incluya todas las situaciones que necesito, pero filtrarla para que no se sugiera en todas las clases.

Cuando trabajo en las recetas trato de des-riesgarlas, en este caso, no estaba seguro si podía crear el constructor privado así que creé el QuickFix primero. Luego refactoricé las condiciones de búsqueda para hacerlas más específicas.

A veces, cuando trabajo en recetas, no estoy seguro de cómo realizar la búsqueda, así que primero trabajo en eso.

Encuentro que las recetas son más fáciles de crear cuando las construyo de forma incremental, cambiando entre la refacción del QuickFix y la búsqueda.

---

Puedes instalar Sensei desde IntelliJ usando "Preferencias \N-Plugins" (Mac) o "Ajustes \N-Plugins" (Windows) y luego sólo busca "sensei secure code"

El código fuente y las recetas para esto se pueden encontrar en el repositorio `sensei-blog-examples` en la cuenta de GitHub de Secure Code Warrior , en el módulo `pojoexamples`.

https://github.com/securecodewarrior/sensei-blog-examples

‍

Tapjacking, una combinación de "tap" y "hijacking", significa precisamente eso. Se trata de un ataque en el que el atacante secuestra los toques del usuario y lo engaña para que haga algo que no pretendía. Entonces, ¿cómo funciona y cómo lo prevenimos?

Empezamos nuestra historia con las superposiciones de pantalla. Las superposiciones de pantalla o, como Google las llama, las ventanas que utilizan el tipo TYPE_APPLICATION_OVERLAY. Son ventanas que se dibujan encima de otras aplicaciones y normalmente sólo oscurecen una parte de la pantalla. Suelen utilizarse (como la imagen de ejemplo de abajo) cuando una app solicita nuevos permisos.

Esta es una función genial y divertida y cada vez más aplicaciones están empezando a utilizarla, piensa en las burbujas de chat de Facebook, o en la navegación de Google Maps en una esquina de la pantalla, como en la captura de pantalla de abajo.

Sin embargo, hay algunos riesgos de seguridad con estas superposiciones. Cualquier superposición de pantalla activa puede escuchar los toques, ¿de qué otra forma podría saber Facebook que hemos tocado o arrastrado la burbuja? Esto permite que las aplicaciones nos espíen y puedan robar contraseñas y datos de tarjetas de crédito.

Un paso más allá, y de ahí viene el término tapjacking, las superposiciones pueden dibujar cosas encima de otras aplicaciones engañando al usuario para que realice diferentes acciones. El usuario cree que está interactuando con la superposición, pero en realidad sus toques también realizan acciones en la aplicación subyacente. De este modo, la superposición puede engañarle para que habilite ciertos permisos o cambie algunos ajustes peligrosos, como se demuestra en este viejo vídeo de YouTube.

El vídeo de demostración de arriba fue subido a YouTube en 2010, por lo que se hizo en una versión antigua de Android. Pero el ataque sigue siendo relevante hoy en día, ya que salieron a la luz vulnerabilidades que permiten el tapjacking en versiones más recientes de Android como Nougat y Marshmallow.

¿Qué puedes hacer al respecto? Como usuario, es importante darse cuenta de las consecuencias de estas superposiciones y estar atento a las apps que las utilizan. A partir del nivel 23 de la API (Android 6.0 Marshmallow), esto se ha convertido en un permiso que tiene que ser concedido explícitamente por el usuario. Sin embargo, eso deja al 50% de los usuarios de Androidtodavía vulnerables. Todavía puedes comprobar qué aplicaciones hacen uso de este permiso en los ajustes, en "Mostrar sobre otras aplicaciones".

Como desarrolladores, depende de nosotros asegurarnos de que las acciones del usuario se realicen con pleno conocimiento y consentimiento del mismo. Android proporciona un ajuste para sus vistas que hace precisamente eso, llamado filterTouchesWhenObscured. Cuando está activado, el framework descartará los toques que se reciban siempre que la ventana de las vistas esté oscurecida por otra ventana visible. Es tan simple como eso, establece filterTouchesWhenObscured a true, y tu aplicación estará a salvo del tapjacking.

Buena suerte y hasta la próxima semana.

A veces es esencial que una aplicación pueda verificar que una acción se realiza con el pleno conocimiento y consentimiento del usuario, como conceder una solicitud de permiso, realizar una compra o hacer clic en un anuncio. Lamentablemente, una aplicación maliciosa podría intentar engañar al usuario para que realice estas acciones, sin saberlo, ocultando el propósito de la vista.

https://developer.android.com/reference/android/view/View.html

El cifrado del dispositivo es el proceso de cifrar todos los datos del dispositivo Android. Una vez que se habilita para un dispositivo Android, todos los datos creados por el usuario se encriptan inmediatamente antes de que se escriban en el almacenamiento. Esto protege los datos de manera que incluso si cualquier parte no autorizada intenta acceder a los datos, no podrá leerlos. Esta es una característica especialmente buena para los dispositivos de los teléfonos inteligentes, ya que el usuario los lleva consigo y son más propensos a la pérdida o al robo que otros dispositivos informáticos. Cualquier curioso o ladrón no puede acceder a los datos a menos que pueda desbloquear el teléfono.

Android dispone de dos tipos de cifrado del dispositivo: el cifrado de todo el disco y el cifrado basado en archivos.

Cifrado de disco completo

El cifrado de disco completo se introdujo en el nivel 19 de la API (Android 4.4 KitKat), pero las nuevas características del nivel 21 de la API (Android 5.0 Lollipop) realmente impulsaron su uso. El cifrado de disco completo utiliza una única clave para proteger toda la partición de datos de usuario del dispositivo. La clave está protegida con las credenciales del usuario y deben proporcionarse en el arranque antes de que se pueda acceder a cualquier parte del disco.

Esto es genial para la seguridad, pero también significa que la mayor parte de la funcionalidad del dispositivo no está disponible hasta que el usuario introduzca sus credenciales. Esto significa que cuando el dispositivo se reinicia pero no se desbloquea, algunas funciones como las alarmas no pueden funcionar, los servicios no están disponibles y los teléfonos no pueden recibir llamadas. Por esta razón se creó el segundo modo de encriptación.

Cifrado basado en archivos

El cifrado basado en archivos, el segundo modo de cifrado del dispositivo, está disponible desde el nivel 24 de la API (Android 7.0 Nougat). En este modo, se encriptan diferentes archivos con diferentes claves que se pueden desbloquear de forma independiente. Con este modo de cifrado llegó el modo de arranque directo, que permite a los dispositivos cifrados arrancar directamente en la pantalla de bloqueo, habilitando las funciones que antes no existían antes de desbloquear el dispositivo.

El arranque directo permite que las aplicaciones funcionen en un contexto limitado antes de que se desbloquee el dispositivo. De este modo, pueden seguir funcionando como se espera sin comprometer la información del usuario. Para ofrecer esta funcionalidad, el dispositivo Android necesita dos ubicaciones de almacenamiento:

1. Almacenamiento cifrado de credenciales. Ubicación de almacenamiento por defecto, sólo disponible después de que el usuario haya desbloqueado el dispositivo.
2. Almacenamiento cifrado del dispositivo. Disponible en el modo de arranque directo, y después de que el usuario haya desbloqueado el dispositivo.

Si tu aplicación necesita acceder a los datos mientras se ejecuta en modo de arranque directo, debería utilizar el almacenamiento cifrado del dispositivo. Pero ten en cuenta las implicaciones de seguridad. El almacenamiento encriptado del dispositivo no debe utilizarse para almacenar datos sensibles. El almacenamiento encriptado por el dispositivo está encriptado con una clave que está disponible tan pronto como el dispositivo haya arrancado con éxito. Todos los datos a los que sólo debe acceder el usuario deben guardarse en la ubicación predeterminada, el almacenamiento cifrado de credenciales.

Si quieres saber más sobre qué es el cifrado o por qué es importante, consulta el vídeo del portal Secure Code Warrior . O puedes intentar poner a prueba tus conocimientos sobre encriptación jugando a algunos retos.

¿Necesitas una guía paso a paso para tu dispositivo? Consulta este artículo de Bill Hess en Pixel Privacy.

Espero que hayas aprendido algo nuevo. Hasta la próxima semana!

Almacenamiento cifrado de credenciales, que es la ubicación de almacenamiento por defecto y sólo está disponible después de que el usuario haya desbloqueado el dispositivo.

https://developer.android.com/training/articles/direct-boot.html