再说 API 安全:52个可被利用的弱点分析

admin 2025年1月12日21:29:16评论35 views字数 6035阅读20分7秒阅读模式

本文阅读大约需要30分钟;

在数字化转型的浪潮下,API 已成为现代应用程序的核心基石,但其安全风险亦随之攀升。防御者在构建安全体系时,往往囿于既有规则与惯性思维,容易忽略攻击者视角下的潜在威胁。本文将突破传统安全视角,以红队攻击专家的锐利眼光,深度剖析一份精心设计的API安全检查清单。我们不会在此讨论那些众所周知的安全原则,而是将重点放在52个可能被攻击者利用的薄弱环节上。我们将从渗透测试的实战角度出发,层层解剖API身份验证、授权机制、数据输入、处理逻辑、响应输出等各个环节,揭示防御措施的盲点。这不仅是一份安全加固清单,更是一次攻击者思维的模拟,旨在帮助安全从业人员从攻防对抗的实践中,深刻理解API安全漏洞的本质,并以此为鉴,构建更具韧性的安全体系。我们要做的,不仅仅是遵循最佳实践,更要预见攻击者的下一步行动,从而将风险扼杀于萌芽之中。本文并非仅仅是安全的总结,而是一次以攻促防,以变应变的专业探索。

API安全检查清单框架结构:

编号
检查域
攻/防视角
1
身份验证 (Authentication) 
入侵的起点
2
JWT安全(JSON Web Token) 
Token攻防
3
访问控制(Access)
收紧入口
4
授权 (Authorization)
精确授权
5
输入处理(Input) 
防守从输入开始
6
处理(Processing)
代码逻辑安全
7
输出(Processing)
安全响应
8
CI/CD (持续集成/持续交付)
安全贯穿开发流程
9
监控(Monitoring)
持续监视

一、红队视角剖析 (逐项解读)

现在我们带上红队的眼镜,逐条分析一下这份清单,看看这些条目背后隐藏的攻击面:

(一) 身份验证 (Authentication)

  • [ 1] 不要使用 Basic Auth,使用 JWT 等现代认证方法:

    通过抓包工具截获 Basic Auth 的 base64 加密字符串,即可轻易解密账号密码,进行身份伪造。Basic Auth 明文传输,容易被中间人抓包,获取用户名和密码。 使用JWT,可以减少认证信息的暴露,相对更加安全。

  • [ 2] 不要自己写“认证”,使用成熟的身份验证标准:

    自定义认证,容易出现认证绕过、密码存储不当、会话管理不当等问题,可以进行弱口令,认证绕过,来获取访问权限。缺乏安全经验的开发人员自己实现的身份认证,漏洞百出,形同虚设,红队可以轻易攻破,所以,使用安全框架才是安全的第一步。

  • [3 ] 使用最大重试次数限制,并加入账号锁定机制:

    登录时没有重试次数限制和锁定机制,相当于允许红队暴力破解账号。可以利用自动化脚本,对目标账号进行用户名,密码字典爆破。

  • [ 4] 所有敏感数据都必须加密:

    要时刻留意传输和存储过程中,数据是否进行加密。如果不是,将导致严重的数据泄露。(相当于白送)加密可以提高安全性,红队即使获取到数据库,也很难直接获取敏感信息。

(二) JWT (JSON Web Token)

  • [ 5] 使用足够复杂的随机密钥(JWT Secret):

    使用 hashcat 等密码破解工具破解弱密钥,从而修改JWT信息, 绕过签名校验。使用弱密钥或默认密钥, 会让暴力破解变得很简单,从而使 Token 签名无效。

  • [ 6] 不要从header提取算法,在后端强制使用 HS256 或 RS256:

    将算法修改为 "none" 或 "HS256",然后删除签名信息,就可以绕过校验机制, 从而获取控制权限。从 header 中提取算法会让红队可以篡改JWT的加密算法,从而伪造合法的Token。

    简单点说:“算法从客户端传来?分分钟就被篡改,把加密算法写死在后端,前端别管!”.

  • [7 ] 将 Token 过期时间设置尽可能短:

    一旦获取到有效的JWT,就可以长时间利用,并且在过期之前获取更多的信息。长时间有效的Token,让红队有更多机会利用泄露的Token。

  • [ 8] 不要在 JWT 的 Payload 里存放敏感数据,因为它很容易被解码:

    使用在线解码工具就可以读取 Payload 里的数据,获取用户名,密码等敏感数据。

    Payload 虽然进行了 Base64 编码,但并未加密,所有用户都能看到里面的数据,并且进行解码。

  • [9 ] 避免 JWT 承载过多的数据, 它的大小有限制:

    大部分 web server 对 HTTP Header 大小有限制,利用过大 JWT 可能导致 DoS 攻击。过多数据可能会影响请求的性能。

    简单点说: “头太长,客户端处理有问题,可能会有漏洞出现! 别放太多数据”

(三) 访问控制 (Access)

  • [10 ] 使用限流(Throttling)避免 DDoS/暴力破解:

    模拟高并发请求,对服务器发起拒绝服务攻击。没有限流, 红队可以用自动化工具进行大规模的爆破攻击或者拒绝服务攻击。

  • [11] 在服务端使用 HTTPS 和 TLS 1.2+ 加密,防止中间人攻击:

    利用 SSLstrip 工具降级HTTPS为HTTP,截取用户数据。明文传输的数据很容易被红队抓包获取信息, 因此必须要进行加密,才能保证数据安全。

  • [12] 使用 HSTS Header 配合 SSL 防止 SSL Stripping 攻击:

    利用 SSL 降级方法,获取用户信息。使用 HSTS,可以确保强制使用HTTPS协议,防止SSL降级攻击。

  • [13] 关闭目录列表:

    暴露目录列表可以直接看到敏感的文件信息。查看是否有配置文件,或者源码文件泄露,利用文件漏洞进行渗透。

  • [14] 对于内部 API,只允许受信任 IP/主机访问:

    限制内部API的访问来源,可以减少外部攻击。使用IP伪造绕过白名单,从而访问内网 API。

(四) 授权 (Authorization): OAuth

  • [15] 必须在服务端验证 redirect_uri,仅允许安全的 URLs:

    通过重定向链接实施钓鱼攻击。没有对 redirect_uri 做服务器校验,就可以把用户跳转到钓鱼网站,从而获取敏感信息。

    简单点说:“没有验证重定向,就能利用你的服务器当跳板,钓鱼劫持用户的认证信息!".

  • [16] 尽量使用 Code 交换 Token,不要直接允许 response_type=token:

    使用 Code  中间交换可以有效避免Token泄露, 更加安全。

    直接暴露 token,让攻击者更容易获取权限。

    简单点说:“授权凭证是需要被保护的,不直接使用token, 而是使用code来兑换token”。

  • [17] 使用 state 参数,配合随机hash来防止 CSRF:

     利用 CSRF 漏洞,实现未授权访问。

    没有 state 参数的验证,可以让红队伪造用户请求,实现CSRF攻击。

  • [18] 定义默认 scope,并且在每个应用中验证 scope 参数:

    修改 OAuth 请求,访问超出自己权限范围之外的数据。

    没有定义合适的 scope 或者没用校验,会导致越权,让攻击者访问其权限范围之外的数据。

     简单点说:“越权访问就能得到更多权限!定义scope, 可以防止非授权访问”。

(五) 输入 (Input)

  • [19] 依据操作类型,使用正确的 HTTP 方法:

    可以尝试使用 GET 方法,发起修改用户信息的请求。

    如果没有按类型区分,会存在意料之外的操作行为。

  • [20] 校验请求 Accept header 中的content-type, 并返回406 (Not Acceptable) 如果类型不匹配:

    • 可以使用错误的 content-type 格式请求,并利用此漏洞进行攻击。

    • 没有强制请求头的规范,容易被客户端篡改数据。

  • [21]  验证请求体中的 content-type 头部,并校验请求数据, 返回 406 响应 如果不匹配:

    如果不严格进行数据类型校验,可能导致请求处理出错。

    • 尝试发送非标准的或者错误的content-type数据格式进行攻击。

  • [22]  校验用户输入,防止 XSS, SQL-注入, RCE:

    • 校验不足的用户输入,会导致各类注入攻击的产生。

    • 使用特殊字符构造恶意数据包,进行XSS,SQL注入等攻击。

  • [23]  不要在 URL 中使用任何敏感数据, 例如 credentials, Passwords, security tokens or API keys,而使用标准的 Authorization header:

    URL 信息暴露会引发数据泄露,并且被记录在访问日志中,非常不安全。

    • 分析访问历史记录,利用 URL 里的参数信息进行渗透。

  • [24]  仅仅使用服务端加密:

    • 可以绕过客户端的加密,从而获取到用户信息,并重放请求。

    •  客户端的加密很容易被破解。

  • [25]  使用 API 网关服务,实现缓存, 限流等功能:

    • 缺乏 API 网关的保护,会直接暴露API接口。

    • 利用流量洪泛,对API直接发起DDos攻击。

(六) 处理 (Processing)

  • [26]  确保所有接口都有身份验证保护:

    • 尝试绕过认证机制,直接调用内部接口。

    • 确保所有API请求都受到保护,避免未授权的访问。

  • [27] 避免暴露用户内部 ID,使用 /me/orders 来替代 /user/654321/orders:

    • 使用枚举攻击获取敏感用户信息。

    • 内部ID 可以被预测,会暴露敏感信息,从而造成数据泄露风险。

  • [28]  使用 UUID 来代替自增 ID:

    • 使用自动脚本枚举自增ID,来批量获取用户信息。

    • 自增ID 容易被破解和预测, 从而导致信息泄漏。

  • [29] 解析 XML 数据的时候,禁用外部实体解析,从而避免 XXE:

    XXE 会让红队读取本地敏感文件或者发起 SSRF 攻击。利用XXE漏洞来读取本地配置文件,或发起 SSRF 攻击获取内网信息。

  • [30] 如果解析 XML 或 YAML,禁用实体扩展, 防止 Billion Laughs/XML bomb 攻击:

    无限的实体扩展会导致拒绝服务攻击。利用嵌套的实体解析,构造拒绝服务攻击。

  • [31] 使用 CDN 上传文件:

    • 利用直接上传文件到应用服务器,可以绕过一些安全限制。上传恶意代码,从而实现代码执行,并控制服务器。

  • [32] 如果你需要处理大数据, 使用后台任务和队列处理:

    •  通过发送大量请求,让服务器产生长时间的阻塞。

    • 前台大量的数据处理容易引发阻塞,导致应用服务崩溃。

  • [33] 关闭调试 (DEBUG) 模式:

    • 利用 DEBUG模式泄露的敏感信息进行更深入的攻击。

    • 开启DEBUG模式会泄漏内部信息,从而为红队渗透提供帮助。

  • [34] 使用非可执行堆栈 (Non-executable stacks):

    • 利用缓冲区溢出,在堆栈上执行shellcode进行攻击。

    • 恶意利用可执行堆栈进行攻击

(七) 输出 (Output)

  • [35]  使用 X-Content-Type-Options: nosniff 头:

    如果不设置该字段,浏览器可能基于内容进行MIME嗅探,从而导致安全风险。

    • 利用 MIME 类型解析漏洞,进行跨站脚本攻击(XSS)

  • [36] 设置  X-Frame-Options: deny  头:

    可以防御点击劫持漏洞。

    •  将目标网站嵌入恶意 frame 框架,欺骗用户点击敏感元素。

  • [37] 设置  Content-Security-Policy: default-src 'none'  头:

    • 可以严格控制资源的加载来源,减少XSS风险。利用跨站脚本漏洞执行恶意脚本代码,窃取 Cookie或者其他用户信息。

  • [38] 移除指纹信息头:例如 X-Powered-By,  Server,  X-AspNet-Version 等等。

    移除这些 header ,可以隐藏服务器的版本和类型, 防止针对特定漏洞的利用。分析 Header 的信息, 寻找对应版本的安全漏洞进行渗透。

  • [39] 强制返回正确的 content-type, 例如返回application/json, Content-Type 也必须为 application/json:

    • 使用错误 content-type 的值,来实施XSS攻击。

    • 可以减少XSS发生的风险,减少误解析引起的bug。

  • [40] 不要返回敏感信息: 例如 credentials, passwords 或者 security tokens:

    • 获取API 返回的信息,从而直接获取API 密钥,或者用户密码。

    • 敏感信息返回在响应包,可能会造成严重的信息泄露。

  • [41] 根据请求完成的操作,返回正确的状态码,例如 200 OK400 Bad Request,  401 Unauthorized,  405 Method Not Allowed:

    • 错误的响应码可能会隐藏API本身存在的错误。分析 API 的返回代码,探测逻辑缺陷漏洞。

(八) CI & CD

  • [42] 使用单元测试和集成测试来审计设计和实现:

    • 没有单元测试,则无法发现细微的bug和安全隐患。

    • 分析代码的不足,利用代码逻辑漏洞,发起攻击。

  • [43] 使用代码审查流程,并禁止代码自合并:

    • 没有代码审查,会导致带有漏洞的代码,直接发布到线上。

    • 伪造代码,或者植入恶意代码,利用信任漏洞,攻击后端系统。

  • [44] 确保所有组件和服务都经过安全扫描(AV), 确保依赖库也没有安全漏洞:

    • 识别存在漏洞的第三方库,利用已知漏洞进行攻击。

    • 存在漏洞的第三方库,容易导致供应链攻击。

  • [45] 持续运行安全测试(静态/动态分析):

    • 静态和动态分析可以提前暴露代码中的安全漏洞。 动态分析难以覆盖所有安全漏洞, 需要使用手动测试补充,并定期修复安全问题。

  • [46]  检查你的依赖 ( 软件和操作系统),是否有已知漏洞:

    • 过期和具有漏洞的操作系统和依赖,容易导致漏洞利用。收集软件依赖,分析是否有已知的安全漏洞。

  • [47]  制定版本回滚策略:

    • 利用新的错误版本,进行拒绝服务攻击。

    • 如果新版本出现问题,则没有回滚能力, 可能会导致线上服务出现问题。

(九) 监控 (Monitoring)

  • [48]  使用中心化的登录系统,进行访问控制:

    • 如果有权限控制漏洞,则利用越权访问,获取信息和系统控制权限。

    • 分散的登录会让红队有机可乘, 如果使用相同的账号密码体系,就会让红队横向渗透更加容易。

  • [49]  使用 agents 监控所有的流量,请求, 响应和错误信息:

    •  注入恶意数据到监控日志,误导安全人员。

    • 可以帮助安全人员理解系统运行情况,方便排错, 但也可能会存在安全问题。

  • [50] 使用SMS, Slack, Email, Telegram, Kibana 等渠道获取报警信息:

    实时的报警可以提醒安全人员,及时处理攻击,避免损失。可以使用钓鱼手段欺骗安全人员。

  • [51]  避免记录敏感数据, 例如信用卡号,密码, 个人身份号码 等:

    日志中出现敏感信息是非常危险的,会被攻击者利用进行后续攻击。

    • 使用正则表达式搜索敏感日志信息, 利用信息进行渗透测试。

  • [52]  使用 IDS 或者 IPS 来监控 API 请求和实例:

    使用入侵检测或者防护系统,能有效防御网络攻击,和恶意流量。测试 IDS 和 IPS 的策略, 利用混淆的方式绕过检测规则。

总结:

这份 API 安全检查清单并非最终真理,随着技术的发展和攻击手法的更新,我们还需要不断学习,才能建立坚固的防御体系。 如果大家有其他问题或者新的见解,欢迎随时分享!

API渗透测试线上免费靶机实战练习可参考本公众号文章:

30天渗透测试练习计划(2025 第一部分)

30天渗透测试练习计划(2024 第一部分)

如果您觉得文章对您有所帮助,请您点赞+关注!
迎您加群讨论:安全技术交流、威胁情报分享讨论群!
再说 API 安全:52个可被利用的弱点分析

原文始发于微信公众号(再说安全):再说 API 安全:52个可被利用的弱点分析

免责声明:文章中涉及的程序(方法)可能带有攻击性,仅供安全研究与教学之用,读者将其信息做其他用途,由读者承担全部法律及连带责任,本站不承担任何法律及连带责任;如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截,联系方式见首页),望知悉。
  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2025年1月12日21:29:16
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   再说 API 安全:52个可被利用的弱点分析https://cn-sec.com/archives/3621029.html
                  免责声明:文章中涉及的程序(方法)可能带有攻击性,仅供安全研究与教学之用,读者将其信息做其他用途,由读者承担全部法律及连带责任,本站不承担任何法律及连带责任;如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截,联系方式见首页),望知悉.

发表评论

匿名网友 填写信息