
Les codeurs conquièrent les 10 meilleures séries d'API de l'OWASP en matière de sécurité - Mass Assignment
La vulnérabilité d'assignation de masse est née parce que de nombreux frameworks modernes encouragent les développeurs à utiliser des fonctions qui lient automatiquement les entrées des clients à des variables de code et à des objets internes. Ceci est fait pour simplifier le code et accélérer les opérations.
Les attaquants peuvent utiliser cette méthodologie pour imposer des modifications aux propriétés des objets qui ne devraient jamais être mises à jour par un client. Normalement, cela entraîne des problèmes spécifiques à l'entreprise, par exemple un utilisateur qui se donne des privilèges d'administrateur au lieu de détruire un site Web ou de voler des secrets d'entreprise. Les attaquants doivent également avoir une idée des relations entre les objets et la logique métier de l'application qu'ils exploitent.
Cependant, rien de tout cela ne rend la vulnérabilité d'assignation de masse moins dangereuse entre les mains d'un utilisateur intelligent et malveillant.
Avant de lancer le guide complet, jouez à notre défi ludique et voyez comment vous vous en sortez :
Comment les attaquants peuvent-ils exploiter la vulnérabilité d'assignation de masse ?
Le scénario proposé par OWASP (et légèrement modifié par nos soins) suppose une application de covoiturage qui inclut différentes propriétés liées à des objets dans le code par attribution de masse. Il s'agit notamment des propriétés liées aux autorisations que les utilisateurs peuvent modifier et des propriétés dépendantes des processus qui ne doivent être définies qu'en interne par l'application. Les deux utilisent l'attribution de masse pour lier des propriétés à des objets.
Dans ce scénario, l'application de covoiturage permet aux utilisateurs de mettre à jour leurs profils, comme cela est courant dans de nombreuses applications destinées aux utilisateurs. Cela se fait à l'aide d'un appel d'API envoyé à PUT, qui renvoie l'objet JSON suivant :
{"user_name » :"SneakySnake », « age » :17, « is_admin » :false}
Comme l'attaquant, en l'occurrence M. SneakySnake, a découvert la relation entre les propriétés et les objets, il peut renvoyer sa demande initiale de mise à jour de son profil avec la chaîne suivante :
{"user_name » :"SneakySnake », « age » :24, « is_admin » :true}
Comme le point de terminaison est vulnérable à l'assignation en masse, il accepte la nouvelle entrée comme étant valide. Non seulement notre hacker a ajouté quelques années à son profil, mais il s'est également attribué des privilèges d'administrateur.
Élimination de la vulnérabilité liée aux affectations de masse
Aussi pratique que cela puisse être d'utiliser la fonction d'attribution de masse dans certains frameworks, vous devez éviter de le faire si vous souhaitez sécuriser vos API. Analysez plutôt les valeurs des requêtes plutôt que de les lier directement à un objet. Vous pouvez également utiliser un objet à transfert de données réduit, ce qui offrirait presque le même confort que la liaison directe à l'objet lui-même, mais sans le risque associé.
Par mesure de précaution supplémentaire, les propriétés sensibles telles que les privilèges d'administrateur de l'exemple ci-dessus peuvent être refusées afin qu'elles ne soient jamais acceptées par le serveur lors d'un appel d'API. Une meilleure idée serait de refuser toutes les propriétés par défaut, puis d'autoriser les propriétés spécifiques et non sensibles que vous souhaitez que les utilisateurs puissent mettre à jour ou modifier. Toutes ces mesures peuvent aider à verrouiller les API et à éliminer la vulnérabilité d'attribution de masse de votre environnement.
Consultez le Secure Code Warrior pages de blog pour en savoir plus sur cette vulnérabilité et sur la manière de protéger votre organisation et vos clients des ravages causés par d'autres failles de sécurité. Vous pouvez également essayez une démo de la plateforme de formation Secure Code Warrior pour maintenir toutes vos compétences en cybersécurité à jour et à jour.


La vulnérabilité d'assignation de masse est née de nombreux frameworks modernes encourageant les développeurs à utiliser des fonctions qui lient automatiquement les entrées des clients à des variables de code et à des objets internes.
Matias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.

Secure Code Warrior aquí para ayudar a su organización a proteger el código a lo largo de todo el ciclo de desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es responsable de la seguridad de las aplicaciones, desarrollador, responsable de la seguridad informática o cualquier otra persona involucrada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código no seguro.
Reserve una demostraciónMatias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.
Matías es un investigador y desarrollador con más de 15 años de experiencia práctica en seguridad de software. Ha desarrollado soluciones para empresas como Fortify Software y su propia empresa Sensei Security. A lo largo de su carrera, Matías ha dirigido múltiples proyectos de investigación sobre seguridad de aplicaciones que han dado lugar a productos comerciales y cuenta con más de 10 patentes en su haber. Cuando está lejos de su escritorio, Matias ha servido como instructor para la formación de seguridad de aplicaciones avanzadas courses y regularmente habla en conferencias mundiales como la Conferencia RSA, Black Hat, DefCon, BSIMM, OWASP AppSec y BruCon.
Matías es doctor en Ingeniería Informática por la Universidad de Gante, donde estudió la seguridad de las aplicaciones mediante la ofuscación de programas para ocultar el funcionamiento interno de una aplicación.


La vulnérabilité d'assignation de masse est née parce que de nombreux frameworks modernes encouragent les développeurs à utiliser des fonctions qui lient automatiquement les entrées des clients à des variables de code et à des objets internes. Ceci est fait pour simplifier le code et accélérer les opérations.
Les attaquants peuvent utiliser cette méthodologie pour imposer des modifications aux propriétés des objets qui ne devraient jamais être mises à jour par un client. Normalement, cela entraîne des problèmes spécifiques à l'entreprise, par exemple un utilisateur qui se donne des privilèges d'administrateur au lieu de détruire un site Web ou de voler des secrets d'entreprise. Les attaquants doivent également avoir une idée des relations entre les objets et la logique métier de l'application qu'ils exploitent.
Cependant, rien de tout cela ne rend la vulnérabilité d'assignation de masse moins dangereuse entre les mains d'un utilisateur intelligent et malveillant.
Avant de lancer le guide complet, jouez à notre défi ludique et voyez comment vous vous en sortez :
Comment les attaquants peuvent-ils exploiter la vulnérabilité d'assignation de masse ?
Le scénario proposé par OWASP (et légèrement modifié par nos soins) suppose une application de covoiturage qui inclut différentes propriétés liées à des objets dans le code par attribution de masse. Il s'agit notamment des propriétés liées aux autorisations que les utilisateurs peuvent modifier et des propriétés dépendantes des processus qui ne doivent être définies qu'en interne par l'application. Les deux utilisent l'attribution de masse pour lier des propriétés à des objets.
Dans ce scénario, l'application de covoiturage permet aux utilisateurs de mettre à jour leurs profils, comme cela est courant dans de nombreuses applications destinées aux utilisateurs. Cela se fait à l'aide d'un appel d'API envoyé à PUT, qui renvoie l'objet JSON suivant :
{"user_name » :"SneakySnake », « age » :17, « is_admin » :false}
Comme l'attaquant, en l'occurrence M. SneakySnake, a découvert la relation entre les propriétés et les objets, il peut renvoyer sa demande initiale de mise à jour de son profil avec la chaîne suivante :
{"user_name » :"SneakySnake », « age » :24, « is_admin » :true}
Comme le point de terminaison est vulnérable à l'assignation en masse, il accepte la nouvelle entrée comme étant valide. Non seulement notre hacker a ajouté quelques années à son profil, mais il s'est également attribué des privilèges d'administrateur.
Élimination de la vulnérabilité liée aux affectations de masse
Aussi pratique que cela puisse être d'utiliser la fonction d'attribution de masse dans certains frameworks, vous devez éviter de le faire si vous souhaitez sécuriser vos API. Analysez plutôt les valeurs des requêtes plutôt que de les lier directement à un objet. Vous pouvez également utiliser un objet à transfert de données réduit, ce qui offrirait presque le même confort que la liaison directe à l'objet lui-même, mais sans le risque associé.
Par mesure de précaution supplémentaire, les propriétés sensibles telles que les privilèges d'administrateur de l'exemple ci-dessus peuvent être refusées afin qu'elles ne soient jamais acceptées par le serveur lors d'un appel d'API. Une meilleure idée serait de refuser toutes les propriétés par défaut, puis d'autoriser les propriétés spécifiques et non sensibles que vous souhaitez que les utilisateurs puissent mettre à jour ou modifier. Toutes ces mesures peuvent aider à verrouiller les API et à éliminer la vulnérabilité d'attribution de masse de votre environnement.
Consultez le Secure Code Warrior pages de blog pour en savoir plus sur cette vulnérabilité et sur la manière de protéger votre organisation et vos clients des ravages causés par d'autres failles de sécurité. Vous pouvez également essayez une démo de la plateforme de formation Secure Code Warrior pour maintenir toutes vos compétences en cybersécurité à jour et à jour.

La vulnérabilité d'assignation de masse est née parce que de nombreux frameworks modernes encouragent les développeurs à utiliser des fonctions qui lient automatiquement les entrées des clients à des variables de code et à des objets internes. Ceci est fait pour simplifier le code et accélérer les opérations.
Les attaquants peuvent utiliser cette méthodologie pour imposer des modifications aux propriétés des objets qui ne devraient jamais être mises à jour par un client. Normalement, cela entraîne des problèmes spécifiques à l'entreprise, par exemple un utilisateur qui se donne des privilèges d'administrateur au lieu de détruire un site Web ou de voler des secrets d'entreprise. Les attaquants doivent également avoir une idée des relations entre les objets et la logique métier de l'application qu'ils exploitent.
Cependant, rien de tout cela ne rend la vulnérabilité d'assignation de masse moins dangereuse entre les mains d'un utilisateur intelligent et malveillant.
Avant de lancer le guide complet, jouez à notre défi ludique et voyez comment vous vous en sortez :
Comment les attaquants peuvent-ils exploiter la vulnérabilité d'assignation de masse ?
Le scénario proposé par OWASP (et légèrement modifié par nos soins) suppose une application de covoiturage qui inclut différentes propriétés liées à des objets dans le code par attribution de masse. Il s'agit notamment des propriétés liées aux autorisations que les utilisateurs peuvent modifier et des propriétés dépendantes des processus qui ne doivent être définies qu'en interne par l'application. Les deux utilisent l'attribution de masse pour lier des propriétés à des objets.
Dans ce scénario, l'application de covoiturage permet aux utilisateurs de mettre à jour leurs profils, comme cela est courant dans de nombreuses applications destinées aux utilisateurs. Cela se fait à l'aide d'un appel d'API envoyé à PUT, qui renvoie l'objet JSON suivant :
{"user_name » :"SneakySnake », « age » :17, « is_admin » :false}
Comme l'attaquant, en l'occurrence M. SneakySnake, a découvert la relation entre les propriétés et les objets, il peut renvoyer sa demande initiale de mise à jour de son profil avec la chaîne suivante :
{"user_name » :"SneakySnake », « age » :24, « is_admin » :true}
Comme le point de terminaison est vulnérable à l'assignation en masse, il accepte la nouvelle entrée comme étant valide. Non seulement notre hacker a ajouté quelques années à son profil, mais il s'est également attribué des privilèges d'administrateur.
Élimination de la vulnérabilité liée aux affectations de masse
Aussi pratique que cela puisse être d'utiliser la fonction d'attribution de masse dans certains frameworks, vous devez éviter de le faire si vous souhaitez sécuriser vos API. Analysez plutôt les valeurs des requêtes plutôt que de les lier directement à un objet. Vous pouvez également utiliser un objet à transfert de données réduit, ce qui offrirait presque le même confort que la liaison directe à l'objet lui-même, mais sans le risque associé.
Par mesure de précaution supplémentaire, les propriétés sensibles telles que les privilèges d'administrateur de l'exemple ci-dessus peuvent être refusées afin qu'elles ne soient jamais acceptées par le serveur lors d'un appel d'API. Une meilleure idée serait de refuser toutes les propriétés par défaut, puis d'autoriser les propriétés spécifiques et non sensibles que vous souhaitez que les utilisateurs puissent mettre à jour ou modifier. Toutes ces mesures peuvent aider à verrouiller les API et à éliminer la vulnérabilité d'attribution de masse de votre environnement.
Consultez le Secure Code Warrior pages de blog pour en savoir plus sur cette vulnérabilité et sur la manière de protéger votre organisation et vos clients des ravages causés par d'autres failles de sécurité. Vous pouvez également essayez une démo de la plateforme de formation Secure Code Warrior pour maintenir toutes vos compétences en cybersécurité à jour et à jour.

Haga clic en el enlace siguiente y descargue el PDF de este recurso.
Secure Code Warrior aquí para ayudar a su organización a proteger el código a lo largo de todo el ciclo de desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es responsable de la seguridad de las aplicaciones, desarrollador, responsable de la seguridad informática o cualquier otra persona involucrada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código no seguro.
Mostrar el informeReserve una demostraciónMatias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.
Matías es un investigador y desarrollador con más de 15 años de experiencia práctica en seguridad de software. Ha desarrollado soluciones para empresas como Fortify Software y su propia empresa Sensei Security. A lo largo de su carrera, Matías ha dirigido múltiples proyectos de investigación sobre seguridad de aplicaciones que han dado lugar a productos comerciales y cuenta con más de 10 patentes en su haber. Cuando está lejos de su escritorio, Matias ha servido como instructor para la formación de seguridad de aplicaciones avanzadas courses y regularmente habla en conferencias mundiales como la Conferencia RSA, Black Hat, DefCon, BSIMM, OWASP AppSec y BruCon.
Matías es doctor en Ingeniería Informática por la Universidad de Gante, donde estudió la seguridad de las aplicaciones mediante la ofuscación de programas para ocultar el funcionamiento interno de una aplicación.
La vulnérabilité d'assignation de masse est née parce que de nombreux frameworks modernes encouragent les développeurs à utiliser des fonctions qui lient automatiquement les entrées des clients à des variables de code et à des objets internes. Ceci est fait pour simplifier le code et accélérer les opérations.
Les attaquants peuvent utiliser cette méthodologie pour imposer des modifications aux propriétés des objets qui ne devraient jamais être mises à jour par un client. Normalement, cela entraîne des problèmes spécifiques à l'entreprise, par exemple un utilisateur qui se donne des privilèges d'administrateur au lieu de détruire un site Web ou de voler des secrets d'entreprise. Les attaquants doivent également avoir une idée des relations entre les objets et la logique métier de l'application qu'ils exploitent.
Cependant, rien de tout cela ne rend la vulnérabilité d'assignation de masse moins dangereuse entre les mains d'un utilisateur intelligent et malveillant.
Avant de lancer le guide complet, jouez à notre défi ludique et voyez comment vous vous en sortez :
Comment les attaquants peuvent-ils exploiter la vulnérabilité d'assignation de masse ?
Le scénario proposé par OWASP (et légèrement modifié par nos soins) suppose une application de covoiturage qui inclut différentes propriétés liées à des objets dans le code par attribution de masse. Il s'agit notamment des propriétés liées aux autorisations que les utilisateurs peuvent modifier et des propriétés dépendantes des processus qui ne doivent être définies qu'en interne par l'application. Les deux utilisent l'attribution de masse pour lier des propriétés à des objets.
Dans ce scénario, l'application de covoiturage permet aux utilisateurs de mettre à jour leurs profils, comme cela est courant dans de nombreuses applications destinées aux utilisateurs. Cela se fait à l'aide d'un appel d'API envoyé à PUT, qui renvoie l'objet JSON suivant :
{"user_name » :"SneakySnake », « age » :17, « is_admin » :false}
Comme l'attaquant, en l'occurrence M. SneakySnake, a découvert la relation entre les propriétés et les objets, il peut renvoyer sa demande initiale de mise à jour de son profil avec la chaîne suivante :
{"user_name » :"SneakySnake », « age » :24, « is_admin » :true}
Comme le point de terminaison est vulnérable à l'assignation en masse, il accepte la nouvelle entrée comme étant valide. Non seulement notre hacker a ajouté quelques années à son profil, mais il s'est également attribué des privilèges d'administrateur.
Élimination de la vulnérabilité liée aux affectations de masse
Aussi pratique que cela puisse être d'utiliser la fonction d'attribution de masse dans certains frameworks, vous devez éviter de le faire si vous souhaitez sécuriser vos API. Analysez plutôt les valeurs des requêtes plutôt que de les lier directement à un objet. Vous pouvez également utiliser un objet à transfert de données réduit, ce qui offrirait presque le même confort que la liaison directe à l'objet lui-même, mais sans le risque associé.
Par mesure de précaution supplémentaire, les propriétés sensibles telles que les privilèges d'administrateur de l'exemple ci-dessus peuvent être refusées afin qu'elles ne soient jamais acceptées par le serveur lors d'un appel d'API. Une meilleure idée serait de refuser toutes les propriétés par défaut, puis d'autoriser les propriétés spécifiques et non sensibles que vous souhaitez que les utilisateurs puissent mettre à jour ou modifier. Toutes ces mesures peuvent aider à verrouiller les API et à éliminer la vulnérabilité d'attribution de masse de votre environnement.
Consultez le Secure Code Warrior pages de blog pour en savoir plus sur cette vulnérabilité et sur la manière de protéger votre organisation et vos clients des ravages causés par d'autres failles de sécurité. Vous pouvez également essayez une démo de la plateforme de formation Secure Code Warrior pour maintenir toutes vos compétences en cybersécurité à jour et à jour.
Índice
Matias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.

Secure Code Warrior aquí para ayudar a su organización a proteger el código a lo largo de todo el ciclo de desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es responsable de la seguridad de las aplicaciones, desarrollador, responsable de la seguridad informática o cualquier otra persona involucrada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código no seguro.
Reserve una demostraciónDescargarRecursos para ayudarle a empezar
Temas y contenidos de formación sobre el código seguro
Nuestro contenido de vanguardia evoluciona constantemente para adaptarse al panorama en constante cambio del desarrollo de software, teniendo en cuenta su función. Temas que abarcan desde la IA hasta la inyección de XQuery, ofrecidos para una variedad de puestos, desde arquitectos hasta ingenieros, pasando por jefes de producto y control de calidad. Descubra una visión general de lo que nuestro catálogo de contenidos tiene para ofrecer por tema y por función.
La Cámara de Comercio establece el estándar para la seguridad impulsada por desarrolladores a gran escala
Kamer van Koophandel comparte cómo ha integrado la codificación segura en el desarrollo diario mediante certificaciones basadas en roles, evaluaciones comparativas de Trust Score y una cultura de responsabilidad compartida en materia de seguridad.
Modelado de amenazas con IA: convertir a cada desarrollador en un modelador de amenazas
Saldrá mejor equipado para ayudar a los desarrolladores a combinar ideas y técnicas de modelado de amenazas con las herramientas de IA que ya utilizan para reforzar la seguridad, mejorar la colaboración y crear software más resistente desde el principio.
Recursos para ayudarle a empezar
Cybermon está de vuelta: las missions Beat the Boss ya están disponibles bajo demanda.
Cybermon 2025 Beat the Boss ya está disponible todo el año en SCW. Implemente desafíos de seguridad avanzados relacionados con la IA y el LLM para reforzar el desarrollo seguro de la IA a gran escala.
Explicación de la ley sobre ciberresiliencia: lo que significa para el desarrollo de software seguro desde el diseño.
Descubra qué exige la ley europea sobre ciberresiliencia (CRA), a quién se aplica y cómo los equipos de ingenieros pueden prepararse mediante prácticas de seguridad desde el diseño, la prevención de vulnerabilidades y el refuerzo de las capacidades de los desarrolladores.
Facilitador 1: Criterios de éxito definidos y medibles
El facilitador 1 da inicio a nuestra serie de 10 partes titulada «Facilitadores del éxito», mostrando cómo combinar la codificación segura con resultados comerciales, como la reducción de riesgos y la rapidez, para garantizar la madurez a largo plazo de los programas.




%20(1).avif)
.avif)
