
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.
마티아스 마두는 보안 전문가, 연구원, CTO이자 Secure Code Warrior 의 공동 설립자입니다. 마티아스는 겐트 대학교에서 정적 분석 솔루션에 중점을 둔 애플리케이션 보안 박사 학위를 취득했습니다. 이후 미국의 Fortify에 입사하여 개발자의 보안 코드 작성을 지원하지 않고 코드 문제만 탐지하는 것만으로는 충분하지 않다는 것을 깨달았습니다. 이를 계기로 개발자를 지원하고 보안에 대한 부담을 덜어주며 고객의 기대를 뛰어넘는 제품을 개발하게 되었습니다. 팀 어썸의 일원으로 책상에 앉아 있지 않을 때는 RSA 컨퍼런스, 블랙햇, 데프콘 등의 컨퍼런스에서 무대에 올라 발표하는 것을 즐깁니다.

Secure Code Warrior 귀사의 조직이 소프트웨어 개발 주기 전반에 걸쳐 코드를 안전하게 보호하고 사이버보안이 최우선 과제인 문화를 조성하도록 Secure Code Warrior . 애플리케이션 보안 담당자, 개발자, IT 보안 책임자 또는 보안 관련 업무에 종사하는 모든 분들을 위해, 저희는 귀사의 조직이 안전하지 않은 코드로 인한 위험을 줄일 수 있도록 돕습니다.
데모 예약하기마티아스 마두는 보안 전문가, 연구원, CTO이자 Secure Code Warrior 의 공동 설립자입니다. 마티아스는 겐트 대학교에서 정적 분석 솔루션에 중점을 둔 애플리케이션 보안 박사 학위를 취득했습니다. 이후 미국의 Fortify에 입사하여 개발자의 보안 코드 작성을 지원하지 않고 코드 문제만 탐지하는 것만으로는 충분하지 않다는 것을 깨달았습니다. 이를 계기로 개발자를 지원하고 보안에 대한 부담을 덜어주며 고객의 기대를 뛰어넘는 제품을 개발하게 되었습니다. 팀 어썸의 일원으로 책상에 앉아 있지 않을 때는 RSA 컨퍼런스, 블랙햇, 데프콘 등의 컨퍼런스에서 무대에 올라 발표하는 것을 즐깁니다.
Matias는 15년 이상의 소프트웨어 보안 경험을 가진 연구원이자 개발자입니다. 그는 Fortify 소프트웨어와 같은 회사와 자신의 회사를 위한 솔루션을 개발했습니다. Sensei 안전. 그의 경력을 통해, Matias는 상용 제품으로 주도하고 자신의 벨트 아래 10 개 이상의 특허를 자랑하는 여러 응용 프로그램 보안 연구 프로젝트를 주도하고있다. 마티아스는 책상에서 떨어져 있을 때 고급 응용 프로그램 보안 교육을 위한 강사로 일했습니다. courses RSA 컨퍼런스, 블랙 햇, 데프콘, BSIMM, OWASP AppSec 및 브루콘을 포함한 글로벌 컨퍼런스에서 정기적으로 강연합니다.
마티아스는 겐트 대학교에서 컴퓨터 공학 박사 학위를 취득했으며, 프로그램 난독화를 통해 응용 프로그램 보안을 연구하여 응용 프로그램의 내부 작동을 숨깁니다.


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.

아래 링크를 클릭하고 이 자료의 PDF를 다운로드하세요.
Secure Code Warrior 귀사의 조직이 소프트웨어 개발 주기 전반에 걸쳐 코드를 안전하게 보호하고 사이버보안이 최우선 과제인 문화를 조성하도록 Secure Code Warrior . 애플리케이션 보안 담당자, 개발자, IT 보안 책임자 또는 보안 관련 업무에 종사하는 모든 분들을 위해, 저희는 귀사의 조직이 안전하지 않은 코드로 인한 위험을 줄일 수 있도록 돕습니다.
보고서 표시데모 예약하기마티아스 마두는 보안 전문가, 연구원, CTO이자 Secure Code Warrior 의 공동 설립자입니다. 마티아스는 겐트 대학교에서 정적 분석 솔루션에 중점을 둔 애플리케이션 보안 박사 학위를 취득했습니다. 이후 미국의 Fortify에 입사하여 개발자의 보안 코드 작성을 지원하지 않고 코드 문제만 탐지하는 것만으로는 충분하지 않다는 것을 깨달았습니다. 이를 계기로 개발자를 지원하고 보안에 대한 부담을 덜어주며 고객의 기대를 뛰어넘는 제품을 개발하게 되었습니다. 팀 어썸의 일원으로 책상에 앉아 있지 않을 때는 RSA 컨퍼런스, 블랙햇, 데프콘 등의 컨퍼런스에서 무대에 올라 발표하는 것을 즐깁니다.
Matias는 15년 이상의 소프트웨어 보안 경험을 가진 연구원이자 개발자입니다. 그는 Fortify 소프트웨어와 같은 회사와 자신의 회사를 위한 솔루션을 개발했습니다. Sensei 안전. 그의 경력을 통해, Matias는 상용 제품으로 주도하고 자신의 벨트 아래 10 개 이상의 특허를 자랑하는 여러 응용 프로그램 보안 연구 프로젝트를 주도하고있다. 마티아스는 책상에서 떨어져 있을 때 고급 응용 프로그램 보안 교육을 위한 강사로 일했습니다. courses RSA 컨퍼런스, 블랙 햇, 데프콘, BSIMM, OWASP AppSec 및 브루콘을 포함한 글로벌 컨퍼런스에서 정기적으로 강연합니다.
마티아스는 겐트 대학교에서 컴퓨터 공학 박사 학위를 취득했으며, 프로그램 난독화를 통해 응용 프로그램 보안을 연구하여 응용 프로그램의 내부 작동을 숨깁니다.
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.
목차
마티아스 마두는 보안 전문가, 연구원, CTO이자 Secure Code Warrior 의 공동 설립자입니다. 마티아스는 겐트 대학교에서 정적 분석 솔루션에 중점을 둔 애플리케이션 보안 박사 학위를 취득했습니다. 이후 미국의 Fortify에 입사하여 개발자의 보안 코드 작성을 지원하지 않고 코드 문제만 탐지하는 것만으로는 충분하지 않다는 것을 깨달았습니다. 이를 계기로 개발자를 지원하고 보안에 대한 부담을 덜어주며 고객의 기대를 뛰어넘는 제품을 개발하게 되었습니다. 팀 어썸의 일원으로 책상에 앉아 있지 않을 때는 RSA 컨퍼런스, 블랙햇, 데프콘 등의 컨퍼런스에서 무대에 올라 발표하는 것을 즐깁니다.

Secure Code Warrior 귀사의 조직이 소프트웨어 개발 주기 전반에 걸쳐 코드를 안전하게 보호하고 사이버보안이 최우선 과제인 문화를 조성하도록 Secure Code Warrior . 애플리케이션 보안 담당자, 개발자, IT 보안 책임자 또는 보안 관련 업무에 종사하는 모든 분들을 위해, 저희는 귀사의 조직이 안전하지 않은 코드로 인한 위험을 줄일 수 있도록 돕습니다.
데모 예약하기Télécharger



%20(1).avif)
.avif)
