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

Esta semana vamos a hablar del comportamiento por defecto de las librerías Zip. Si eres un desarrollador de aplicaciones, es muy probable que hayas utilizado esto antes. La mayoría de los recursos que se descargan por internet están en formato zip, esto tiene sentido; los datos comprimidos son más pequeños, por lo que se descargan más rápido y consumen menos ancho de banda.

Si quieres algunos ejemplos más concretos: texturas para juegos, paquetes de idiomas para autocompletar en los teclados, ... Muchos recursos no se incluyen automáticamente en la aplicación, sino que se descargan posteriormente.

Pero tenga cuidado al usar esta funcionalidad, los nombres de los archivos en zip pueden contener información de recorrido. Cuando se extrae, esto hará que se creen archivos fuera del directorio previsto. Esto se hace a menudo con la intención de sobrescribir los archivos existentes.

Digamos que tenemos un archivo zip que contiene los siguientes dos archivos:

archivo1
../archivo2

Cuando se extrae este archivo, el archivo1 se extrae donde esperamos que esté, en el directorio de descompresión. Sin embargo, el archivo2 fue escrito un directorio más arriba de donde le pedimos a la biblioteca zip que extrajera el archivo.

Así que tenga cuidado, si su librería zip no tiene cuidado de manejar adecuadamente este caso, permitirá a un atacante escribir un archivo arbitrario en el sistema. Compruebe siempre si su librería es segura, esta regla general es válida para cualquier librería, pero en particular sabe comprobar el comportamiento por defecto de su librería zip para este tipo de archivos.

Vamos a demostrar las consecuencias cuando este caso no se maneja correctamente en Android. En Android se utiliza la librería Java Zip (java.util.zip), que permite recorrer la ruta como se ha explicado anteriormente por defecto.

El formato Dalvik Executable (.dex) de Android tiene limitaciones en cuanto a la cantidad de clases que puede tener un solo archivo. Las aplicaciones que necesitan más clases pueden hacer uso de la librería MultiDex Support que se ha añadido desde el nivel 21 de la API (Android 5.0 Lollipop). Esta librería guarda archivos .dex secundarios en el directorio de datos de la aplicación, este directorio es escribible por el usuario de la app y este código será cargado y ejecutado cuando el archivo .dex sea necesario.

Esto significa que un atacante puede modificar el archivo .dex sobrescribiéndolo mediante un archivo zip malicioso y, lo que es peor, este archivo se cargará y se ejecutará, dando lugar a una vulnerabilidad de ejecución remota de código. Esto no es sólo un ejemplo teórico, sino que se ha demostrado en la aplicación My Talking Tom, que tiene más de 100 millones de descargas en la tienda de aplicaciones. Aquí hay un vídeo del exploit que se presentó en Black Hat.

Compruebe siempre el comportamiento de su biblioteca zip para conocer sus inseguridades. Si no puedes desactivar el path traversal en tu librería zip, asegúrate de validar el nombre de cada entrada antes de extraerla. El nombre debería estar canonizado y la ruta resultante debería estar en el directorio en el que quieres extraer el archivo. Ya que estamos, también deberías comprobar el tamaño total del archivo extraído para evitar las bombas zip, pero esto será un post para otra semana.

Si quieres jugar a algunos retos sobre el cruce de caminos o quieres poner a prueba tus habilidades de codificación segura, echa un vistazo a nuestra plataforma.

Nos vemos la próxima vez, y recuerda, ¡con código seguro o sin código!

- Podemos inyectar un archivo en un zip cuyo nombre esté prefijado con un número arbitrario de " ../ "
- Si la librería zip no tiene cuidado de manejar adecuadamente este caso, nos permitiría escribir fuera del directorio de extracción previsto
- Si el archivo zip no es de confianza, esto da al atacante una vulnerabilidad de escritura arbitraria

https://www.blackhat.com/docs/ldn-15/materials/london-15-Welton-Abusing-Android-Apps-And-Gaining-Remote-Code-Execution.pdf

El Lenguaje de Marcas Extensible (XML) es un lenguaje de marcas utilizado para codificar documentos en un formato fácil de manejar para las máquinas y legible para el ser humano. Sin embargo, este formato tan utilizado incluye múltiples fallos de seguridad. En esta primera entrada del blog relacionada con XML, explicaré los fundamentos del manejo de documentos XML de forma segura mediante el uso de un esquema.

OWASP divide las diferentes vulnerabilidades relacionadas con XML y los esquemas XML en dos categorías.

Documentos XML mal formados

Los documentos XML malformados son documentos que no siguen las especificaciones XML del W3C. Algunos ejemplos que dan lugar a un documento malformado son la eliminación de una etiqueta de finalización, el cambio de orden de diferentes elementos o el uso de caracteres prohibidos. Todos estos errores deberían dar lugar a un error fatal y el documento no debería sufrir ningún tratamiento adicional.

Para evitar las vulnerabilidades causadas por los documentos malformados, debe utilizar un analizador XML bien probado que siga las especificaciones del W3C y que no tarde mucho en procesar los documentos malformados.

Documentos XML no válidos

Los documentos XML inválidos están bien formados pero contienen valores inesperados. En este caso, un atacante puede aprovecharse de las aplicaciones que no definen correctamente un esquema XML para identificar si los documentos son válidos. A continuación puede encontrar un ejemplo sencillo de un documento que, si no se valida correctamente, podría tener consecuencias no deseadas.

Una tienda web que almacena sus transacciones en datos XML:

   <purchase></purchase>
     <id>123</id>
     <price>200</price>
   

And the user only has control over the <id> value. It is then possible, without the right counter measures, for an attacker to input something like this:</id>

   <purchase></purchase>
     <id>123</id>
     <price>0</price>
     <id></id>
     <price>200</price>
   

If the parser that processes this document only reads the first instance of the <id> and <price> tags this will lead to unwanted results. </price></id>

También es posible que el esquema no sea lo suficientemente restrictivo o que otras validaciones de entrada sean insuficientes, de modo que se puedan introducir números negativos, decimales especiales (como NaN o Infinito) o valores excesivamente grandes donde no se esperan, lo que lleva a un comportamiento similar no deseado.

Para evitar las vulnerabilidades relacionadas con los documentos XML no válidos se debe definir un esquema XML preciso y restrictivo para evitar problemas de validación de datos inadecuados.

En la próxima entrada del blog nos adentraremos en algunos ataques más avanzados a documentos XML como los Jumbo Payloads y el temido Top Ten de OWASP número cuatro, XXE.

Mientras tanto, puede perfeccionar o desafiar sus habilidades en la validación de entradas XML en nuestro portal.

Las especificaciones para XML y los esquemas XML incluyen múltiples fallos de seguridad. Al mismo tiempo, estas especificaciones proporcionan las herramientas necesarias para proteger las aplicaciones XML. Aunque utilicemos los esquemas XML para definir la seguridad de los documentos XML, pueden utilizarse para realizar diversos ataques: recuperación de archivos, falsificación de peticiones del lado del servidor, escaneo de puertos o fuerza bruta.

https://www.owasp.org/index.php/XML_Security_Cheat_Sheet

El fallo de registro y supervisión insuficiente se produce principalmente como resultado de un plan de ciberseguridad fallido en lo que respecta al registro de todos los intentos de autenticación fallidos, accesos denegados y errores de validación de entradas. Puede ocurrir en otros puntos del entorno de producción, pero está más asociado a un fallo en la detención de los intentos de inicio de sesión no válidos.

Es una vulnerabilidad peligrosa porque significa que los equipos de ciberseguridad no responderán a los ataques porque no los conocen. Esto da a los atacantes una gran ventaja, permitiéndoles pasar desapercibidos mientras intentan penetrar más en un sistema o mejorar sus credenciales. De hecho, sin un registro y una supervisión adecuados, resulta muy difícil, o incluso imposible, detectar y detener los ataques antes de que puedan causar un daño significativo.

¿Listo para poner a prueba tus habilidades con un desafío ahora mismo? Mira esto:

¿Cómo se aprovechan los atacantes de la insuficiencia de registro y supervisión?

Cualquier API es vulnerable a un registro y supervisión insuficientes si el nivel de registro no se establece correctamente, si se establece demasiado bajo, si los mensajes de error no incluyen suficientes detalles o si no hay ninguna función de registro.

Un ejemplo interesante sería que un hacker obtuviera una gran lista de nombres de usuario comprometidos para un sitio web o servicio. Mediante la experimentación, podrían averiguar que se necesitan tres intentos fallidos de inicio de sesión antes de que se bloquee el sistema, y antes de que se notifique al personal de ciberseguridad.

Armados con esta información, en lugar de tratar de forzar cuentas individuales, podrían escribir un script para tratar de iniciar sesión como cada nombre de su lista comprometida utilizando contraseñas comunes como "123456" o "contraseña". El truco es que sólo intenten cada nombre de usuario una vez, o quizás dos, manteniéndose por debajo del umbral de bloqueos y alertas. Si tienen suerte, comprometerán al menos unas cuantas contraseñas de entrada. Después, simplemente esperan un día a que el contador de inicios de sesión se restablezca y vuelven a ejecutar el proceso utilizando contraseñas diferentes como "qwerty" o "god". Si los administradores nunca detectan lo que están haciendo, los atacantes pueden pasar por la lista muchas veces y finalmente comprometer la mayoría de las cuentas con contraseñas débiles.

Esto sucedió en el ejemplo suministrado por OWASP, en el que una plataforma para compartir vídeos fue atacada mediante un ataque de relleno de credenciales que explotaba la vulnerabilidad de registro y monitorización insuficiente. Hasta que la empresa empezó a recibir quejas de los usuarios, no tenía ni idea de que el ataque estaba ocurriendo. Finalmente, encontraron pruebas en los registros de la API, y tuvieron que emitir una notificación de cambio forzado de contraseña a todos sus usuarios, así como informar del ataque a las autoridades reguladoras.  

Eliminación de la vulnerabilidad del registro y la supervisión insuficientes

La automatización y la supervisión constante pueden ayudar a poner fin a esta vulnerabilidad. Para empezar, hay que registrar todos los intentos de autenticación fallidos. Y ese registro debe ponerse en un formato legible por la máquina, como STIX y TAXII, de modo que pueda introducirse en un sistema de gestión de eventos e información de seguridad (SIEM) que esté capacitado para buscar ataques independientemente de los umbrales utilizados.

También debe proteger sus archivos de registro. Trátelos como información sensible y protéjalos de la eliminación o modificación por parte de los atacantes. Una buena política es hacer una copia de seguridad de los archivos de registro y cifrarlos.

Por último, cree cuadros de mando y alertas personalizados para poder detectar cualquier actividad sospechosa y responder a ella lo antes posible. Si se elimina el tiempo que un atacante pasa con el sistema, se elimina su capacidad de utilizar técnicas de ataque bajas y lentas para no ser detectado.

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.

Desde 2015, hemos estado involucrando a los desarrolladores de todo el mundo con un enfoque proactivo y positivo hacia la seguridad, ayudándoles a construir las habilidades para asegurar su código, reducir el retrabajo y la remediación, y con suerte ver el equipo de seguridad como algo más que la policía de la diversión.

Seguimos comprometidos a estar al lado de los desarrolladores para que aseguren el código en toda la galaxia, pero es hora de cambiar las cosas y llevar a nuestros desarrolladores, curtidos en la batalla y conscientes de la seguridad, al siguiente nivel.

Estamos encantados de anunciar una nueva función en la plataforma Secure Code Warrior : Missions. Esta nueva categoría de retos es la siguiente fase de la formación en seguridad adaptada a los desarrolladores, que hace que los usuarios pasen de recordar los conocimientos de seguridad a aplicarlos en un entorno de simulación del mundo real. Este enfoque de microaprendizaje basado en el andamiaje crea potentes habilidades de codificación segura que son relevantes para el trabajo, y mucho más entretenidas que (verticalmente) ver interminables vídeos de formación en el fondo de un día de trabajo.

Nuestra primera misión jugable y pública es una simulación de la violación de GitHub Unicode. Puede parecer engañosamente simple, pero es una vulnerabilidad realmente inteligente que es divertida de diseccionar. El investigador de seguridad 0xsha hizo un estudio exhaustivo sobre cómo este mismo fallo puede utilizarse para explotar Django mediante transformaciones de casos, al tiempo que revela cómo el comportamiento de la vulnerabilidad puede cambiar entre lenguajes de programación. Hay mucho más que descubrir sobre este problema de seguridad, y nuestra misión es un gran lugar para empezar.

Colisión frontal de GitHub (mapeo de casos)

En una publicación del blog del 28 de noviembre de 2019, el grupo de investigación de seguridad Wisdom informó sobre un error de seguridad que descubrieron en GitHub. Describieron cómo pudieron utilizar una colisión de mapeo de casos en Unicode para desencadenar el envío de un correo electrónico de restablecimiento de contraseña a una dirección de correo electrónico incorrecta (o, si pensamos como un atacante, a una dirección de correo electrónico elegida por el actor de la amenaza).

Aunque una vulnerabilidad de seguridad nunca es una buena noticia, los investigadores de seguridad que se dedican al sombrero blanco proporcionan algo de piedad -por no mencionar la oportunidad de evitar un desastre- si descubren errores potencialmente explotables en una base de código. Sus blogs e informes a menudo son una gran lectura, y es genial aprender sobre una nueva vulnerabilidad y cómo funciona.

Para pasar al siguiente nivel de destreza en la codificación segura, es inmensamente poderoso no sólo encontrar las vulnerabilidades comunes (especialmente las nuevas y geniales - todos sabemos que los actores de amenazas maliciosas estarán buscando terreno fértil para desenterrar algunos datos con estas nuevas técnicas) sino también tener un entorno seguro y práctico para entender cómo explotarlas.

Así que vamos a hacer precisamente eso. Sigue leyendo para descubrir cómo se puede explotar una colisión de mapeo de casos en Unicode, cómo se ve en tiempo real y cómo puedes adoptar la mentalidad de un investigador de seguridad y probarlo por ti mismo.

¿Preparado para enfrentarte a una colisión de mapas de casos ahora mismo? Acércate:

Unicode: Complejo, infinitamente personalizable y más que emojis

Puede que "Unicode" no esté en el léxico de la persona media, pero es muy probable que la mayoría de la gente lo utilice de alguna forma cada día. Si has utilizado un navegador web, cualquier programa de Microsoft o has enviado un emoji, entonces has estado cerca de Unicode. Se trata de un estándar para la codificación y el manejo coherente del texto de la mayoría de los sistemas de escritura del mundo, que garantiza que todo el mundo pueda expresarse (digitalmente) utilizando un único conjunto de caracteres. En la actualidad, hay más de 143.000 caracteres, así que estás cubierto tanto si utilizas el islandés como el turco sin puntos, o cualquier otro.

Debido al enorme volumen de caracteres que tiene Unicode en su conjunto, en muchos casos se necesita una forma de convertir los caracteres a otro carácter "equivalente". Por ejemplo, parece sensato que si se convierte una cadena Unicode con un punto sin a ASCII, que simplemente se convierta en una "i", ¿verdad?

Un gran volumen de codificación de caracteres conlleva un gran potencial de desastre

Una colisión de mapeo de casos en Unicode es un fallo de lógica de negocio, y en su esencia, puede llevar a una toma de posesión de cuentas no protegidas por 2FA. Para ilustrar la vulnerabilidad en cuestión, veamos un ejemplo de este fallo en un fragmento de código real:

app.post(/api/resetPassword, function (req, res) {
  var email = req.body.email;
  db.get(SELECT rowid AS id, email FROM users WHERE email = ?, [email.toUpperCase()],
      (err, user) => {
          if (err) {
              console.error(err.message);
              res.status(400).send();
          } else {
              generateTemporaryPassword((tempPassword) => {
                  accountRepository.resetPassword(user.id, tempPassword, () => {
                      messenger.sendPasswordResetEmail(email, tempPassword);
                      res.status(204).send();
                  });
              });
          }
      });
});

La lógica es algo así:

1. Acepta la dirección de correo electrónico proporcionada por el usuario, y la pone en mayúsculas por coherencia
2. Comprueba si la dirección de correo electrónico ya existe en la base de datos
3. Si lo hace, entonces establecerá una nueva contraseña temporal (esto no es la mejor práctica, por cierto. En su lugar, utiliza un enlace con un token que permita restablecer la contraseña)
4. A continuación, envía un correo electrónico a la dirección obtenida en el paso 1, con la contraseña temporal (esto es una práctica muy mala, por muchas razones.)

Veamos qué ocurre con el ejemplo proporcionado en la entrada original del blog, en el que un usuario solicita un restablecimiento de la contraseña para el correo electrónico John@GıtHub.com (nótese la i turca sin puntos):

1. La lógica convierte John@Gıthub.com en JOHN@GITHUB.COM
2. Lo busca en la base de datos y encuentra el usuario JOHN@GITHUB.COM
3. Genera una nueva contraseña y la envía a John@Gıthub.com

Tenga en cuenta que este proceso termina enviando el correo electrónico altamente sensible a la dirección de correo electrónico equivocada. Uy!

Cómo expulsar a este demonio de Unicode

Lo interesante de esta vulnerabilidad específica es que hay múltiples factores que la hacen vulnerable:

1. El comportamiento real de la fundición de Unicode
2. La lógica que determina la dirección de correo electrónico a utilizar, es decir, la dirección de correo electrónico proporcionada por el usuario, en lugar de la que ya existe en la base de datos.

En teoría, se puede solucionar este problema específico de dos maneras, como se indica en la entrada del blog de Wisdom:

1. Convertir el correo electrónico a ASCII con la conversión Punycode
2. Utilizar la dirección de correo electrónico de la base de datos, en lugar de la proporcionada por el usuario

Cuando se trata de endurecer el software, es una gran idea no dejar nada al azar, empleando tantas capas de defensa como sea posible. Por lo que sabemos, puede haber otras formas de explotar esta codificación, sólo que aún no las conocemos. Todo lo que pueda hacer para disminuir el riesgo y cerrar las ventanas que puedan quedar abiertas para un atacante es valioso.

¿Listo para probarlo por ti mismo?

La mayoría de los desarrolladores son conscientes de que los datos comprometidos son malos para el negocio. Sin embargo, los ingenieros conscientes de la seguridad son un poderoso antídoto contra las crecientes vulnerabilidades, brechas y problemas de ciberseguridad.

Es hora de llevar tus habilidades de codificación segura y de concienciación al siguiente nivel. Experimenta esta vulnerabilidad de GitHub en una simulación inmersiva y segura, en la que podrás ver el impacto de un mal código en contextos tanto de frontend como de backend. Los atacantes tienen ventaja, así que vamos a igualar el campo de juego y aplicar las habilidades reales con un contragolpe de sombrero blanco.

Aunque la mayoría de las vulnerabilidades de esta lista son bastante específicas de las APIs, el problema de las funciones de seguridad deshabilitadas/funciones de depuración habilitadas/permisos inadecuados es uno que puede atacar en cualquier lugar. Es probable que sea un poco más frecuente en las APIs, pero los atacantes a menudo intentarán encontrar fallas sin parches y archivos o directorios desprotegidos en cualquier parte de una red. Encontrarse con una API que tenga la depuración activada o las funciones de seguridad desactivadas sólo facilita un poco su nefasto trabajo. Peor aún, existen herramientas automatizadas para detectar y explotar las desconfiguraciones de seguridad, por lo que si las tienes en tu entorno, hay muchas posibilidades de que sean explotadas, razón por la cual esta vulnerabilidad entró en la lista OWASP de fallos peligrosos de API.

Antes de entrar en la diversión, vea si puede resolver este desafío de depuración:

¿Cómo se cuela en una API el fallo de las funciones de seguridad deshabilitadas/las funciones de depuración habilitadas/los permisos inadecuados?

Para ver cómo esta falla multidimensional de la API se agrega a las redes, debemos desglosarla en sus partes componentes. Empecemos por el problema de las funciones de depuración habilitadas. La depuración es una herramienta útil que ayuda a los desarrolladores a averiguar por qué las aplicaciones no funcionan correctamente o cometen errores. Con la depuración activada, los errores y las excepciones generan páginas de error detalladas para que los desarrolladores puedan ver lo que salió mal y solucionar los problemas. Es perfectamente correcto tener esto activo mientras una aplicación está todavía en desarrollo.

Sin embargo, hay una razón por la que la mayoría de los frameworks vienen con advertencias sobre la ejecución del modo de depuración en un entorno de producción, probablemente justo en el código donde se activa la depuración. Por ejemplo:

# ADVERTENCIA DE SEGURIDAD: ¡no ejecutar con la depuración activada en producción!
DEBUG = True

En este ejemplo, se ha activado la depuración. La aplicación Django generará páginas de error detalladas cuando se produzca una excepción. Si esto se hace en un entorno de producción, un adversario tendría acceso a estas páginas de error, que incluyen información de metadatos sobre el entorno. Aunque la mayoría de los frameworks tienen la depuración desactivada por defecto, es fácil olvidarse de volver a desactivarla si se activa durante un largo proceso de desarrollo. Luego, cuando la aplicación se traslada a un entorno de producción, proporciona a los atacantes mucha información sobre cómo comprometer una aplicación, o incluso un servidor o una red entera.

Mientras que la activación del modo de depuración es en su mayoría un problema independiente, las vulnerabilidades de los permisos inadecuados y las características de seguridad deshabilitadas a menudo funcionan juntas. Por ejemplo, en un escenario real proporcionado por OWASP, un atacante utilizó un motor de búsqueda para encontrar una base de datos que estaba conectada accidentalmente a Internet. Como el popular sistema de gestión de bases de datos estaba utilizando su configuración por defecto, la autenticación estaba deshabilitada. Así, combinando las vulnerabilidades de los permisos inadecuados y las características de seguridad deshabilitadas, el atacante obtuvo acceso a millones de registros con PII, preferencias personales y datos de autenticación.

Eliminación de las funciones de seguridad deshabilitadas/funciones de depuración habilitadas/permisos inadecuados

Probablemente, para eliminar esta vulnerabilidad, se necesita un enfoque doble. Para eliminar la parte de depuración habilitada del problema, simplemente añada una comprobación al proceso de desarrollo para asegurarse de que la depuración está deshabilitada antes de mover una API o aplicación al entorno de producción. Desde nuestro ejemplo, el comando adecuado para hacerlo sería el siguiente:

# ADVERTENCIA DE SEGURIDAD: ¡no ejecutar con la depuración activada en producción!
DEBUG = False

Ahora las características de depuración en la aplicación Django están deshabilitadas con la bandera DEBUG configurada en False. No se generarán páginas de error en respuesta a los errores. Si un adversario aún logra acceder a las páginas de error, éstas no contendrán ningún metadato útil, y no supondrán un riesgo para la aplicación.

Eliminar las características de seguridad deshabilitadas y las vulnerabilidades de permisos inadecuados es un poco más difícil porque pueden abarcar una amplia gama de vulnerabilidades específicas. La mejor manera de detenerlas es desarrollar un proceso estándar y repetible que permita el despliegue rápido y sencillo de activos bloqueados en el entorno de producción.

Incluso entonces, debería crear un proceso en el que los archivos de orquestación, los componentes de la API y los servicios en la nube, como los permisos de los cubos de Amazon S3, se revisen y actualicen constantemente. Esta revisión también debería evaluar la eficacia general de la configuración de seguridad en todo el entorno a lo largo del tiempo para asegurarse de que la organización siempre está mejorando la seguridad de su API.

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.