引 言
2022年11月5日，中关村信息安全测评联盟提出并归口《网络安全保护测评高风险判定指引》，在最新一版的高风险判定中应用系统环境新增一项高风险判定：自2022年12月1日起，应用系统访问控制策略存在缺陷，可越权访问系统功能模块或查看、操作其他用户的数据等存在访问控制缺陷的场景将判定为高风险漏洞。本文基于此高风险漏洞，探究当前互联网环境下应用系统中API 端点易出现的安全问题。
01 API 是什么？
API 即英文 Application Programming Interface 首字母的缩写，直译过来就是应用程序之间的接口，狭义上来说是指一些其他人预先定义好的函数，目的是让开发人员在无需访问源码或理解内部工作机制细节的情况下调用这些函数完成两个应用之间的数据交互。
常见的API用途包括支持跨语言实施库和框架、通过协议操作远程资源， 以及定义第三方与使用期资产的应用程序之间进行交互经过的接口。从独立的移动开发和web开发人员大型企业和政府机构，API在各个行业和使用案例中的应用越来越广泛。
02 API 端点易出现的问题
OWASP 组织给出了现代 API 面临的十大安全问题，见如下链接：
https://owasp.org/www-project-api-security/
OWASP API Security Project项目自2019年以来已经三年未更新过，具体原因我们不得而知，但就杭州中尔网络科技的安全团队在渗透测试中发现的API 方面的漏洞来说，它仍然适用于当前的互联网环境。本文将重点关注前两名易于出现的漏洞：损坏的对象授权和损坏的用户认证，也即是《网络安全保护测评高风险判定指引》中新增的高风险场景：应用系统访问控制机制存在的缺陷。
损坏的对象授权 2.1
此处的对象是指什么？它是指一个应用系统中用来描述客观事物的实体。举个不恰当的例子，对象就是在外卖软件中代表你今天晚上的外卖的一串数字，比如下面以 json 形式表示的 foodid。
{'foodid':'1q2w3e4r5t','userid':'5555'}在现代的应用系统中，像上面这样的资源都会有至少一个 API 端点对他进行操作，比如：
获取价格：
GET /api/price/{foodid}付款：
POST /api/pay/{foodid}在不考虑到安全性的情况下，这样使用对象 id 是一种很好的软件设计实践，但也可能由此引入损坏的对象授权漏洞。
在用户权限体系不完善或服务端未对请求的数据和当前用户身份做校验 时，攻击者可能会通过遍历有规律的对象 id 获取其他用户的敏感信息，比如用户姓名、电话和身份证等，更严重的是应用程序把用户的明文身份信息也一并显示出来
/api/userid/001/api/userid/002/api/userid/003/api/userid/004
不仅是获取用户敏感信息方面，损坏的对象授权漏洞可能发生在业务的任何增删改查过程中，比如通过操作损坏的对象删除任意用户、篡改任意用户密码或以低权限用户越权访问高权限模块等，如下图例子所示：
GET /api/delete/{userid} #删除任意用户将普通用户提升为管理员。
通过损坏的对象篡改用户的电话和收货地址等。
POST /api/info/update............{"userid":"xxxxxx","phone":"{new_phone}", "address":"{new_address}"}
2.1.1 预防损坏的对象授权
此类漏洞主要出现在应用程序的业务逻辑线上，传统漏洞扫描工具难以排查，需要开发工程师、测试工程师和安全工程师从白盒和黑盒的角度全面的进行检查，主要预防方式可参考以下几点：
1 | 实施具有完善的用户权限策略和等级结构的授权机制。 |
2 | 使用授权机制检查每个来自客户端输入的访问是否有权操作数据库中的数据。 |
3 | 使用随机和不可预测的值作为 GUID 来代替简单可预测的 ID。 |
4 | 开发、测试人员应当在项目上线前编写测试对应用程序的授权机制进行评估。 |
5 | 通过人工渗透测试和代码审计的方式对漏洞进行检测。 |
2.1.2 检测损坏的对象授权
对于 API 端点中易出现的对象授权漏洞，下面是几点挖掘思路：
1 | 了解应用程序的业务逻辑： 在使用自动化工具进行测试前很有必要细心的浏览网站的功能，思考程序的业务逻辑，对应用程序进行简单建模，哪些地方易于出现特定的漏洞。 |
2 | 保持对 API 端点的敏感性： 每个 API 请求都是对资源和对象的调用，在看到 ID、userid、role 等参数时都应该判断它是否是当前登录用户的私有属性，是否可以被篡改为其他值。 |
3 | 了解用户角色和组： 注意观察用户的权限在数据包中的体现，比如 user 或 admin，思考是否可以通过替换来进行越权。 |
4 | 通过 fuzz 方法寻找更多端点： 通过 fuzz 目录的方法发现更多端点，比如 /api/image/upload ,/api/file/upload 。 |
损坏的身份认证 2.2
在网络安全中，身份验证是验证某人或某物身份的过程。身份验证通常通过检查密码、硬件令牌或其他可证明身份的信息来进行。就像航空公司工作人员在登机时检查护照或身份证以验证一个人的身份一样，计算机系统需要确保一个人确实是他们所说的那个人。在机场，此身份验证过程可确保只有持有机票的人才能登机；对于数字系统，这可以确保只有正确的人才能查看和使用数据。
如果应用系统使用了具有漏洞的身份认证和会话管理功能，攻击者就能够破译密码、密钥或会话令牌，或者利用其它开发缺陷来暂时性或永久性冒充其他用户的身份。比如攻击者会使用大量有效的用户名和密码组合，用于凭据填充、默认管理帐户列表以及自动暴力破解等攻击工具入侵应用系统，获取机密数据。
2.2.1 API可能受到的身份认证攻击
现代应用程序中通过 API 进行授权和认证的机制相较于业务系统来说是相当复杂的，尤其是在引入了第三方授权的情况下，此外，身份验证机制对所有人公开，很容易成为攻击者的目标。
常见的危害性较大的漏洞有，身份认证缺失导致的任意用户注册漏洞，前端泄露硬编码密钥，未授权访问漏洞，登录绕过，任意用户密码重置等漏洞， 比如：
1 | Influxdb 数据库使用 jwt 鉴权，但在服务端未设置参数 shared-secret 的情况下，jwt 的认证密钥为空字符串，此时攻击者可以伪造任意用户身份在Influxdb 中执行SQL语句。 |
2 | 锐捷RG-UAC统一上网行为管理审计系统账户硬编码漏洞，将账户密码经弱哈希加密后存放在前端代码中。 |
3 | harbor注册功能逻辑漏洞，可在注册时通过在 POST 数据包中添加 “"has_admin_role":true”将普通账户升级为管理员账户。 |
杭州中尔网络安全团队在各大攻防演练及渗透测试中发现，如下有关 API 认证的问题广泛存在于当前的互联网环境中，如果您的应用程序存在如下问题，那么可能存在身份认证漏洞：
1 | 允许攻击者对同一账户进行暴力破解攻击，无验证码或账户锁定机制进行防御。 |
2 | 使用弱密码。 |
3 | 使用明文或弱哈希密码传输身份验证信息。 |
4 | 使用弱加密密钥或默认密钥，攻击者可轻易破解认证令牌。 |
5 | 使用未签名、弱签名的 JWT 令牌，身份验证令牌在注销或一段时间不活动期间未正确失效。 |
6 | 存在逻辑缺陷漏洞可获取管理员密码或提升普通用户权限。 |
2.2.2 预防损坏的身份认证
1 | 确保所有的流程都通过规范的 API 进行身份验证。 |
2 | 使用标准的身份验证、令牌生成、密码存储项目代码，不要重复造轮子。 |
3 | 在找回密码和注册账号功能处实施和登录处一样严格的防暴力破解机制。 |
4 | 身份认证模块尽量实施多因素验证机制。 |
5 | 在尽可能的情况下实施多因素身份验证以防止凭证填充、暴力破解和被盗凭证重用攻击。 |
6 | 对密码长度、复杂性和轮换策略进行增强，对密码进行加密管理。 |
2.2.3检测损坏的身份认证
对于 API 端点中易出现的身份认证漏洞，下面是几点挖掘思路：
1 | 制作针对性的弱口令字典对密码进行暴力破解。 |
2 | 关注图片、短信验证码功能是否完善，是否可绕过。 |
3 | 深入理解各处功能逻辑及请求参数含义，猜测后端验证逻辑，手动验证是否存在漏洞。 |
4 | 增、删修改参数，比较回显的异同，寻找规律，确定逻辑是否可绕过。 |
5 | 手动和工具共用猜解口令和密钥，测试令牌是否存在规律性可被伪造。 |
结语
API 安全是 Web 应用程序安全的核心组件。大多数现代 Web 应用程序都依赖 API 来运行，而 API 允许外部各方访问它，从而给应用程序带来了额外的风险。就好像一家向公众开放办公室的企业：场所内有更多人，其中一些人可能不为企业员工所知，这会带来更大的风险。同样，API 允许外部人员使用程序，从而给 API 服务的基础设施带来更多风险。
未来，企业将面临诸多未知的 API 安全攻击，API 的安全建设将成为企业的重点工作。就下一步发展趋势来看，开发人员需要进一步加大对于 API 业务模型、分析能力、技术蓝图、以及合规性与标准化的深入研究与开发。而安全工程师也需要深入理解应用程序的业务逻辑，提升自己的技术能力，从不同的层面（包括应用层、网络层、系统层甚至物理层）对目标系统进行脆弱性分析，尝试找出尽可能多的漏洞、配置错误或其他安全风险，为企业提供“更安全”、“更私密”的安全保障。
本文简单介绍了 API 易出现的安全问题，下一篇将从黑盒和白盒角度深入分析 API 漏洞的挖掘和漏洞形成原理。
参考文章
1、https://blog.51cto.com/u_15641509/5329900
2、https://www.cloudflare.com/zh-cn/learning/access-management/what- is-authentication/
3、https://blog.csdn.net/weixin_43125873/article/details/119490732
4、https://github.com/OWASP/API- Security/blob/master/2019/en/src/0xa1-broken-object-level- authorization.md
5、https://github.com/OWASP/API-Security/blob/master/2019/en/src/0xa2-broken-user-authentication.md
6、https://inonst.medium.com/a-deep-dive-on-the-most-critical-api- vulnerability-bola-1342224ec3f2
7、https://owasp.org/www-project-api-security/
如有侵权请联系:admin#unsafe.sh