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.是一位安全专家、研究员和CTO，也是Secure Code Warrior 的联合创始人。Matias在根特大学获得了应用安全的博士学位，主要研究静态分析解决方案。后来他加入了美国的Fortify公司，在那里他意识到，仅仅检测代码问题而不帮助开发人员编写安全代码是不够的。这激发了他开发产品的热情，帮助开发人员，减轻安全的负担，并超越客户的期望。当他不在办公桌前作为Awesome团队的一员时，他喜欢站在舞台上，在包括RSA会议、BlackHat和DefCon等会议上发表演讲。
Secure Code Warrior 您的组织在软件开发全生命周期中保护代码安全，并营造将网络安全置于首位的企业文化。无论您是应用安全管理员、开发人员、首席信息安全官，还是任何与安全相关的工作人员，我们都能助力您的组织降低不安全代码带来的风险。
预约演示
Matias Madou, Ph.D.是一位安全专家、研究员和CTO，也是Secure Code Warrior 的联合创始人。Matias在根特大学获得了应用安全的博士学位，主要研究静态分析解决方案。后来他加入了美国的Fortify公司，在那里他意识到，仅仅检测代码问题而不帮助开发人员编写安全代码是不够的。这激发了他开发产品的热情，帮助开发人员，减轻安全的负担，并超越客户的期望。当他不在办公桌前作为Awesome团队的一员时，他喜欢站在舞台上，在包括RSA会议、BlackHat和DefCon等会议上发表演讲。
马蒂亚斯是一名研究员和开发人员，拥有超过15年的软件安全实践经验。他曾为Fortify Software和他自己的公司Sensei Security等公司开发解决方案。在他的职业生涯中，马蒂亚斯领导了多个应用安全研究项目，并将其转化为商业产品，他拥有超过10项专利。当他离开办公桌时，Matias曾担任高级应用安全培训courses ，并定期在全球会议上发言，包括RSA会议、黑帽、DefCon、BSIMM、OWASP AppSec和BruCon。
马蒂亚斯拥有根特大学的计算机工程博士学位，在那里他研究了通过程序混淆来隐藏应用程序的内部工作的应用安全。
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.
点击下方链接，下载此资源的PDF文件。
Secure Code Warrior 您的组织在软件开发全生命周期中保护代码安全，并营造将网络安全置于首位的企业文化。无论您是应用安全管理员、开发人员、首席信息安全官，还是任何与安全相关的工作人员，我们都能助力您的组织降低不安全代码带来的风险。
查看报告预约演示
Matias Madou, Ph.D.是一位安全专家、研究员和CTO，也是Secure Code Warrior 的联合创始人。Matias在根特大学获得了应用安全的博士学位，主要研究静态分析解决方案。后来他加入了美国的Fortify公司，在那里他意识到，仅仅检测代码问题而不帮助开发人员编写安全代码是不够的。这激发了他开发产品的热情，帮助开发人员，减轻安全的负担，并超越客户的期望。当他不在办公桌前作为Awesome团队的一员时，他喜欢站在舞台上，在包括RSA会议、BlackHat和DefCon等会议上发表演讲。
马蒂亚斯是一名研究员和开发人员，拥有超过15年的软件安全实践经验。他曾为Fortify Software和他自己的公司Sensei Security等公司开发解决方案。在他的职业生涯中，马蒂亚斯领导了多个应用安全研究项目，并将其转化为商业产品，他拥有超过10项专利。当他离开办公桌时，Matias曾担任高级应用安全培训courses ，并定期在全球会议上发言，包括RSA会议、黑帽、DefCon、BSIMM、OWASP AppSec和BruCon。
马蒂亚斯拥有根特大学的计算机工程博士学位，在那里他研究了通过程序混淆来隐藏应用程序的内部工作的应用安全。
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.
目录
Matias Madou, Ph.D.是一位安全专家、研究员和CTO，也是Secure Code Warrior 的联合创始人。Matias在根特大学获得了应用安全的博士学位，主要研究静态分析解决方案。后来他加入了美国的Fortify公司，在那里他意识到，仅仅检测代码问题而不帮助开发人员编写安全代码是不够的。这激发了他开发产品的热情，帮助开发人员，减轻安全的负担，并超越客户的期望。当他不在办公桌前作为Awesome团队的一员时，他喜欢站在舞台上，在包括RSA会议、BlackHat和DefCon等会议上发表演讲。
Secure Code Warrior 您的组织在软件开发全生命周期中保护代码安全，并营造将网络安全置于首位的企业文化。无论您是应用安全管理员、开发人员、首席信息安全官，还是任何与安全相关的工作人员，我们都能助力您的组织降低不安全代码带来的风险。
预约演示下载
%20(1).avif)
.avif)
