Coders Conquer Security OWASP Top 10 API Series - Mass Assignment
大量赋值漏洞的诞生是因为许多现代框架鼓励开发者使用自动将来自客户端的输入绑定到代码变量和内部对象的函数。这样做是为了简化代码，加快操作速度。
攻击者可以使用这种方法来强制改变客户端不应该更新的对象属性。通常情况下，这将导致特定的业务问题，如用户给自己增加管理权限，而不是使网站瘫痪或窃取企业机密。攻击者还必须对对象和他们所利用的应用程序的业务逻辑之间的关系有一些了解。
然而，这一切都不能使大量分配的漏洞在聪明的恶意用户手中变得不那么危险。
在我们推出完整的指南之前，先玩玩我们的游戏化挑战，看看你的表现如何。
攻击者如何利用大规模分配漏洞？
OWASP提出的方案（我们稍作了修改），假设一个共享汽车的应用程序，包括使用大规模分配绑定到代码中对象的不同属性。这些属性包括用户可以改变的与权限有关的属性和只应由应用程序内部设置的与流程有关的属性。两者都使用大规模赋值将属性绑定到对象上。
在这种情况下，共享汽车应用允许用户更新他们的资料，这在许多面向用户的应用中是很常见的。这是用一个发送到PUT的API调用完成的，它返回以下JSON对象。
{"user_name":"SneakySnake", "age":17, "is_admin":false}
因为攻击者，即本例中的SneakySnake先生，已经弄清了属性和对象之间的关系，他可以重新发送他的原始请求，用以下字符串更新他的资料。
{"user_name":"SneakySnake","age":24,, "is_admin":true}
由于端点容易受到大规模分配的影响，它接受新的输入为有效。我们的黑客不仅在他的个人资料中增加了几年，而且还为自己分配了管理权限。
消除大规模分配的漏洞
尽管在一些框架中使用质量赋值功能可能很方便，但如果你想保持你的API安全，你应该避免这样做。相反，解析请求值，而不是将它们直接绑定到一个对象。你也可以使用一个缩小的数据传输对象，这将提供几乎与直接绑定到对象本身相同的便利，只是没有相关的风险。
作为额外的预防措施，像上面例子中的管理权限这样的敏感属性可以被拒绝，这样它们就永远不会被服务器在API调用中接受。一个更好的主意可能是默认拒绝每一个属性，然后允许特定的、非敏感的属性，你希望用户能够更新或改变。做任何这些事情都可以帮助锁定API，并从你的环境中消除大量分配的漏洞。
请查看 Secure Code Warrior博客页面，了解有关这一漏洞的更多见解，以及如何保护你的组织和客户免受其他安全缺陷的蹂躏。你也可以尝试一下 Secure Code Warrior 培训平台的演示，以保持你所有网络安全技能的磨练和更新。
Matias Madou, Ph.D.是一位安全专家、研究员和CTO，也是Secure Code Warrior 的联合创始人。Matias在根特大学获得了应用安全的博士学位，主要研究静态分析解决方案。后来他加入了美国的Fortify公司，在那里他意识到，仅仅检测代码问题而不帮助开发人员编写安全代码是不够的。这激发了他开发产品的热情，帮助开发人员，减轻安全的负担，并超越客户的期望。当他不在办公桌前作为Awesome团队的一员时，他喜欢站在舞台上，在包括RSA会议、BlackHat和DefCon等会议上发表演讲。
Secure Code Warrior 我们在这里为您的组织提供服务，帮助您在整个软件开发生命周期中确保代码安全，并创造一种将网络安全放在首位的文化。无论您是应用安全经理、开发人员、CISO或任何涉及安全的人，我们都可以帮助您的组织减少与不安全代码有关的风险。
预定一个演示
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。
马蒂亚斯拥有根特大学的计算机工程博士学位，在那里他研究了通过程序混淆来隐藏应用程序的内部工作的应用安全。
大量赋值漏洞的诞生是因为许多现代框架鼓励开发者使用自动将来自客户端的输入绑定到代码变量和内部对象的函数。这样做是为了简化代码，加快操作速度。
攻击者可以使用这种方法来强制改变客户端不应该更新的对象属性。通常情况下，这将导致特定的业务问题，如用户给自己增加管理权限，而不是使网站瘫痪或窃取企业机密。攻击者还必须对对象和他们所利用的应用程序的业务逻辑之间的关系有一些了解。
然而，这一切都不能使大量分配的漏洞在聪明的恶意用户手中变得不那么危险。
在我们推出完整的指南之前，先玩玩我们的游戏化挑战，看看你的表现如何。
攻击者如何利用大规模分配漏洞？
OWASP提出的方案（我们稍作了修改），假设一个共享汽车的应用程序，包括使用大规模分配绑定到代码中对象的不同属性。这些属性包括用户可以改变的与权限有关的属性和只应由应用程序内部设置的与流程有关的属性。两者都使用大规模赋值将属性绑定到对象上。
在这种情况下，共享汽车应用允许用户更新他们的资料，这在许多面向用户的应用中是很常见的。这是用一个发送到PUT的API调用完成的，它返回以下JSON对象。
{"user_name":"SneakySnake", "age":17, "is_admin":false}
因为攻击者，即本例中的SneakySnake先生，已经弄清了属性和对象之间的关系，他可以重新发送他的原始请求，用以下字符串更新他的资料。
{"user_name":"SneakySnake","age":24,, "is_admin":true}
由于端点容易受到大规模分配的影响，它接受新的输入为有效。我们的黑客不仅在他的个人资料中增加了几年，而且还为自己分配了管理权限。
消除大规模分配的漏洞
尽管在一些框架中使用质量赋值功能可能很方便，但如果你想保持你的API安全，你应该避免这样做。相反，解析请求值，而不是将它们直接绑定到一个对象。你也可以使用一个缩小的数据传输对象，这将提供几乎与直接绑定到对象本身相同的便利，只是没有相关的风险。
作为额外的预防措施，像上面例子中的管理权限这样的敏感属性可以被拒绝，这样它们就永远不会被服务器在API调用中接受。一个更好的主意可能是默认拒绝每一个属性，然后允许特定的、非敏感的属性，你希望用户能够更新或改变。做任何这些事情都可以帮助锁定API，并从你的环境中消除大量分配的漏洞。
请查看 Secure Code Warrior博客页面，了解有关这一漏洞的更多见解，以及如何保护你的组织和客户免受其他安全缺陷的蹂躏。你也可以尝试一下 Secure Code Warrior 培训平台的演示，以保持你所有网络安全技能的磨练和更新。
大量赋值漏洞的诞生是因为许多现代框架鼓励开发者使用自动将来自客户端的输入绑定到代码变量和内部对象的函数。这样做是为了简化代码，加快操作速度。
攻击者可以使用这种方法来强制改变客户端不应该更新的对象属性。通常情况下，这将导致特定的业务问题，如用户给自己增加管理权限，而不是使网站瘫痪或窃取企业机密。攻击者还必须对对象和他们所利用的应用程序的业务逻辑之间的关系有一些了解。
然而，这一切都不能使大量分配的漏洞在聪明的恶意用户手中变得不那么危险。
在我们推出完整的指南之前，先玩玩我们的游戏化挑战，看看你的表现如何。
攻击者如何利用大规模分配漏洞？
OWASP提出的方案（我们稍作了修改），假设一个共享汽车的应用程序，包括使用大规模分配绑定到代码中对象的不同属性。这些属性包括用户可以改变的与权限有关的属性和只应由应用程序内部设置的与流程有关的属性。两者都使用大规模赋值将属性绑定到对象上。
在这种情况下，共享汽车应用允许用户更新他们的资料，这在许多面向用户的应用中是很常见的。这是用一个发送到PUT的API调用完成的，它返回以下JSON对象。
{"user_name":"SneakySnake", "age":17, "is_admin":false}
因为攻击者，即本例中的SneakySnake先生，已经弄清了属性和对象之间的关系，他可以重新发送他的原始请求，用以下字符串更新他的资料。
{"user_name":"SneakySnake","age":24,, "is_admin":true}
由于端点容易受到大规模分配的影响，它接受新的输入为有效。我们的黑客不仅在他的个人资料中增加了几年，而且还为自己分配了管理权限。
消除大规模分配的漏洞
尽管在一些框架中使用质量赋值功能可能很方便，但如果你想保持你的API安全，你应该避免这样做。相反，解析请求值，而不是将它们直接绑定到一个对象。你也可以使用一个缩小的数据传输对象，这将提供几乎与直接绑定到对象本身相同的便利，只是没有相关的风险。
作为额外的预防措施，像上面例子中的管理权限这样的敏感属性可以被拒绝，这样它们就永远不会被服务器在API调用中接受。一个更好的主意可能是默认拒绝每一个属性，然后允许特定的、非敏感的属性，你希望用户能够更新或改变。做任何这些事情都可以帮助锁定API，并从你的环境中消除大量分配的漏洞。
请查看 Secure Code Warrior博客页面，了解有关这一漏洞的更多见解，以及如何保护你的组织和客户免受其他安全缺陷的蹂躏。你也可以尝试一下 Secure Code Warrior 培训平台的演示，以保持你所有网络安全技能的磨练和更新。
点击下面的链接，下载本资料的 PDF 文件。
Secure Code Warrior 我们在这里为您的组织提供服务，帮助您在整个软件开发生命周期中确保代码安全，并创造一种将网络安全放在首位的文化。无论您是应用安全经理、开发人员、CISO或任何涉及安全的人，我们都可以帮助您的组织减少与不安全代码有关的风险。
查看报告预定一个演示
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。
马蒂亚斯拥有根特大学的计算机工程博士学位，在那里他研究了通过程序混淆来隐藏应用程序的内部工作的应用安全。
大量赋值漏洞的诞生是因为许多现代框架鼓励开发者使用自动将来自客户端的输入绑定到代码变量和内部对象的函数。这样做是为了简化代码，加快操作速度。
攻击者可以使用这种方法来强制改变客户端不应该更新的对象属性。通常情况下，这将导致特定的业务问题，如用户给自己增加管理权限，而不是使网站瘫痪或窃取企业机密。攻击者还必须对对象和他们所利用的应用程序的业务逻辑之间的关系有一些了解。
然而，这一切都不能使大量分配的漏洞在聪明的恶意用户手中变得不那么危险。
在我们推出完整的指南之前，先玩玩我们的游戏化挑战，看看你的表现如何。
攻击者如何利用大规模分配漏洞？
OWASP提出的方案（我们稍作了修改），假设一个共享汽车的应用程序，包括使用大规模分配绑定到代码中对象的不同属性。这些属性包括用户可以改变的与权限有关的属性和只应由应用程序内部设置的与流程有关的属性。两者都使用大规模赋值将属性绑定到对象上。
在这种情况下，共享汽车应用允许用户更新他们的资料，这在许多面向用户的应用中是很常见的。这是用一个发送到PUT的API调用完成的，它返回以下JSON对象。
{"user_name":"SneakySnake", "age":17, "is_admin":false}
因为攻击者，即本例中的SneakySnake先生，已经弄清了属性和对象之间的关系，他可以重新发送他的原始请求，用以下字符串更新他的资料。
{"user_name":"SneakySnake","age":24,, "is_admin":true}
由于端点容易受到大规模分配的影响，它接受新的输入为有效。我们的黑客不仅在他的个人资料中增加了几年，而且还为自己分配了管理权限。
消除大规模分配的漏洞
尽管在一些框架中使用质量赋值功能可能很方便，但如果你想保持你的API安全，你应该避免这样做。相反，解析请求值，而不是将它们直接绑定到一个对象。你也可以使用一个缩小的数据传输对象，这将提供几乎与直接绑定到对象本身相同的便利，只是没有相关的风险。
作为额外的预防措施，像上面例子中的管理权限这样的敏感属性可以被拒绝，这样它们就永远不会被服务器在API调用中接受。一个更好的主意可能是默认拒绝每一个属性，然后允许特定的、非敏感的属性，你希望用户能够更新或改变。做任何这些事情都可以帮助锁定API，并从你的环境中消除大量分配的漏洞。
请查看 Secure Code Warrior博客页面，了解有关这一漏洞的更多见解，以及如何保护你的组织和客户免受其他安全缺陷的蹂躏。你也可以尝试一下 Secure Code Warrior 培训平台的演示，以保持你所有网络安全技能的磨练和更新。
目录
Matias Madou, Ph.D.是一位安全专家、研究员和CTO，也是Secure Code Warrior 的联合创始人。Matias在根特大学获得了应用安全的博士学位，主要研究静态分析解决方案。后来他加入了美国的Fortify公司，在那里他意识到，仅仅检测代码问题而不帮助开发人员编写安全代码是不够的。这激发了他开发产品的热情，帮助开发人员，减轻安全的负担，并超越客户的期望。当他不在办公桌前作为Awesome团队的一员时，他喜欢站在舞台上，在包括RSA会议、BlackHat和DefCon等会议上发表演讲。
Secure Code Warrior 我们在这里为您的组织提供服务，帮助您在整个软件开发生命周期中确保代码安全，并创造一种将网络安全放在首位的文化。无论您是应用安全经理、开发人员、CISO或任何涉及安全的人，我们都可以帮助您的组织减少与不安全代码有关的风险。
预定一个演示下载资源
安全技能基准测试：简化企业安全设计
寻找有关 "按设计确保安全 "计划成功与否的有意义的数据是众所周知的难题。首席信息安全官（CISO）在试图证明投资回报率（ROI）和安全计划活动在人员和公司层面上的商业价值时，往往会面临挑战。更不用说，企业要深入了解自己的组织是如何以当前的行业标准为基准的，更是难上加难。美国总统的《国家网络安全战略》向利益相关者提出了 "通过设计实现安全和弹性 "的挑战。让 "按设计保证安全 "计划发挥作用的关键不仅在于为开发人员提供确保代码安全的技能，还在于向监管机构保证这些技能已经到位。在本演讲中，我们将分享大量定性和定量数据，这些数据来自多个主要来源，包括从超过 25 万名开发人员那里收集的内部数据点、数据驱动的客户洞察力以及公共研究。利用这些数据点的汇总，我们旨在传达一个跨多个垂直领域的 "按设计保证安全 "计划的现状。报告详细阐述了这一领域目前未得到充分利用的原因、成功的技能提升计划对降低网络安全风险的重大影响，以及消除代码库中各类漏洞的潜力。
