
程序员征服安全 OWASP 十大 API 系列-缺乏资源和速率限制
由于缺乏资源和速率限制,API 漏洞的行为几乎完全符合标题的描述。每个 API 的可用资源和计算能力都有限,具体取决于其环境。大多数人还必须回答用户或其他程序的请求,要求其执行所需的功能。当同时传入的请求过多,且 API 没有足够的计算资源来处理这些请求时,就会出现此漏洞。然后,该 API 可能变得不可用或无法响应新请求。
如果 API 的速率或资源限制设置不正确,或者代码中未定义限制,则容易受到此问题的影响。例如,如果企业遇到特别繁忙的时期,则API可能会过载。但这也是一个安全漏洞,因为威胁行为者可以故意使用请求使未受保护的 API 过载,以执行拒绝服务 (DDoS) 攻击。
顺便问一下,到目前为止,你在 API 游戏化挑战中表现如何?如果你想立即尝试处理速率限制漏洞的技能,那就进入竞技场:
现在,让我们更深入地了解一下。
缺乏资源和速率限制 API 漏洞的一些例子有哪些?
此漏洞可以通过两种方式潜入 API。首先是编码人员根本没有定义API的油门速率应该是多少。基础设施中的某个地方可能有默认的油门费率设置,但依赖它并不是一个好政策。相反,每个 API 都应单独设置其费率。尤其如此,因为 API 可能具有截然不同的功能和可用资源。
例如,设计为仅为少数用户服务的内部 API 的油门速率可能非常低并且运行良好。但是,作为实时电子商务网站一部分的面向公众的API很可能需要定义极高的速率来弥补同时用户激增的可能性。在这两种情况下,节流速率都应根据预期需求、潜在用户数量和可用计算能力来定义。
为了最大限度地提高性能,将速率设置为无限可能会很诱人,尤其是在很可能非常繁忙的 API 中。这可以通过一段简单的代码来完成(例如,我们将使用 Python Django REST框架):
“默认节流速率:{
“不知道:没有,
“用户:无
在该示例中,匿名用户和系统已知用户都可以无限次地联系 API,而不考虑一段时间内的请求数量。这是个坏主意,因为无论API有多少可用的计算资源,攻击者都可以部署僵尸网络之类的东西,从而最终减慢其爬行速度,或者可能将其完全下线。发生这种情况时,有效用户将被拒绝访问,攻击将成功。
消除资源短缺和速率限制问题
组织部署的每个 API 都应在其代码中定义其限制率。这可能包括执行超时、最大允许内存、可以返回给用户的每页记录数或在定义的时间范围内允许的进程数量等内容。
从上面的示例中可以看出,与其完全开放限制速率,不如对匿名用户和已知用户使用不同的费率来严格定义节流速率。
“默认节流速率:{
“匿名:配置(“THROTTLE_ANON,默认值 = 200/小时),
“用户:配置(“THROTTLE_USER,默认值 = 5000/小时)
在新示例中,API 将限制匿名用户每小时发出 200 个请求。已通过系统审核的已知用户将获得更大的回旋余地,每小时 5,000 个请求。但是,即使它们也仅限于防止高峰时段意外过载,或者在用户帐户遭到入侵并被用于拒绝服务攻击时进行补偿。
作为最后要考虑的良好做法,最好在用户达到限制时向他们显示通知,并解释何时重置这些限制。这样,有效的用户就会知道应用程序拒绝他们的请求的原因。如果执行经批准的任务的有效用户被拒绝访问 API,这也会很有用,因为它可以向操作人员发出信号,表明需要加强限制。
来看看 安全代码勇士 博客页面,详细了解此漏洞以及如何保护您的组织和客户免受其他安全漏洞的破坏。你也可以 试试演示 Secure Code Warrior 培训平台可让您的所有网络安全技能不断磨练并保持最新状态。
Matias Madou, Ph.D.是一位安全专家、研究员和CTO,也是Secure Code Warrior 的联合创始人。Matias在根特大学获得了应用安全的博士学位,主要研究静态分析解决方案。后来他加入了美国的Fortify公司,在那里他意识到,仅仅检测代码问题而不帮助开发人员编写安全代码是不够的。这激发了他开发产品的热情,帮助开发人员,减轻安全的负担,并超越客户的期望。当他不在办公桌前作为Awesome团队的一员时,他喜欢站在舞台上,在包括RSA会议、BlackHat和DefCon等会议上发表演讲。

Secure Code Warrior可帮助您的组织在整个软件开发生命周期中保护代码,并营造一种将网络安全置于首位的文化。无论您是应用安全经理、开发人员、首席信息安全官还是任何与安全相关的人员,我们都能帮助您的组织降低与不安全代码相关的风险。
预约演示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。
马蒂亚斯拥有根特大学的计算机工程博士学位,在那里他研究了通过程序混淆来隐藏应用程序的内部工作的应用安全。


由于缺乏资源和速率限制,API 漏洞的行为几乎完全符合标题的描述。每个 API 的可用资源和计算能力都有限,具体取决于其环境。大多数人还必须回答用户或其他程序的请求,要求其执行所需的功能。当同时传入的请求过多,且 API 没有足够的计算资源来处理这些请求时,就会出现此漏洞。然后,该 API 可能变得不可用或无法响应新请求。
如果 API 的速率或资源限制设置不正确,或者代码中未定义限制,则容易受到此问题的影响。例如,如果企业遇到特别繁忙的时期,则API可能会过载。但这也是一个安全漏洞,因为威胁行为者可以故意使用请求使未受保护的 API 过载,以执行拒绝服务 (DDoS) 攻击。
顺便问一下,到目前为止,你在 API 游戏化挑战中表现如何?如果你想立即尝试处理速率限制漏洞的技能,那就进入竞技场:
现在,让我们更深入地了解一下。
缺乏资源和速率限制 API 漏洞的一些例子有哪些?
此漏洞可以通过两种方式潜入 API。首先是编码人员根本没有定义API的油门速率应该是多少。基础设施中的某个地方可能有默认的油门费率设置,但依赖它并不是一个好政策。相反,每个 API 都应单独设置其费率。尤其如此,因为 API 可能具有截然不同的功能和可用资源。
例如,设计为仅为少数用户服务的内部 API 的油门速率可能非常低并且运行良好。但是,作为实时电子商务网站一部分的面向公众的API很可能需要定义极高的速率来弥补同时用户激增的可能性。在这两种情况下,节流速率都应根据预期需求、潜在用户数量和可用计算能力来定义。
为了最大限度地提高性能,将速率设置为无限可能会很诱人,尤其是在很可能非常繁忙的 API 中。这可以通过一段简单的代码来完成(例如,我们将使用 Python Django REST框架):
“默认节流速率:{
“不知道:没有,
“用户:无
在该示例中,匿名用户和系统已知用户都可以无限次地联系 API,而不考虑一段时间内的请求数量。这是个坏主意,因为无论API有多少可用的计算资源,攻击者都可以部署僵尸网络之类的东西,从而最终减慢其爬行速度,或者可能将其完全下线。发生这种情况时,有效用户将被拒绝访问,攻击将成功。
消除资源短缺和速率限制问题
组织部署的每个 API 都应在其代码中定义其限制率。这可能包括执行超时、最大允许内存、可以返回给用户的每页记录数或在定义的时间范围内允许的进程数量等内容。
从上面的示例中可以看出,与其完全开放限制速率,不如对匿名用户和已知用户使用不同的费率来严格定义节流速率。
“默认节流速率:{
“匿名:配置(“THROTTLE_ANON,默认值 = 200/小时),
“用户:配置(“THROTTLE_USER,默认值 = 5000/小时)
在新示例中,API 将限制匿名用户每小时发出 200 个请求。已通过系统审核的已知用户将获得更大的回旋余地,每小时 5,000 个请求。但是,即使它们也仅限于防止高峰时段意外过载,或者在用户帐户遭到入侵并被用于拒绝服务攻击时进行补偿。
作为最后要考虑的良好做法,最好在用户达到限制时向他们显示通知,并解释何时重置这些限制。这样,有效的用户就会知道应用程序拒绝他们的请求的原因。如果执行经批准的任务的有效用户被拒绝访问 API,这也会很有用,因为它可以向操作人员发出信号,表明需要加强限制。
来看看 安全代码勇士 博客页面,详细了解此漏洞以及如何保护您的组织和客户免受其他安全漏洞的破坏。你也可以 试试演示 Secure Code Warrior 培训平台可让您的所有网络安全技能不断磨练并保持最新状态。

由于缺乏资源和速率限制,API 漏洞的行为几乎完全符合标题的描述。每个 API 的可用资源和计算能力都有限,具体取决于其环境。大多数人还必须回答用户或其他程序的请求,要求其执行所需的功能。当同时传入的请求过多,且 API 没有足够的计算资源来处理这些请求时,就会出现此漏洞。然后,该 API 可能变得不可用或无法响应新请求。
如果 API 的速率或资源限制设置不正确,或者代码中未定义限制,则容易受到此问题的影响。例如,如果企业遇到特别繁忙的时期,则API可能会过载。但这也是一个安全漏洞,因为威胁行为者可以故意使用请求使未受保护的 API 过载,以执行拒绝服务 (DDoS) 攻击。
顺便问一下,到目前为止,你在 API 游戏化挑战中表现如何?如果你想立即尝试处理速率限制漏洞的技能,那就进入竞技场:
现在,让我们更深入地了解一下。
缺乏资源和速率限制 API 漏洞的一些例子有哪些?
此漏洞可以通过两种方式潜入 API。首先是编码人员根本没有定义API的油门速率应该是多少。基础设施中的某个地方可能有默认的油门费率设置,但依赖它并不是一个好政策。相反,每个 API 都应单独设置其费率。尤其如此,因为 API 可能具有截然不同的功能和可用资源。
例如,设计为仅为少数用户服务的内部 API 的油门速率可能非常低并且运行良好。但是,作为实时电子商务网站一部分的面向公众的API很可能需要定义极高的速率来弥补同时用户激增的可能性。在这两种情况下,节流速率都应根据预期需求、潜在用户数量和可用计算能力来定义。
为了最大限度地提高性能,将速率设置为无限可能会很诱人,尤其是在很可能非常繁忙的 API 中。这可以通过一段简单的代码来完成(例如,我们将使用 Python Django REST框架):
“默认节流速率:{
“不知道:没有,
“用户:无
在该示例中,匿名用户和系统已知用户都可以无限次地联系 API,而不考虑一段时间内的请求数量。这是个坏主意,因为无论API有多少可用的计算资源,攻击者都可以部署僵尸网络之类的东西,从而最终减慢其爬行速度,或者可能将其完全下线。发生这种情况时,有效用户将被拒绝访问,攻击将成功。
消除资源短缺和速率限制问题
组织部署的每个 API 都应在其代码中定义其限制率。这可能包括执行超时、最大允许内存、可以返回给用户的每页记录数或在定义的时间范围内允许的进程数量等内容。
从上面的示例中可以看出,与其完全开放限制速率,不如对匿名用户和已知用户使用不同的费率来严格定义节流速率。
“默认节流速率:{
“匿名:配置(“THROTTLE_ANON,默认值 = 200/小时),
“用户:配置(“THROTTLE_USER,默认值 = 5000/小时)
在新示例中,API 将限制匿名用户每小时发出 200 个请求。已通过系统审核的已知用户将获得更大的回旋余地,每小时 5,000 个请求。但是,即使它们也仅限于防止高峰时段意外过载,或者在用户帐户遭到入侵并被用于拒绝服务攻击时进行补偿。
作为最后要考虑的良好做法,最好在用户达到限制时向他们显示通知,并解释何时重置这些限制。这样,有效的用户就会知道应用程序拒绝他们的请求的原因。如果执行经批准的任务的有效用户被拒绝访问 API,这也会很有用,因为它可以向操作人员发出信号,表明需要加强限制。
来看看 安全代码勇士 博客页面,详细了解此漏洞以及如何保护您的组织和客户免受其他安全漏洞的破坏。你也可以 试试演示 Secure Code Warrior 培训平台可让您的所有网络安全技能不断磨练并保持最新状态。

点击下面的链接并下载此资源的PDF。
Secure Code Warrior可帮助您的组织在整个软件开发生命周期中保护代码,并营造一种将网络安全置于首位的文化。无论您是应用安全经理、开发人员、首席信息安全官还是任何与安全相关的人员,我们都能帮助您的组织降低与不安全代码相关的风险。
查看报告预约演示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。
马蒂亚斯拥有根特大学的计算机工程博士学位,在那里他研究了通过程序混淆来隐藏应用程序的内部工作的应用安全。
由于缺乏资源和速率限制,API 漏洞的行为几乎完全符合标题的描述。每个 API 的可用资源和计算能力都有限,具体取决于其环境。大多数人还必须回答用户或其他程序的请求,要求其执行所需的功能。当同时传入的请求过多,且 API 没有足够的计算资源来处理这些请求时,就会出现此漏洞。然后,该 API 可能变得不可用或无法响应新请求。
如果 API 的速率或资源限制设置不正确,或者代码中未定义限制,则容易受到此问题的影响。例如,如果企业遇到特别繁忙的时期,则API可能会过载。但这也是一个安全漏洞,因为威胁行为者可以故意使用请求使未受保护的 API 过载,以执行拒绝服务 (DDoS) 攻击。
顺便问一下,到目前为止,你在 API 游戏化挑战中表现如何?如果你想立即尝试处理速率限制漏洞的技能,那就进入竞技场:
现在,让我们更深入地了解一下。
缺乏资源和速率限制 API 漏洞的一些例子有哪些?
此漏洞可以通过两种方式潜入 API。首先是编码人员根本没有定义API的油门速率应该是多少。基础设施中的某个地方可能有默认的油门费率设置,但依赖它并不是一个好政策。相反,每个 API 都应单独设置其费率。尤其如此,因为 API 可能具有截然不同的功能和可用资源。
例如,设计为仅为少数用户服务的内部 API 的油门速率可能非常低并且运行良好。但是,作为实时电子商务网站一部分的面向公众的API很可能需要定义极高的速率来弥补同时用户激增的可能性。在这两种情况下,节流速率都应根据预期需求、潜在用户数量和可用计算能力来定义。
为了最大限度地提高性能,将速率设置为无限可能会很诱人,尤其是在很可能非常繁忙的 API 中。这可以通过一段简单的代码来完成(例如,我们将使用 Python Django REST框架):
“默认节流速率:{
“不知道:没有,
“用户:无
在该示例中,匿名用户和系统已知用户都可以无限次地联系 API,而不考虑一段时间内的请求数量。这是个坏主意,因为无论API有多少可用的计算资源,攻击者都可以部署僵尸网络之类的东西,从而最终减慢其爬行速度,或者可能将其完全下线。发生这种情况时,有效用户将被拒绝访问,攻击将成功。
消除资源短缺和速率限制问题
组织部署的每个 API 都应在其代码中定义其限制率。这可能包括执行超时、最大允许内存、可以返回给用户的每页记录数或在定义的时间范围内允许的进程数量等内容。
从上面的示例中可以看出,与其完全开放限制速率,不如对匿名用户和已知用户使用不同的费率来严格定义节流速率。
“默认节流速率:{
“匿名:配置(“THROTTLE_ANON,默认值 = 200/小时),
“用户:配置(“THROTTLE_USER,默认值 = 5000/小时)
在新示例中,API 将限制匿名用户每小时发出 200 个请求。已通过系统审核的已知用户将获得更大的回旋余地,每小时 5,000 个请求。但是,即使它们也仅限于防止高峰时段意外过载,或者在用户帐户遭到入侵并被用于拒绝服务攻击时进行补偿。
作为最后要考虑的良好做法,最好在用户达到限制时向他们显示通知,并解释何时重置这些限制。这样,有效的用户就会知道应用程序拒绝他们的请求的原因。如果执行经批准的任务的有效用户被拒绝访问 API,这也会很有用,因为它可以向操作人员发出信号,表明需要加强限制。
来看看 安全代码勇士 博客页面,详细了解此漏洞以及如何保护您的组织和客户免受其他安全漏洞的破坏。你也可以 试试演示 Secure Code Warrior 培训平台可让您的所有网络安全技能不断磨练并保持最新状态。
目录
Matias Madou, Ph.D.是一位安全专家、研究员和CTO,也是Secure Code Warrior 的联合创始人。Matias在根特大学获得了应用安全的博士学位,主要研究静态分析解决方案。后来他加入了美国的Fortify公司,在那里他意识到,仅仅检测代码问题而不帮助开发人员编写安全代码是不够的。这激发了他开发产品的热情,帮助开发人员,减轻安全的负担,并超越客户的期望。当他不在办公桌前作为Awesome团队的一员时,他喜欢站在舞台上,在包括RSA会议、BlackHat和DefCon等会议上发表演讲。

Secure Code Warrior可帮助您的组织在整个软件开发生命周期中保护代码,并营造一种将网络安全置于首位的文化。无论您是应用安全经理、开发人员、首席信息安全官还是任何与安全相关的人员,我们都能帮助您的组织降低与不安全代码相关的风险。
预约演示下载



%20(1).avif)
.avif)
