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
Trust Agent:AI - Secure and scale AI-Drive development
AI is writing code. Who’s governing it? With up to 50% of AI-generated code containing security weaknesses, managing AI risk is critical. Discover how SCW's Trust Agent: AI provides the real-time visibility, proactive governance, and targeted upskilling needed to scale AI-driven development securely.
The Power of OpenText Application Security + Secure Code Warrior
OpenText Application Security and Secure Code Warrior combine vulnerability detection with AI Software Governance and developer capability. Together, they help organizations reduce risk, strengthen secure coding practices, and confidently adopt AI-driven development.
Secure Code Warrior corporate overview
Secure Code Warrior is an AI Software Governance platform designed to enable organizations to safely adopt AI-driven development by bridging the gap between development velocity and enterprise security. The platform addresses the "Visibility Gap," where security teams often lack insights into shadow AI coding tools and the origins of production code.
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.
.png)
