Las 10 mejores API de la serie OWASP de Coders Conquer Security: asignación masiva
La vulnerabilidad de asignación masiva nació porque muchos marcos modernos alientan a los desarrolladores a usar funciones que vinculan automáticamente la entrada de los clientes a variables de código y objetos internos. Esto se hace para simplificar el código y acelerar las operaciones.
Los atacantes pueden usar esta metodología para forzar cambios en las propiedades de los objetos que un cliente nunca debería actualizar. Normalmente, esto se traduce en problemas específicos de la empresa, como que un usuario se añada privilegios de administrador en lugar de cerrar un sitio web o robar secretos corporativos. Los atacantes también deben tener alguna idea de las relaciones entre los objetos y la lógica empresarial de la aplicación que están explotando.
Sin embargo, nada de eso hace que la vulnerabilidad de asignación masiva sea menos peligrosa en manos de un usuario inteligente y malintencionado.
Antes de comenzar con la guía completa, juega a nuestro desafío gamificado y comprueba cómo te va:
¿Cómo pueden los atacantes aprovechar la vulnerabilidad de asignación masiva?
El escenario propuesto por OWASP (y modificado ligeramente por nosotros) supone una aplicación para compartir viajes que incluye diferentes propiedades vinculadas a objetos en el código mediante la asignación masiva. Entre ellas se incluyen las propiedades relacionadas con los permisos que los usuarios pueden cambiar y las propiedades dependientes del proceso que la aplicación solo debe establecer internamente. Ambas utilizan la asignación masiva para vincular propiedades a objetos.
En este escenario, la aplicación de transporte compartido permite a los usuarios actualizar sus perfiles, como es habitual en muchas aplicaciones orientadas al usuario. Esto se hace mediante una llamada a la API enviada a PUT, que devuelve el siguiente objeto JSON:
{"user_name» :"SneakySnake», «edad» :17, «is_admin» :false}
Como el atacante, el Sr. SneakySnake en este caso, ha descubierto la relación entre las propiedades y los objetos, puede volver a enviar su solicitud original para actualizar su perfil con la siguiente cadena:
{"user_name» :"SneakySnake», «edad» :24, «is_admin» :true}
Como el punto final es vulnerable a la asignación masiva, acepta la nueva entrada como válida. Nuestro hacker no solo añadió algunos años a su perfil, sino que también se asignó privilegios de administrador.
Eliminar la vulnerabilidad de la asignación masiva
Por muy conveniente que sea usar la función de asignación masiva en algunos marcos, debes evitar hacerlo si quieres mantener tus API seguras. En su lugar, analiza los valores de las solicitudes en lugar de vincularlos directamente a un objeto. También puede usar un objeto de transferencia de datos reducida, lo que proporcionaría casi la misma comodidad que vincularlo directamente al objeto en sí, solo que sin el riesgo asociado.
Como medida de precaución adicional, las propiedades sensibles, como los privilegios de administrador del ejemplo anterior, podrían denegarse para que el servidor nunca las acepte en una llamada a la API. Una idea aún mejor sería denegar todas las propiedades de forma predeterminada y, a continuación, permitir las propiedades específicas y no confidenciales que quieras que los usuarios puedan actualizar o cambiar. Hacer cualquiera de estas cosas puede ayudar a bloquear las API y eliminar la vulnerabilidad de asignación masiva de su entorno.
Eche un vistazo a la Secure Code Warrior páginas de 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 otras fallas de seguridad. También puedes prueba una demo de la plataforma de formación Secure Code Warrior para mantener todas sus habilidades de ciberseguridad perfeccionadas y actualizadas.
La vulnerabilidad de asignación masiva nació como resultado de muchos marcos modernos que alentaban a los desarrolladores a usar funciones que vinculan automáticamente la entrada de los clientes a variables de código y objetos internos.
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Secure Code Warrior está aquí para que su organización le ayude a proteger el código durante todo el ciclo de vida del desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Ya sea administrador de AppSec, desarrollador, CISO o cualquier persona relacionada con la seguridad, podemos ayudar a su organización a reducir los riesgos asociados con el código inseguro.
Reserva una demostración
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Matias is a researcher and developer with more than 15 years of hands-on software security experience. He has developed solutions for companies such as Fortify Software and his own company Sensei Security. Over his career, Matias has led multiple application security research projects which have led to commercial products and boasts over 10 patents under his belt. When he is away from his desk, Matias has served as an instructor for advanced application security training courses and regularly speaks at global conferences including RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec and BruCon.
Matias holds a Ph.D. in Computer Engineering from Ghent University, where he studied application security through program obfuscation to hide the inner workings of an application.
La vulnerabilidad de asignación masiva nació porque muchos marcos modernos alientan a los desarrolladores a usar funciones que vinculan automáticamente la entrada de los clientes a variables de código y objetos internos. Esto se hace para simplificar el código y acelerar las operaciones.
Los atacantes pueden usar esta metodología para forzar cambios en las propiedades de los objetos que un cliente nunca debería actualizar. Normalmente, esto se traduce en problemas específicos de la empresa, como que un usuario se añada privilegios de administrador en lugar de cerrar un sitio web o robar secretos corporativos. Los atacantes también deben tener alguna idea de las relaciones entre los objetos y la lógica empresarial de la aplicación que están explotando.
Sin embargo, nada de eso hace que la vulnerabilidad de asignación masiva sea menos peligrosa en manos de un usuario inteligente y malintencionado.
Antes de comenzar con la guía completa, juega a nuestro desafío gamificado y comprueba cómo te va:
¿Cómo pueden los atacantes aprovechar la vulnerabilidad de asignación masiva?
El escenario propuesto por OWASP (y modificado ligeramente por nosotros) supone una aplicación para compartir viajes que incluye diferentes propiedades vinculadas a objetos en el código mediante la asignación masiva. Entre ellas se incluyen las propiedades relacionadas con los permisos que los usuarios pueden cambiar y las propiedades dependientes del proceso que la aplicación solo debe establecer internamente. Ambas utilizan la asignación masiva para vincular propiedades a objetos.
En este escenario, la aplicación de transporte compartido permite a los usuarios actualizar sus perfiles, como es habitual en muchas aplicaciones orientadas al usuario. Esto se hace mediante una llamada a la API enviada a PUT, que devuelve el siguiente objeto JSON:
{"user_name» :"SneakySnake», «edad» :17, «is_admin» :false}
Como el atacante, el Sr. SneakySnake en este caso, ha descubierto la relación entre las propiedades y los objetos, puede volver a enviar su solicitud original para actualizar su perfil con la siguiente cadena:
{"user_name» :"SneakySnake», «edad» :24, «is_admin» :true}
Como el punto final es vulnerable a la asignación masiva, acepta la nueva entrada como válida. Nuestro hacker no solo añadió algunos años a su perfil, sino que también se asignó privilegios de administrador.
Eliminar la vulnerabilidad de la asignación masiva
Por muy conveniente que sea usar la función de asignación masiva en algunos marcos, debes evitar hacerlo si quieres mantener tus API seguras. En su lugar, analiza los valores de las solicitudes en lugar de vincularlos directamente a un objeto. También puede usar un objeto de transferencia de datos reducida, lo que proporcionaría casi la misma comodidad que vincularlo directamente al objeto en sí, solo que sin el riesgo asociado.
Como medida de precaución adicional, las propiedades sensibles, como los privilegios de administrador del ejemplo anterior, podrían denegarse para que el servidor nunca las acepte en una llamada a la API. Una idea aún mejor sería denegar todas las propiedades de forma predeterminada y, a continuación, permitir las propiedades específicas y no confidenciales que quieras que los usuarios puedan actualizar o cambiar. Hacer cualquiera de estas cosas puede ayudar a bloquear las API y eliminar la vulnerabilidad de asignación masiva de su entorno.
Eche un vistazo a la Secure Code Warrior páginas de 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 otras fallas de seguridad. También puedes prueba una demo de la plataforma de formación Secure Code Warrior para mantener todas sus habilidades de ciberseguridad perfeccionadas y actualizadas.
La vulnerabilidad de asignación masiva nació porque muchos marcos modernos alientan a los desarrolladores a usar funciones que vinculan automáticamente la entrada de los clientes a variables de código y objetos internos. Esto se hace para simplificar el código y acelerar las operaciones.
Los atacantes pueden usar esta metodología para forzar cambios en las propiedades de los objetos que un cliente nunca debería actualizar. Normalmente, esto se traduce en problemas específicos de la empresa, como que un usuario se añada privilegios de administrador en lugar de cerrar un sitio web o robar secretos corporativos. Los atacantes también deben tener alguna idea de las relaciones entre los objetos y la lógica empresarial de la aplicación que están explotando.
Sin embargo, nada de eso hace que la vulnerabilidad de asignación masiva sea menos peligrosa en manos de un usuario inteligente y malintencionado.
Antes de comenzar con la guía completa, juega a nuestro desafío gamificado y comprueba cómo te va:
¿Cómo pueden los atacantes aprovechar la vulnerabilidad de asignación masiva?
El escenario propuesto por OWASP (y modificado ligeramente por nosotros) supone una aplicación para compartir viajes que incluye diferentes propiedades vinculadas a objetos en el código mediante la asignación masiva. Entre ellas se incluyen las propiedades relacionadas con los permisos que los usuarios pueden cambiar y las propiedades dependientes del proceso que la aplicación solo debe establecer internamente. Ambas utilizan la asignación masiva para vincular propiedades a objetos.
En este escenario, la aplicación de transporte compartido permite a los usuarios actualizar sus perfiles, como es habitual en muchas aplicaciones orientadas al usuario. Esto se hace mediante una llamada a la API enviada a PUT, que devuelve el siguiente objeto JSON:
{"user_name» :"SneakySnake», «edad» :17, «is_admin» :false}
Como el atacante, el Sr. SneakySnake en este caso, ha descubierto la relación entre las propiedades y los objetos, puede volver a enviar su solicitud original para actualizar su perfil con la siguiente cadena:
{"user_name» :"SneakySnake», «edad» :24, «is_admin» :true}
Como el punto final es vulnerable a la asignación masiva, acepta la nueva entrada como válida. Nuestro hacker no solo añadió algunos años a su perfil, sino que también se asignó privilegios de administrador.
Eliminar la vulnerabilidad de la asignación masiva
Por muy conveniente que sea usar la función de asignación masiva en algunos marcos, debes evitar hacerlo si quieres mantener tus API seguras. En su lugar, analiza los valores de las solicitudes en lugar de vincularlos directamente a un objeto. También puede usar un objeto de transferencia de datos reducida, lo que proporcionaría casi la misma comodidad que vincularlo directamente al objeto en sí, solo que sin el riesgo asociado.
Como medida de precaución adicional, las propiedades sensibles, como los privilegios de administrador del ejemplo anterior, podrían denegarse para que el servidor nunca las acepte en una llamada a la API. Una idea aún mejor sería denegar todas las propiedades de forma predeterminada y, a continuación, permitir las propiedades específicas y no confidenciales que quieras que los usuarios puedan actualizar o cambiar. Hacer cualquiera de estas cosas puede ayudar a bloquear las API y eliminar la vulnerabilidad de asignación masiva de su entorno.
Eche un vistazo a la Secure Code Warrior páginas de 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 otras fallas de seguridad. También puedes prueba una demo de la plataforma de formación Secure Code Warrior para mantener todas sus habilidades de ciberseguridad perfeccionadas y actualizadas.
Haga clic en el enlace de abajo y descargue el PDF de este recurso.
Secure Code Warrior está aquí para que su organización le ayude a proteger el código durante todo el ciclo de vida del desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Ya sea administrador de AppSec, desarrollador, CISO o cualquier persona relacionada con la seguridad, podemos ayudar a su organización a reducir los riesgos asociados con el código inseguro.
Ver informeReserva una demostración
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Matias is a researcher and developer with more than 15 years of hands-on software security experience. He has developed solutions for companies such as Fortify Software and his own company Sensei Security. Over his career, Matias has led multiple application security research projects which have led to commercial products and boasts over 10 patents under his belt. When he is away from his desk, Matias has served as an instructor for advanced application security training courses and regularly speaks at global conferences including RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec and BruCon.
Matias holds a Ph.D. in Computer Engineering from Ghent University, where he studied application security through program obfuscation to hide the inner workings of an application.
La vulnerabilidad de asignación masiva nació porque muchos marcos modernos alientan a los desarrolladores a usar funciones que vinculan automáticamente la entrada de los clientes a variables de código y objetos internos. Esto se hace para simplificar el código y acelerar las operaciones.
Los atacantes pueden usar esta metodología para forzar cambios en las propiedades de los objetos que un cliente nunca debería actualizar. Normalmente, esto se traduce en problemas específicos de la empresa, como que un usuario se añada privilegios de administrador en lugar de cerrar un sitio web o robar secretos corporativos. Los atacantes también deben tener alguna idea de las relaciones entre los objetos y la lógica empresarial de la aplicación que están explotando.
Sin embargo, nada de eso hace que la vulnerabilidad de asignación masiva sea menos peligrosa en manos de un usuario inteligente y malintencionado.
Antes de comenzar con la guía completa, juega a nuestro desafío gamificado y comprueba cómo te va:
¿Cómo pueden los atacantes aprovechar la vulnerabilidad de asignación masiva?
El escenario propuesto por OWASP (y modificado ligeramente por nosotros) supone una aplicación para compartir viajes que incluye diferentes propiedades vinculadas a objetos en el código mediante la asignación masiva. Entre ellas se incluyen las propiedades relacionadas con los permisos que los usuarios pueden cambiar y las propiedades dependientes del proceso que la aplicación solo debe establecer internamente. Ambas utilizan la asignación masiva para vincular propiedades a objetos.
En este escenario, la aplicación de transporte compartido permite a los usuarios actualizar sus perfiles, como es habitual en muchas aplicaciones orientadas al usuario. Esto se hace mediante una llamada a la API enviada a PUT, que devuelve el siguiente objeto JSON:
{"user_name» :"SneakySnake», «edad» :17, «is_admin» :false}
Como el atacante, el Sr. SneakySnake en este caso, ha descubierto la relación entre las propiedades y los objetos, puede volver a enviar su solicitud original para actualizar su perfil con la siguiente cadena:
{"user_name» :"SneakySnake», «edad» :24, «is_admin» :true}
Como el punto final es vulnerable a la asignación masiva, acepta la nueva entrada como válida. Nuestro hacker no solo añadió algunos años a su perfil, sino que también se asignó privilegios de administrador.
Eliminar la vulnerabilidad de la asignación masiva
Por muy conveniente que sea usar la función de asignación masiva en algunos marcos, debes evitar hacerlo si quieres mantener tus API seguras. En su lugar, analiza los valores de las solicitudes en lugar de vincularlos directamente a un objeto. También puede usar un objeto de transferencia de datos reducida, lo que proporcionaría casi la misma comodidad que vincularlo directamente al objeto en sí, solo que sin el riesgo asociado.
Como medida de precaución adicional, las propiedades sensibles, como los privilegios de administrador del ejemplo anterior, podrían denegarse para que el servidor nunca las acepte en una llamada a la API. Una idea aún mejor sería denegar todas las propiedades de forma predeterminada y, a continuación, permitir las propiedades específicas y no confidenciales que quieras que los usuarios puedan actualizar o cambiar. Hacer cualquiera de estas cosas puede ayudar a bloquear las API y eliminar la vulnerabilidad de asignación masiva de su entorno.
Eche un vistazo a la Secure Code Warrior páginas de 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 otras fallas de seguridad. También puedes prueba una demo de la plataforma de formación Secure Code Warrior para mantener todas sus habilidades de ciberseguridad perfeccionadas y actualizadas.
Tabla de contenido
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Secure Code Warrior está aquí para que su organización le ayude a proteger el código durante todo el ciclo de vida del desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Ya sea administrador de AppSec, desarrollador, CISO o cualquier persona relacionada con la seguridad, podemos ayudar a su organización a reducir los riesgos asociados con el código inseguro.
Reserva una demostraciónDescargarRecursos para empezar
Temas y contenido de formación sobre código seguro
Nuestro contenido líder en la industria siempre está evolucionando para adaptarse al cambiante panorama del desarrollo de software teniendo en cuenta su función. Se ofrecen temas que abarcan desde la IA hasta la inyección de XQuery para distintos puestos, desde arquitectos e ingenieros hasta directores de productos y control de calidad. Obtenga un adelanto de lo que ofrece nuestro catálogo de contenido por tema y función.
%20(1).avif)
.avif)
Threat Modeling with AI: Turning Every Developer into a Threat Modeler
Walk away better equipped to help developers combine threat modeling ideas and techniques with the AI tools they're already using to strengthen security, improve collaboration, and build more resilient software from the start.
Recursos para empezar
Cybermon está de vuelta: las misiones de IA de Beat the Boss ya están disponibles bajo demanda
Cybermon 2025 Beat the Boss ya está disponible durante todo el año en SCW. Implemente desafíos de seguridad avanzados de IA y LLM para fortalecer el desarrollo seguro de la IA a gran escala.
Explicación de la Ley de Ciberresiliencia: qué significa para el desarrollo de software seguro por diseño
Descubra qué exige la Ley de Ciberresiliencia (CRA) de la UE, a quién se aplica y cómo los equipos de ingeniería pueden prepararse con prácticas de diseño seguras, prevención de vulnerabilidades y desarrollo de capacidades para desarrolladores.
Habilitador 1: Criterios de éxito definidos y medibles
Enabler 1 da inicio a nuestra serie Enablers of Success, de 10 partes, mostrando cómo vincular la codificación segura con los resultados empresariales, como la reducción del riesgo y la velocidad para lograr la madurez del programa a largo plazo.
