当前位置：首页 > news >正文

OAuth/OpenID Connect 安全评估实战：一份完整的测试用例清单

news 2026/3/26 18:39:22

信息收集

作为测试的一部分，首先需要确认应用使用了哪种OAuth实现方式，例如：

隐式授权（Implicit grant）或令牌授权（Token grant），特征为response_type=token
授权码授权（Authorization Code grant），特征为response_type=code

检查以下标准端点，这有助于我们了解应用支持或预期的范围（scopes）等信息：

/.well-known/oauth-authorization-server/
/.well-known/openid-configuration

关键测试用例

1. 重定向URI验证

检查是否存在开放重定向（Open Redirect）漏洞，即测试重定向URI验证不足的情况。参考常见的绕过手法。

示例 (来自 OWASP WSTG):
攻击者控制的回调域为client.evil.com，目标是诱使OAuth流程将授权码发送到攻击者的域名。

https://as.example.com/authorize?client_id=example-client&redirect_uri=http%3A%2F%client.evil.com%2F&state=example&response_mode=fragment&response_type=code&scope=openid&nonce=example

2. 授权码测试

授权码重用：在授权码授权流程中，尝试多次发送同一个授权码（Code Replay）。同时，注意验证授权码的有效期，理想情况下它应该是短期的。
跨客户端使用授权码：尝试将一个有效的授权码用于另一个client_id。
- 前提：应用所有者提供了其他client_id，或者测试人员能够通过动态客户端注册等方式在授权服务器上注册新的client_id。
跨用户使用授权码：尝试将一个有效授权码用于另一个资源所有者。
- 前提：拥有另一个测试用户账号，或者应用允许自行注册。
- 操作步骤：启动用户1的OAuth流程，在授权服务器提供授权码的环节，拦截响应（使该授权码不被使用）。然后使用用户2启动另一个OAuth流程，并用之前拦截到的用户1的授权码替换用户2的授权码。
跨重定向URI使用授权码：尝试将一个有效的授权码用于另一个redirect_uri。

示例 (来自 OWASP WSTG):

POST /oauth/token HTTP/1.1 Host: as.example.com [...] {"client_id":"example-client","code":"INJECT_CODE_HERE","grant_type":"authorization_code","redirect_uri":"https://client.example.com"}

重放此请求，如果响应返回了访问令牌（Access Tokens）、刷新令牌（Refresh Token）等，请将其作为安全发现提交。

3. PKCE降级攻击

测试是否存在PKCE降级攻击的可能。

4. SSRF漏洞

检查OAuth流程中是否存在服务端请求伪造（SSRF）漏洞。

5. State参数与CSRF

检查state参数是否存在。如果不存在，可能存在跨站请求伪造（CSRF）风险。
如果state参数存在，检查其是否被验证以及是否足够随机。OAuth流程中的CSRF测试通常在“用户授权页面”进行。

示例 (来自 OWASP WSTG):

POST /u/consent?state=Tampered_State HTTP/1.1 Host: as.example.com [...] state=MODIFY_OR_OMIT_THIS&audience=https%3A%2F%2Fas.example.com%2Fuserinfo&scope%5B%5D=profile&scope%5B%5D=email&action=accept

6. 点击劫持

测试授权页面是否存在点击劫持风险。CSP的frame-ancestors指令和/或X-Frame-Options标头是有效的缓解措施。

7. 令牌生命周期

测试JWT令牌（如访问令牌、刷新令牌）的生命周期是否设置合理。

8. 权限提升

检查是否可以升级授权范围。例如，如果初始scope=openid%20email，能否将其升级为scope=openid%20email%20profile？

9. 动态客户端注册

在OpenID Connect中，检查配置是否支持动态客户端注册。这可能引入SSRF等风险。

10. 隐式流程信息泄露

如果使用隐式流程，检查response_mode是否未设置为form_post。若未设置，令牌可能因作为URL的一部分而泄露。

“如果response_mode未设置为form_post，隐式流程会将授权令牌作为URL的一部分传输。这可能导致请求的令牌或代码通过Referrer头、日志文件和代理服务器泄露，因为这些参数是通过查询字符串或片段标识符传递的。” — OWASP WSTG

11. 安全头缺失

检查OAuth流程涉及的端点是否缺失必要的安全头，如：CSP（需配置恰当的指令）、HSTS、Referrer Policy、Permission Policy、X-Frame-Options、X-Content-Type-Options等。

12. CORS配置错误

检查OAuth流程涉及的端点是否存在CORS配置错误，例如设置了Access-Control-Allow-Origin: *，或者允许任意域名的Origin。

13. 未加密网络连接

检查OAuth流程涉及的端点是否使用了未加密的网络连接。

14. 客户端安全

客户端密钥泄露：测试是否存在客户端密钥泄露的风险。
令牌存储不当：测试令牌是否在客户端被安全存储。

15. 访问令牌注入

适用于客户端直接接收访问令牌的响应类型（如隐式授权类型）。测试是否存在访问令牌注入的风险。

修复与加固建议

始终验证所有参数是否存在，并严格校验其值（例如，强制redirect_uri参数必须与预期的URI完全一致）。
使用PKCE扩展来正确保护授权码和令牌交换过程。
不允许对PKCE扩展等安全特性进行降级或回退。
限制凭证的生命周期（授权码应是短期的；访问令牌根据使用场景设定在5到15分钟；刷新令牌最好是长期但使用一次后即失效）。
尽可能确保凭证（如授权码）仅能使用一次。
配置可用的安全缓解措施，例如针对CORS的配置、反CSRF令牌（即state参数）和反点击劫持头（如CSP的frame-ancestors指令和/或X-Frame-Options）。
仅在客户端能够安全存储客户端密钥时才使用它。
遵循行业最佳实践来安全存储令牌，并将其视为与其他凭证同等重要的敏感信息。
避免使用已弃用的OAuth授权类型。更多细节请参考 OAuth 弱点测试。FINISHED
CSD0tFqvECLokhw9aBeRqtTv15RNmaHdiNZPviuVo91Rx7oQAt7mixCYQUykH/Zk8zv9xuEArnfCcgKoAjV8/Dh0HhRf1uPVxoJ1qROJDXbkqNcc3mEX5hJXMPylYq0JwE1YD3gaoczG9TJ17S5S0w==
更多精彩内容请关注我的个人公众号公众号（办公AI智能小助手）
对网络安全、黑客技术感兴趣的朋友可以关注我的安全公众号（网络安全技术点滴分享）