Comprensión de la deserialización insegura de OWASP 2017 A8

Question

Comprensión de la deserialización insegura de OWASP 2017 A8

#1 de deviantfan (1 votos)

0

Estoy leyendo sobre Insecure Deserialization y recordé una vulnerabilidad sobre la que leí en algunas implementaciones de JSON Web Token (JWT) en auth0.

enlace

En pocas palabras, se usa el algoritmo "ninguno", se elimina la firma y la aplicación cree que todo lo que el usuario envíe está bien. ¿Caería esto bajo Insecure Deserialization o Using Components with Known Vulnerabilities ? El ejemplo dado podría ser, por supuesto, Broken Access Control , pero dado que el usuario controla el objeto, también podría manipular el sistema de otras maneras.

enlace

{"alg":"HS256","typ":"JWT"}.{ "admin": false, "name": "John Doe", "iat": 1516239022}.signature

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhZG1pbiI6ZmFsc2UsIm5hbWUiOiJKb2huIERvZSIsImlhdCI6MTUxNjIzOTAyMn0.lN5mCX6BnfgtoRVHVaTt9hcj3VUcHWAwdnTT-PLca3c

{"alg":"none","typ":"JWT"}.{ "admin": true, "name": "John Doe", "iat": 1516239022}.signature

eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJhZG1pbiI6dHJ1ZSwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.

Los ejemplos que encuentro son de PHP, Python y Java y algunas descripciones indican que JSON o XML no son parte de la clasificación.

Sin embargo, muchos lenguajes de programación ofrecen una capacidad nativa para Serialización de objetos. Estos formatos nativos suelen ofrecer más características. que JSON o XML, incluida la personalización de la serialización proceso. Desafortunadamente, las características de estos nativos de deserialización. Los mecanismos pueden ser reutilizados para efectos maliciosos cuando se opera en datos no fiables. Se han encontrado ataques contra deserializadores para permitir Ataques de denegación de servicio, control de acceso y ejecución remota de código.

enlace

Sí, la vulnerabilidad es más importante que la clasificación, pero todavía estoy interesado en las clasificaciones correctas.

owasp owasp-top-ten

pregunta Ogglas 11.07.2018 - 16:41

fuente

1 respuesta

Lea otras preguntas en las etiquetas owasp owasp-top-ten

¿Cómo ver con seguridad películas pirateadas, abrir archivos infectados? Entendiendo los prefijos de la suite de cifrado

score 1 · Accepted Answer

Tldr: No siempre es posible distinguir claramente entre clases de vulnerabilidad.

Para ver primero la "serialización insegura" de una manera diferente:
A partir de la descripción, Owasps "serialización insegura" es un poco de una mezcla confusa de (imo) 3 problemas separados:

Para una primera subsección específica de valores de entrada no confiables , a quién le importan los formatos de serialización. En su bloque de código, el problema es el admin, true (y el servidor que cree en este valor), nada más. Si está solo, fuera de cualquier Json, etc., sigue siendo el mismo problema.
Entrada no confiable, pero otra sección: Intercambio de código (clases, métodos ...). Si hay alguna inyección de dependencia en marcha para un EncryptionAlgorithmInterface , y las implementaciones disponibles son None , DES , AES256 y así sucesivamente. ¿Qué podría hacer con el objeto serializado? Cambiando el algoritmo a ninguno y luego busque un lugar donde pueda leer los datos mientras envío por Internet.
Problemas por definición en el propio serializador. ¿Qué sucede si se envía un flujo interminable de [[[[[[[[[[[[... [] a un servicio web que espera a Json? ”). ] nunca son enviados)? Una implementación simple alcanzará rápidamente un desbordamiento de pila (error, no sitio web), que bloquea el proceso del servidor.

El enlace de token web de Json ...

es al menos una entrada no confiable.
También es (Owasps) serialización insegura, pero en realidad, a quién le importa, el problema no es el formato de datos.
Después de que se escribió la explicación, también se convirtió en "componentes en ejecución con vulnerabilidades conocidas".
No en Owasps Top10, pero también es un problema de definición de protocolo.
...

Finalmente, acerca de la parte de la serialización nativa que ofrece más que Json, etc .: Bueno, parcialmente, pero esto no es así, por ejemplo. Versión de PHP segura.

En Java es posible tomar un objeto, escribir su estado completo en una matriz de bytes (es decir, el contenido de la variable miembro actual (tanto tipos simples como otros objetos), pero también código binario ejecutable en algunas situaciones, etc.) y luego vuelva a crear todo desde esta matriz de bytes. El acceso a un método Java serializado que se ejecutará más adelante es, por supuesto, muy bueno para hacer cosas malas. Y si no hay ninguno, introducir uno que se llamará debido a su nombre en algún momento (por ejemplo, es igual a) también es fácil.

En PHP, no existe una forma tan sencilla de guardar y cargar partes de código ejecutable como el tiempo de ejecución las tiene en la memoria, por lo que no es posible abusar de ellas. Sin embargo , los nombres de otros métodos para llamar pueden estar ahí. Eso no es tan conveniente, pero sigue siendo bueno.