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