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 ）。Ghent大学でアプリケーションセキュリティの博士号を取得し、静的解析ソリューションに焦点を当てた。その後、米国Fortify社に入社し、開発者が安全なコードを書くことを支援せずに、コードの問題を検出するだけでは不十分であることに気づきました。開発者を支援し、セキュリティの負担を軽減し、お客様の期待を上回る製品を開発することを志すようになった。Team Awesomeの一員としてデスクワークをしていないときは、RSA Conference、BlackHat、DefConなどのカンファレンスでプレゼンテーションをするのが好きである。
Secure Code Warrior ソフトウェア開発ライフサイクル全体を通じてコードを保護し、サイバーセキュリティを最優先事項とする文化を構築するために、貴組織をSecure Code Warrior 。AppSec管理者、開発者、CISO、セキュリティ関連担当者など、あらゆる立場の方々に対し、不安全なコードに関連するリスクを軽減するお手伝いをいたします。
デモを予約する
Matias Madou, Ph.D. セキュリティ専門家、研究者、CTO兼共同設立者（Secure Code Warrior ）。Ghent大学でアプリケーションセキュリティの博士号を取得し、静的解析ソリューションに焦点を当てた。その後、米国Fortify社に入社し、開発者が安全なコードを書くことを支援せずに、コードの問題を検出するだけでは不十分であることに気づきました。開発者を支援し、セキュリティの負担を軽減し、お客様の期待を上回る製品を開発することを志すようになった。Team Awesomeの一員としてデスクワークをしていないときは、RSA Conference、BlackHat、DefConなどのカンファレンスでプレゼンテーションをするのが好きである。
マティアスは、15年以上のソフトウェアセキュリティの実務経験を持つ研究者・開発者です。フォーティファイ・ソフトウェア社や自身の会社（Sensei Security）などでソリューションを開発してきました。キャリアの中で、Matiasは、商用製品につながる複数のアプリケーションセキュリティ研究プロジェクトを主導し、10件以上の特許を取得しています。また、RSAカンファレンス、Black Hat、DefCon、BSIMM、OWASP AppSec、BruConなどの世界的なカンファレンスで定期的に講演を行っているほか、高度なアプリケーションセキュリティトレーニング（courses ）の講師も務めています。
Matiasはゲント大学でコンピュータ工学の博士号を取得し、アプリケーションの内部構造を隠すためのプログラム難読化によるアプリケーションセキュリティを研究しました。
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 ソフトウェア開発ライフサイクル全体を通じてコードを保護し、サイバーセキュリティを最優先事項とする文化を構築するために、貴組織をSecure Code Warrior 。AppSec管理者、開発者、CISO、セキュリティ関連担当者など、あらゆる立場の方々に対し、不安全なコードに関連するリスクを軽減するお手伝いをいたします。
報告書を見るデモを予約する
Matias Madou, Ph.D. セキュリティ専門家、研究者、CTO兼共同設立者（Secure Code Warrior ）。Ghent大学でアプリケーションセキュリティの博士号を取得し、静的解析ソリューションに焦点を当てた。その後、米国Fortify社に入社し、開発者が安全なコードを書くことを支援せずに、コードの問題を検出するだけでは不十分であることに気づきました。開発者を支援し、セキュリティの負担を軽減し、お客様の期待を上回る製品を開発することを志すようになった。Team Awesomeの一員としてデスクワークをしていないときは、RSA Conference、BlackHat、DefConなどのカンファレンスでプレゼンテーションをするのが好きである。
マティアスは、15年以上のソフトウェアセキュリティの実務経験を持つ研究者・開発者です。フォーティファイ・ソフトウェア社や自身の会社（Sensei Security）などでソリューションを開発してきました。キャリアの中で、Matiasは、商用製品につながる複数のアプリケーションセキュリティ研究プロジェクトを主導し、10件以上の特許を取得しています。また、RSAカンファレンス、Black Hat、DefCon、BSIMM、OWASP AppSec、BruConなどの世界的なカンファレンスで定期的に講演を行っているほか、高度なアプリケーションセキュリティトレーニング（courses ）の講師も務めています。
Matiasはゲント大学でコンピュータ工学の博士号を取得し、アプリケーションの内部構造を隠すためのプログラム難読化によるアプリケーションセキュリティを研究しました。
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 ）。Ghent大学でアプリケーションセキュリティの博士号を取得し、静的解析ソリューションに焦点を当てた。その後、米国Fortify社に入社し、開発者が安全なコードを書くことを支援せずに、コードの問題を検出するだけでは不十分であることに気づきました。開発者を支援し、セキュリティの負担を軽減し、お客様の期待を上回る製品を開発することを志すようになった。Team Awesomeの一員としてデスクワークをしていないときは、RSA Conference、BlackHat、DefConなどのカンファレンスでプレゼンテーションをするのが好きである。
Secure Code Warrior ソフトウェア開発ライフサイクル全体を通じてコードを保護し、サイバーセキュリティを最優先事項とする文化を構築するために、貴組織をSecure Code Warrior 。AppSec管理者、開発者、CISO、セキュリティ関連担当者など、あらゆる立場の方々に対し、不安全なコードに関連するリスクを軽減するお手伝いをいたします。
デモを予約するダウンロード
%20(1).avif)
.avif)
