本篇文章共5268字，预计阅读时间17分钟。

API #6: Mass Assignment（批量分配）

“批量分配”是指一次为多个变量或对象属性赋值的做法，但是这个功能怎么会导致安全漏洞呢？让我们通过一个示例来一探究竟：

对象属性

应用程序对象通常具有很多个对象属性，例如，假设“User”对象用于在应用程序中存储用户信息，它包含的用户的属性有用户ID、名称、位置等。

{  "id": 12345,  "name": "Vickie",  "location": "San Francisco, CA",  "admin": false,  "group_membership": [121, 322, 457]}

在这种情况下，用户能够修改该对象中的某些属性，如Location和Name属性，但是这个User对象的其他部分应该被限制为不允许用户访问，比如“admin”属性，它表示用户是否是管理员，“group_membership”属性，它用于记录用户属于哪个用户组。

批量分配漏洞

当应用程序自动将用户输入分配给多个程序的变量或对象时，就会出现大量赋值漏洞，这是许多旨在简化开发应用程序框架中的一个功能。

但此功能有时允许攻击者随意覆盖、修改或创建新的程序变量或对象属性，例如，假设该站点允许用户通过PUT请求更改他们的姓名，如下所示，该请求将用户12345的名称从“Vickie”更新为“Vickie Li”。

PUT /api/v1.1/user/12345{  "name": "Vickie Li"}

那么，如果恶意用户提交了此请求会怎样？

PUT /api/v1.1/user/12345{  "name": "Vickie Li",   "admin": true}

如果应用程序使用批量分配来自动更新用户属性，则此请求还将更新用户的“ADMIN”字段，并授予用户12345管理员权限，这就是典型的批量赋值漏洞。

同样，恶意用户也可以通过该漏洞将自己分配到新的私有用户组：

PUT /api/v1.1/user/12345{  "name": "Vickie Li",   "admin": true,   "group_membership": [1, 35, 121, 322, 457]}

而要防止批量分配漏洞，可以禁用框架中的批量分配功能，或使用白名单仅允许对某些属性或变量进行分配。

API #7: Security Misconfiguration（安全配置错误）

安全配置错误是API和非API应用程序面临的持续威胁，让我们来看看API中几个常见的安全错误配置，以及它们如何影响API。

详细错误消息

首先，最常见的安全错误配置之一是向用户发送详细的错误消息，这些冗长的错误消息可能包含堆栈跟踪、有关系统的信息(如服务器版本或底层数据库结构)，并让用户深入了解应用程序幕后是如何工作的，在这种情况下，恶意用户可以通过应用程序的错误消息(通过提供格式错误或非法的输入)来收集有关服务器的信息。

许多默认的404页面还包含了允许攻击者进行指纹识别的自定义签名，Ruby on Rails框架就是一个典型例子。

错误配置的HTTP标头

另一种常见错误配置是误用或缺少HTTP标头（headers），有许多HTTP安全标头可帮助增强应用程序的安全性，如果没有正确配置，攻击者通常可以找到允许他们泄露数据的安全漏洞，或者对应用程序的用户执行常见的网络攻击。

例如，Content-Security-Policy(CSP)头控制着允许浏览器为页面加载哪些资源，应将其设置为禁止来自随机域的脚本、内联脚本和事件处理HTML属性，以防止XSS跨站点脚本攻击，有关如何安全配置CSP的详细信息，可移步：

https://blog.shiftleft.io/intro-to-the-content-security-policy-csp-c29266fa095f

CORS(跨域资源共享)配置错误也是HTTP报头配置错误导致的安全问题，CORS是放宽同源策略(SOP)的一种安全方式，它允许服务器通过Access-Control-Allow-Origin标头显式指定允许访问其资源的源列表，访问-控制-允许-来源应配置为仅允许来自受信任站点的跨域通信，错误配置的CORS策略使得攻击者能够通过扰乱跨域通信来窃取机密数据。有关攻击者如何利用错误配置的CORS的更多信息，可移步：

https://medium.com/swlh/hacking-the-same-origin-policy-f9f49ad592fc

不必要的服务或HTTP方法

另一个常见的错误配置是无法关闭不必要的服务或HTTP方法，功能级授权破坏一节中提到了以下示例，API允许用户通过向站点发送GET请求来检索博客帖子，如下所示：

GET /api/v1.1/user/12358/posts?id=32

同时我们还讨论了站点如何允许管理员通过特殊的API请求查看网站的统计数据：

GET /api/v1.1/site/stats/hd216zla

由于未对任何用户进行限制，该URL在末尾包含一个随机字符串，以防止未经授权的用户访问它，但是，作为唯一的安全机制并不可靠，如果攻击者可以通过信息泄漏找到这个URL，则攻击者就可以访问相应的敏感功能，让像这样的敏感服务对外开放可能会导致恶意用户的访问。

不安全的默认配置

默认情况下，许多第三方依赖项(如数据库和Web框架)都是不安全的，需要开发人员通过自定义配置来加强安全性，例如，旧版本的MongoDB可以通过互联网访问，默认情况下不需要身份验证，如果开发人员不更改默认配置，就导致数千个数据库向公众公开。

如果开发人员没有意识到这些后果，像本例这样的不安全默认配置可能会导致许多严重的安全问题，要了解如何设置MongoDB数据库的身份验证，可移步：

https://docs.mongodb.com/manual/tutorial/enable-authentication/

需要注意的是，此列表并不包括API可能发生的所有安全错误配置；相反，它是对最常见的安全错误配置的概述，这位女黑客希望这个列表将帮助消除API系统中最常见的安全错误配置，并帮助各位考虑API中的其他潜在安全漏洞！

API #8: Injection（注入）

注入是大量漏洞(如SQL注入、操作系统命令注入和XML注入)的根本问题，在应用程序和API中发现的漏洞中，注入占据了很大比例。

注入是如何发生的？

简而言之，当应用程序不能正确区分不受信任的用户数据和代码时，就会发生注入。

不受信任的用户数据可以是HTTP请求参数、HTTP标头和Cookie，它们还可以来自用户修改的数据或存储的文件，如果应用程序将不受信任的用户数据插入或查询之前没有正确处理这些数据，则程序的解释器会将用户输入混淆为命令或查询的一部分，在这种情况下，攻击者可以通过更改其命令的方式向应用程序发送数据。

例如，在SQL注入攻击中，攻击者注入数据来操作SQL命令，在命令注入攻击中，攻击者在宿主服务器上注入OS系统命令数据，任何将用户数据与命令或代码相结合的程序都可能存在潜在漏洞。

注入漏洞也会影响API系统，因为API只是不受信任的用户输入进入应用程序的另一种方式，让我们来看看API中的注入漏洞是如何出现的。

案例 #1: 检索博客发帖

假设API允许其用户通过发送如下所示的GET请求来检索博客帖子：

GET /api/v1.1/posts?id=12358

该请求会导致接口返回12358的博客帖子，服务器将使用SQL查询从数据库中检索相应的数据，其中post_id指的是用户通过URL传入的id。

SELECT * FROM posts WHERE post_id = 12358

那么，假如用户改为从API接口进行请求，会怎样呢？

GET /api/v1.1/posts?id=12358; DROP TABLE users

SQL服务器会将分号之后的ID部分单独解释为的SQL命令，因此，SQL引擎将首先像往常一样执行此命令来检索博客帖子：

SELECT * FROM posts WHERE post_id = 12358;

接着将执行此命令来删除USERS表，导致应用程序丢失存储在该表中的数据：

DROP TABLE users

这被称为典型的SQL注入攻击，只要用户输入不安全的方式传递到SQL查询中，就会发生这种情况，注意，API中的用户输入不仅可以通过URL参数传输，还可以通过POST请求、URL路径参数等到达应用程序，所以确保这些地方的安全也很重要。

案例 #2: 读取系统文件

假设该站点允许用户读取他们通过API接口上传的文件：

GET /api/v1.1/files?id=1123581321

上面的请求可能会使服务器通过系统命令检索用户文件：

cat /var/www/html/users/tmp/1123581321

在这种情况下，用户可以通过在分号后面添加附加命令来将新命令注入到OS系统命令中：

GET /api/v1.1/files?id=1123581321; rm -rf /var/www/html/users

此命令将强制服务器删除位于/var/www/html/users的文件夹，该文件夹是应用程序存储用户信息的位置。

如何防止API中的注入漏洞

以上都是注入漏洞的一些简化示例，在实战中是要记住注入漏洞并不总是那么明显，在处理或使用用户输入的数据时，随时都可能发生操作，即使恶意用户数据没有立即被使用，不受信任的数据也可能最终在程序中的某个地方传播，从而可能会做一些例如危险的功能或不受保护的查询。

我们应该明白为什么注入是如此难以预防，不受信任的数据可以攻击其下游触及的任何应用程序组件，同时，对于应用程序接收到的每一条不可信数据，它都需要检测并消除针对应用程序每个部分的攻击，应用程序可能会得出结论，认为一段数据是安全的，因为它不包含任何用于触发XSS的特殊字符-但是攻击者实际上是打算触发SQL注入。

输入验证

那么您如何防范这些威胁呢？第一件事就是验证不受信任的数据，这意味着要么“黑名单”以拒绝任何包含可能影响应用程序组件的危险字符输入，或者采用“白名单”，仅允许具有已知良好字符的输入字符串，例如，假设注册功能，由于知道数据将被插入到 SQL 查询中，因此可以拒绝任何在 SQL 中属于特殊字符的用户名输入，例如单引号，或者仅允许使用字母、数字、字符的规则。

但有时“黑名单”很难做到防范，因为你并不总是知道哪些字符对应用程序组件很重要，如果恰好错过了一个特殊字符，那么攻击者就可以绕过保护。

参数化

另一种注入防护是参数化，参数化是指在插入任何用户输入的数据前编译命令的代码部分。

这意味着不是将用户的输入直接发送到服务器进行编译，而是首先定义所有逻辑，编译它，然后在执行之前将用户的输入插入，将用户的输入插入后，该命令将不再被解析和编译，任何不在原始语句中的内容都将被视为字符串数据，而不是可执行代码。

这将允许数据库区分命令的代码部分和数据部分，而不管用户的输入是什么样的，这种方法对于防止一些注入漏洞非常有效，但并不能在代码中的上下文中使用。

逃逸

最后，可以通过转义特殊字符，转义意味着对用户输入中的特殊字符进行编码，以便将它们视为数据，而不是特殊字符，通过使用特殊标记和语法标记用户输入中的特殊字符，从而使解释器知道不对数据执行操作。

但是这种方法也有它的问题，首先，您必须为每个下游解析器使用准确的编码语法，否则可能会有解析器误解编码值的风险，您还可能忘记转义某些字符，攻击者可以使用这些字符来尝试编码绕过，因此，防止注入漏洞的关键是了解不同语言的解析器是如何工作的，以及哪些解析器在流程中最先运行。

API #9: Improper Assets Management（不当的资产管理）

尽管“不当的资产管理”听起来很复杂，但其本质是：未能保持API节点的跟踪，可能是由于API文档不完整，也可能是因为完全缺少API文档，但是为什么API文档的缺失是一个安全问题呢？

API通常有许多不同的版本、功能、节点和许多影响该节点行为的参数，如果没有跟踪所有这些功能，就意识不到隐藏在节点中的未知安全漏洞。

除了文档不完整或丢失外，文档不准确也是一个安全问题，即使有详细说明API节点的文档，它能否描述每个节点的功能？节点是否有文档中没有记录的行为，例如接受替换HTTP的方法？是否有任何未记录的参数会影响节点的功能？不准确的文档可能会让您认为节点是安全的，而实际上它的行为并不是你想像的那样。

一些例子

例如，假设您在API端点上发现了一个敏感信息泄漏。但是您不知道具有相同信息泄漏漏洞的旧版本API也向公众开放。因此，您没有减轻旧版本中的漏洞，攻击者仍然可以通过旧版本的API利用该漏洞。

或者，您可能希望将某些敏感端点的访问权限限制为站点管理员。但是，如果没有每个端点及其功能的详细记录，您就无法决定应该限制哪些端点。

敏感数据泄露、授权问题、OWASP API前十名以及许多其他漏洞通常会在API中显现出来。但是您无法测试和保护您不了解的端点。

如何来保护API？

最佳方法是提供有关API主机、版本、节点及其参数和预期行为的详细文档，始终如一地记录，并记录所有内容！确保其他使用API的人员可以访问相应的文档，像往常一样，扫描API以查找常见漏洞，并定期审核所有API节点的安全性。

不当的资产管理乍看起来可能不是问题，但从长远来看，如果没有全面的API的文档，实际上是非常危险的。

API #10: Insufficient Logging & Monitoring（日志记录和监控不足）

到目前为止，在这份API安全指南中，我们已经讨论了可以采取的措施，以防止针对API的恶意攻击，但是，在攻击者找到攻击应用程序或API的方法之后会发生什么呢？

在攻击者获得对系统的初始访问权限后，他们将开始利用最初的立足点来探索和利用网络，他们可能会在计算机上查找更多可利用的漏洞，执行侦察以发现其他计算机，发现的新漏洞，建立对系统的持久访问，或者跨网络从其他计算机中窃取数据等等。

网络攻击不会在几个小时甚至几天内发生，攻击者往往需要时间来探索网络并构建合适的策略来充分利用系统并窃取其中包含的数据，攻击者能够在未被检测到的情况下访问系统的时间越长，就越有可能找到攻击系统、窃取数据并对应用程序及其用户造成广泛损害的方法，这就是为什么有一个能够尽快检测恶意活动的日志记录和监控系统是至关重要的。

许多组织通常只有基础架构的日志记录，如记录网络事件和服务器登录事件，而缺乏API或特定于应用程序的监控架构，这意味着你无法洞察网络中正在进行的恶意活动，因此你需要一个负责监视异常API使用的API日志记录的系统，然后记录事件：如输入验证失败、身份验证授权成功和失败、应用程序错误，以及处理敏感功能(如支付、帐户设置等)的任何其他API事件，随着时间的推移，你将能够梳理出API的正常使用情况，并检测可能是攻击的可疑活动。

一旦设置了日志记录和监控，请确保在发生安全事件时具有有效的警报系统，毕竟，只有当监测系统的结果能够及时交付给正确的人时，监测系统才是有用的，这样，安全团队才可以尽快地解决该事件，并限制对攻击者系统的损坏。

====正文结束====

原文始发于微信公众号（骨哥说事）：国外一位女黑客分享的API 安全指南（下篇）