“开源 Web 应用安全项目”(OWASP)在 2019 年发布了API 十大安全风险 《OWASP API 安全 Top10》:失效的对象级别授权、失效的用户身份验证、过 度的数据暴露、资源缺乏和速率限制、失效的功能级授权、批量分配、安全配置 错误、注入、资产管理不当、日志和监视不足位列其中。
1. 失效的对象级别授权
失效的对象级别授权是指:用户与服务器使用API进行通信时,服务器端未进行对象级别的权限控制或限制不严格。攻击者可以通过修改请求数据中的对象ID 等信息,实现未授权获取或修改敏感信息。 eg: 越权访问到他人信息
2. 失效的用户身份验证
失效的用户身份验证是指:API在访问时未对请求方进行身份验证或身份验证存在问题导致易被破解,那么攻击者可以实现未授权对API进行操作。 eg:
- 未校验令牌的有效性;
- 更新密码接口未限制请求频率,旧密码参数可暴力破解
- 短信验证码或者邮箱验证码有效期超出10分钟或长度小于6位
3.过度的数据暴露
发生过度数据暴露的主要原因之一是,开发人员和编码人员对他们的应用程 序将使用的数据种类没有足够的洞察力。正因为如此,开发人员倾向于利用通用 流程,在这种流程中,所有的对象属性都暴露给最终用户。
防御措施:
- 不要依赖客户端来过滤敏感数据
- 检查 API 的响应,确认其中仅包含合法数据
- 停止用通用 API 向用户发送一切的过程也很重要。例如,必须避免
有信息直接执行 to_json()和 to_string(),然后发送给客户端。应该专门挑选需要返回给授权用户的属性,并专门发送这些信息 - 对于敏感数据应使用加密技术进行保护。这样,即使该数据的位置作为
过度数据暴露漏洞的一部分被泄露出去,也有一个良好的第二道防线,即使数 落入恶意用户或威胁行为者手中,也能保护数据。
4.资源缺乏和速率限制
当有太多的请求同时进来,而API没有足够的计算资源来处理这些请求时,就会出现这种漏洞。然后,API可能变得不可用或对新的请求没有反应。 对用户调用 API 的频率执行明确的时间窗口限制,定义并强制验证所有传入 参数和有效负荷的最大数据量,例如字符串的最大长度和数组中元素的最大数 量。在突破限制时通知客户,并提供限制数量及限制重置的时间。
5.失效的功能级授权
失效的功能级授权漏洞允许用户执行应该被限制的功能,或者让他们访问应 该被保护的资源。 所有业务层面的功能都必须使用基于角色的授权方法进行保护。一定 要在服务器上实现授权,不能试图从客户端保证功能的安全。在创建功能和资源 级别时,用户应该只被赋予做它们需要的事情的权限,实践最小权限的方法。
6.批量分配
后端应用对象可能包含许多属性,其中一些属性可以由客户端直接更新,而某些属性则不应该更新。 例如修改用户信息,传参中附加一项不可修改的属性,也被修改成功了。
如何防止:
- 如果可能,请避免使用将客户输入自动绑定到代码变量或内部对象中的函数;
- 仅将客户端可更新的属性列入白名单;
- 使用内置功能将客户端不应访问的属性列入黑名单;
- 如果可能,为输入数据有效负载准确、明显的定义和实施 schema 格式。
7.安全配置错误
安全配置错误可以发生在一个应用程序堆栈的任何层面,包括平台、Web服务器、应用服务器、数据库、框架和自定义代码。 案例: 比如攻击者在服务器的根目录下找到.bash_history 文件, 该文件包含DevOps 团队用于访问 API 的命令: $ curl -X GET ‘https://api.server/endpoint/’ -H ‘authorization: Basic Zm9vOmJhcg==’, 攻击者可由此命令获取权限认证信息(Zm9vOmJhcg== base64 解码:foo:bar)以 及接口信息。
8.注入
服务端未对客户端提供的数据进行验证、过滤或净化,数据直接使用或者拼接到 SQL/NoSQL/LDAP 查询语句、 OS 命令、XML 解释器和 ORM(对象关系映射器)/ODM(对象文档映射器)中,产生注入类攻击。 案例: 判断服务端是否支持 XML 解析,如果支持,可以尝试 XML 注入。 <?xml version="1.0" encoding="utf-8"?>
]> &entityex; API 未对来自外部系统(如,集成系统)的数据进行验证、过滤或净化。
9.资源管理不当
很有可能一些 API 会丢失、被遗忘或者未销毁,这就导致了如果资产管理不当会直接导致攻击者可以访问敏感数据,甚至可以通过旧的、未打补丁的 API 版本连接到同一数据库。 如何消除不当的资产管理缺陷:应该做到对所有的 API、他们的用途和版本进行严格的盘点。主要关注因素包括,部署到什么环境中,如生产或开发,谁应该对它们有网络访问权限、收集和处理哪些数据,是常规数据还是敏感数据、API的存活时间、当然还有它们的版本。一旦完成,需要实施一个流程,将文档添加到任何新创建的 API 或服务中。这应该包括 API 的所有方面,包括速率限制、如何请求和相应、资源共享、可以连接到哪些端点、以及它任何以后需要审计的内容,还需要避免在生产中使用非生产 API,考虑给 API 增加一个时间限制等。
10.日志和监视不足
如果没有日志和监视,或者日志和监视不足,就会导致无法及时发现攻击者的恶意活动,同时也就无法快速定位跟踪可疑活动并作出及时响应,给攻击者留有足够的时间来破坏系统。 建议:
- 应该有一个记录各种认证和授权事件的系统,比如登陆失败、暴力攻击、访问敏感数据等;
- 必须建立有效的监测和警报系统,此系统能够发现可疑活动并作出及时反应;
- 日志应保证有足够的详细信息记录攻击者的行为,识别恶意活动;
- 如果出现问题,必须通知相关团队。5.必须采用行业标准制定事故相应
和恢复计划。
|