本文阅读大约需要30分钟;
在数字化转型的浪潮下,API 已成为现代应用程序的核心基石,但其安全风险亦随之攀升。防御者在构建安全体系时,往往囿于既有规则与惯性思维,容易忽略攻击者视角下的潜在威胁。本文将突破传统安全视角,以红队攻击专家的锐利眼光,深度剖析一份精心设计的API安全检查清单。我们不会在此讨论那些众所周知的安全原则,而是将重点放在52个可能被攻击者利用的薄弱环节上。我们将从渗透测试的实战角度出发,层层解剖API身份验证、授权机制、数据输入、处理逻辑、响应输出等各个环节,揭示防御措施的盲点。这不仅是一份安全加固清单,更是一次攻击者思维的模拟,旨在帮助安全从业人员从攻防对抗的实践中,深刻理解API安全漏洞的本质,并以此为鉴,构建更具韧性的安全体系。我们要做的,不仅仅是遵循最佳实践,更要预见攻击者的下一步行动,从而将风险扼杀于萌芽之中。本文并非仅仅是安全的总结,而是一次以攻促防,以变应变的专业探索。
API安全检查清单框架结构:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
一、红队视角剖析 (逐项解读)
现在我们带上红队的眼镜,逐条分析一下这份清单,看看这些条目背后隐藏的攻击面:
(一) 身份验证 (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 OK, 400 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渗透测试线上免费靶机实战练习可参考本公众号文章:
原文始发于微信公众号(再说安全):再说 API 安全:52个可被利用的弱点分析
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论