黑盒视角下的RESTful API安全测试

目录

• 前言
  • 关于OWASP API TOP 10
• REST API接口测试思路
  • 接口权限测试
  • 接口校验测试
  • 接口滥用测试
• 总结

前言

RESTful API（或称RESTful Web API）在线开放API项目上是一个大的流行趋势，企业API开放平台或多或少都会采用RESTful风格描述的API规范。

RESTful API以资源（Resource）为导向，将所有事物都抽象为资源，统一接口。具有无状态、可表示、分层系统等特点。关于RESTful API的更多设计概要可参考：https://www.explinks.com/wiki/restful-api-best-practices-01/

关于OWASP API TOP 10

不妨先看看在2023年发布的OWASP API Top 10清单：

• API1:2023 - Broken Object Level Authorization（失效的对象级授权）：指的是API未能正确实施对象级别的权限控制，导致未授权访问或数据泄露

• API2:2023 - Broken Authentication（失效的用户认证）：涉及到认证机制的弱点，可能允许攻击者绕过认证或冒充其他用户

• API3:2023 - Broken Object Property Level Authorization（失效的对象属性级授权）：关注于API未能正确实施属性级别的权限控制

• API4:2023 - Unrestricted Resource Consumption（资源消耗无限制）：强调API未能限制资源的使用，可能导致资源耗尽攻击

• API5:2023 - Broken Function Level Authorization（失效的功能级别授权）：指的是API未能正确实施功能级别的权限控制

• API6:2023 - Unrestricted Access to Sensitive Business Flows（访问敏感业务流无限制）：应对新的威胁，包括大多数可以通过限速来缓解的威胁

• API7:2023 - Server Side Request Forgery（服务器端请求伪造SSRF）：当API在获取远程资源时未能验证用户提供的URI，攻击者可以迫使应用向意外的目标发送精心构造的请求

• API8:2023 - Security Misconfiguration（安全配置错误）：如果配置不当或未遵循安全最佳实践，可能会导致各种类型的攻击

• API9:2023 - Improper Inventory Management（不当的库存管理）：API比传统Web应用暴露更多的端点，因此以减轻过时API版本和暴露的调试端点等问题

• API10:2023 - Unsafe Consumption of APIs（API的不安全使用）：开发者往往比用户输入更信任从第三方API接收的数据，因此采用较弱的安全标准

每个风险都代表了API安全中的一个关键点，其中可以看得到关于授权和认证两个点风险分布要多一些，包括对象级授权、属性级授权和功能级授权的失效，认证机制被绕过等，这也是API安全测试中主要遇到的问题。

REST API接口测试思路

可以借助OWASP的crAPI这个项目，从一个完整的黑盒测试的视角了解一下这类API接口的测试思路。

crAPI项目地址：https://github.com/OWASP/crAPI

项目提供了docker快速部署靶场环境（需要先安装docker以及docker-compose），Linux系统环境下docker执行以下命令：

curl -o docker-compose.yml https://raw.githubusercontent.com/OWASP/crAPI/main/deploy/docker/docker-compose.yml

docker-compose pull

docker-compose -f docker-compose.yml --compatibility up -d

如果想偷个懒，或者在部署的过程中遇到困难，也可使用这个在线环境：http://crapi.apisec.ai/

接口权限测试

顾名思义，测试对外提供服务的接口是否存在权限缺陷，例如在请求接口时，是否对用户权限进行严格校验，是否存在水平越权、垂直越权或者未授权访问的风险。

1. 失效的对象级授权

对象级授权是一种访问控制机制，依赖用户请求参数中的对象ID来决定访问哪些目标对象，以验证用户只能访问他们应该有权访问的对象。

例如在评论区等功能，这里就可能会有其他用户的一些相关信息。

在访问其他用户评论时，发现返回的json数据明显多于当前页面需要显示的数据信息，比如还返回了邮箱和车辆ID等：

然后可以在页面中找找有没有接受车辆ID的API端点，尝试替换URL中的为其他车量ID访问，成功访问到了其他用户的车辆信息：

正常情况会返回403没有权限访问，但是这里返回200成功，就是一个典型的水平越权漏洞。

在黑盒渗透的时候我们没有代码，但我们可以尝试去猜测后端程序的大概模样，而不是像一个无头苍蝇一样到处乱碰~ 找出项目的源码参考，其实造成这个漏洞原因就在于，后端在处理这个请求时没有对传入的车辆ID和JWT身份认证进行一个关联性校验。

又例如，同在这个页面中查询用户的维修报告信息API端点，只需要修改report_id即可访问其他用户的报告。

失效的对象授权是针对认证后的API请求未进行鉴权，但是因为不同的业务逻辑需要鉴权的程度不同，对于这种通用接口如果只做了简单的入口式鉴权，而不做更加细粒度的鉴权，那么就等于没有鉴权。

1. 失效的用户身份认证

身份认证机制如果设计的不合理，或者被错误地实施，那么攻击者就可以破坏认证令牌或利用实现缺陷来暂时或永久地冒充其他用户的身份。

例如重置其他用户的密码，我们刚才在用户评论接口返回的信息中看到有邮箱，所以可以尝试在登陆页面尝试重置这个邮箱用户的密码：

分析重置密码的执行逻辑，点击后会针对登陆邮箱发送重置密码的OTP，之后抓包检查OTP的API端点，发现这个POST包并没有携带用于用户认证的Token：

那么可以尝试Burp爆破一下OTP码，但是很快就告诉已经超过了尝试次数：

然而RESTful API在设计的时候有一个特点，它会在URL中嵌入版本号，用来保持兼容性和方便调试等。这里请求端点URL中的“v3”就表示第三个版本，可以试试换成其他版本：

当换为“v2”版本时发现可以正常使用，并且没有尝试次数限制了。

可以看到并且两个接口的主要区别在于对无效OTP尝试次数的限制，/v2/check-otp接口没有限制，并且这个接口是并没有验证用户的身份和修改邮箱的一致性，所以可以通过在未授权的情况下，通过爆破修改用户密码。

所以在修改密码等场景时，如果服务器没有严格判断用户账号、手机号或邮箱、以及验证码是否关联一致，否则就很容易造成这类任意密码重置漏洞。

1. 失效的对象属性级授权

对于RESTful API的端点它们倾向于公开返回所有对象属性，OWASP这样描述，如果满足以下条件则API端点易受攻击：

• API端点公开被视为敏感且不应由用户读取的对象的属性。（以前名称为：“过度数据泄露”)

• API端点允许用户更改、添加和/或删除用户不应访问的敏感对象属性的值。（以前称为：“批量分配”)

就例如评论页面可以看到其他用户敏感信息，过度的数据暴露通常导致敏感数据的泄露：

过多的数据暴露可能会导致，攻击者可能利用这些数据进行欺诈、钓鱼、身份盗窃等攻击，还可以利用这些信息发现安全漏洞，从而进一步攻击。

关于“批量分配”（Mass Assignment）OWASP这样解释：

现代应用程序中的对象可能包含许多属性。其中一些属性应该可由客户端直接更新（例如，user.first_name、user.address），而另一些则不应该（例如，user.is_vip）。

如果一个应用程序接口端点会自动将客户端传入的参数转换为内部对象的属性，却不考虑这些属性的敏感性以及可暴露级别，那么该端点就是存在漏洞的。这可能会让攻击者得以更新他们本不应有权访问的对象属性。

而RESTful的核心思想就是，客户端发出的数据操作指令都是“动词+宾语”的结构，对应CRUD操作。例如在商店页面买一件商品，产生一个订单，那么可以只通过一个API端点就对这个订单进行增删改查等操作。

尝试修改请求方法为GET，并修改为刚产生的订单，分析订单的属性。

可以尝试修改订单数量，或订单状态这类的属性值。POST不行，试试PUT方法：

成功实现0元购。可以看到后端在处理PUT请求时并没有对这两个属性做很好的限制，自动绑定客户端输入的函数转换为代码变量或内部对象。后端应用程序应该定义可更新的属性列表，严格限制可以由客户端更新的属性。

1. 失效的功能级别授权

由于RESTful API更加结构化的设计，使得可以容易的预测访问API的方式（如将HTTP方法从GET替换为PUT），此类缺陷允许攻击者访问未授权的功能。

通过枚举HTTP方法，发现更改视频名字发现API端点，是可以使用DELETE从服务器删除资源的。

接口校验测试

测试对外的接口是否接口数据校验机制，安全的接口应该有白名单校验机制，对数据的数据合法性进行校验，确保不出现异常数据和注入攻击等。

没有对输入的数据进行校验或者校验不完善，通常是造成漏洞的直接原因，例如一些通用的SQL注入，XSS，CSRF，甚至RCE等。这里crAPI提供了一个NoSQL注入的场景，NoSQL注入攻击也利用应用程序对用户输入不进行充分验证和过滤的漏洞，直接向数据库系统发送恶意的查询语句。

想办法在不知道优惠券代码的情况下获得免费优惠券，找到验证优惠卷的接口：

找一些NoSQL注入的payload进行尝试：

这里对bsonMap传入的值并没有做校验，直接传入了查询条件。

还比如有一个SQL注入的场景，在获得这个优惠券以后，这里的coupon_code也可注入。

可盲注：

没有使用参数化查询，而是直接拼接进SQL语句中，这样是非常危险的。

还有一个SSRF的利用场景，就是查询车辆报告的接口，mechanic_api参数允许传递一个URL，这很明显可以试一试SSRF：

同样是因为没有对传入的参数做好校验。

接口滥用测试

一些查询相关信息的接口，如果未对接口进行查询次数控制，则会导致大量信息泄露。另一方面如果频繁频繁恶意进行接口调用查询（DOS攻击），就破坏系统的可用性，造成接口性能下降影响业务。

例如查询车辆报告的接口，请求失败重复功能，若请求失败后重复的次数为一个较大的数时，过大的请求数量就会造成一个DOS攻击。

检查接口是否有接口滥用限制，主要为接口查询频率、参数遍历查询等，分析接口未对访问频率是否会导致接口查询性能下降等。

总结

这里借助crAPI大概聊了聊比较常见的Web API的漏洞。通过OWASP也可以看出来，API的权限处理往往时重灾区，想要充分设计一个安全的接口，并不是一件容易的事。

对于权限的检查一定要贯穿整个接口调用流程。不能仅仅在接口入口处做个简单验证就了事，在后续每一个涉及到资源操作的环节，都要再次核对当前用户是否具备相应的权限，避免出现权限绕过的漏洞。再者，权限的更新和管理也得有完善的流程。当用户的角色发生变化或者权限需要调整时，确保权限始终与用户的实际情况相符。

接口是否接口数据校验机制也是一个老生常谈的问题，安全的接口应该尽可能的使用数据白名单校验机制。

除了这些，还有接口的可用性测试，是否能抗DoS攻击；对于外提供交易服务的接口进行交易时，是否防具备防重放措施；接口是否具备报文签名机制，确保报文数据在传输过程中不会被篡改；接口保密性测试，是否被加密或者通过VPN传输等。

参考文章：

https://www.explinks.com/wiki/restful-api-best-practices-01/#title-2

https://www.explinks.com/wiki/rest-api-security/#title-4

https://developer.aliyun.com/article/1297696

https://www.explinks.com/blog/top-7-rest-api-security-threats/

https://owasp.org/API-Security/editions/2023/en/0x11-t10/

---

若有错误，欢迎指正！o(￣▽￣)ブ