SCW图标
英雄背景无分隔线
博客

Les codeurs conquièrent les 10 meilleures séries d'API de l'OWASP en matière de sécurité - Mass Assignment

马蒂亚斯-马杜博士
发表于 2020 年 10 月 21 日
最后更新于 2026年3月8日

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.是一位安全专家、研究员和CTO,也是Secure Code Warrior 的联合创始人。Matias在根特大学获得了应用安全的博士学位,主要研究静态分析解决方案。后来他加入了美国的Fortify公司,在那里他意识到,仅仅检测代码问题而不帮助开发人员编写安全代码是不够的。这激发了他开发产品的热情,帮助开发人员,减轻安全的负担,并超越客户的期望。当他不在办公桌前作为Awesome团队的一员时,他喜欢站在舞台上,在包括RSA会议、BlackHat和DefCon等会议上发表演讲。

了解更多

Secure Code Warrior 在整个软件开发周期中保障代码安全,并营造将网络安全置于首位的企业文化。无论您是应用安全负责人、开发人员、信息安全主管,还是其他任何参与安全工作的人员,我们都能协助您的组织降低不安全代码带来的风险。

预约演示
分享到:
领英品牌社交x 标志
作者
马蒂亚斯-马杜博士
2020年10月21日发布

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。

马蒂亚斯拥有根特大学的计算机工程博士学位,在那里他研究了通过程序混淆来隐藏应用程序的内部工作的应用安全。

分享到:
领英品牌社交x 标志

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.

显示资源
显示资源

请填写以下表格以下载报告

我们希望获得您的授权,以便向您发送有关我们产品和/或安全编码相关主题的信息。我们将始终以最高标准谨慎处理您的个人数据,绝不会将其出售给其他企业用于营销目的。

提交
scw 成功图标
SCW 错误图标
要提交表单,请启用「Analytics」Cookie。完成操作后,请随时将其重新禁用。

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.

查看网络研讨会
开始
了解更多

点击下方链接,下载此资源的PDF文件。

Secure Code Warrior 在整个软件开发周期中保障代码安全,并营造将网络安全置于首位的企业文化。无论您是应用安全负责人、开发人员、信息安全主管,还是其他任何参与安全工作的人员,我们都能协助您的组织降低不安全代码带来的风险。

显示报告预约演示
下载PDF文件
显示资源
分享到:
领英品牌社交x 标志
您想了解更多吗?

分享到:
领英品牌社交x 标志
作者
马蒂亚斯-马杜博士
2020年10月21日发布

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。

马蒂亚斯拥有根特大学的计算机工程博士学位,在那里他研究了通过程序混淆来隐藏应用程序的内部工作的应用安全。

分享到:
领英品牌社交x 标志

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.

目录

下载PDF文件
显示资源
您想了解更多吗?

Matias Madou, Ph.D.是一位安全专家、研究员和CTO,也是Secure Code Warrior 的联合创始人。Matias在根特大学获得了应用安全的博士学位,主要研究静态分析解决方案。后来他加入了美国的Fortify公司,在那里他意识到,仅仅检测代码问题而不帮助开发人员编写安全代码是不够的。这激发了他开发产品的热情,帮助开发人员,减轻安全的负担,并超越客户的期望。当他不在办公桌前作为Awesome团队的一员时,他喜欢站在舞台上,在包括RSA会议、BlackHat和DefCon等会议上发表演讲。

了解更多

Secure Code Warrior 在整个软件开发周期中保障代码安全,并营造将网络安全置于首位的企业文化。无论您是应用安全负责人、开发人员、信息安全主管,还是其他任何参与安全工作的人员,我们都能协助您的组织降低不安全代码带来的风险。

预约演示下载
分享到:
领英品牌社交x 标志
资源中心

帮助您入门的资源

更多帖子
资源中心

帮助您入门的资源

更多帖子