OAuth/OpenID Connect 渗透测试完整指南

news/2025/10/18 6:05:46/文章来源:https://www.cnblogs.com/qife122/p/19149121

Web应用渗透测试：OAuth/OpenID Connect测试案例

OAuth和/或OpenID Connect在现代Web或移动应用程序中常用。如果应用程序使用OAuth和/或OpenID Connect进行身份验证/授权，以下是在评估期间可以执行的可能的测试案例：

侦察阶段

检查应用程序使用的OAuth实现类型，例如隐式授权或令牌授权（response_type=token）、授权码授权（response_type=code）等
检查以下标准端点，这将让我们了解支持的或预期的范围等信息：
- /.well-known/oauth-authorization-server/
- /.well-known/openid-configuration

开放重定向测试

检查redirect_uri（OAuth流程中的强制参数）中是否存在开放重定向可能性，或参阅"测试不足的重定向URI验证"
参考此链接中发现的常见绕过方法

以下是来自OWASP WSTG的示例：

# client.evil.com是攻击者控制的回调域，目标是欺骗OAuth流程将授权码发送到攻击者域
https://as.example.com/authorize?client_id=example-client&redirect_uri=http%3A%2F%2Fclient.evil.com%2F&state=example&response_mode=fragment&response_type=code&scope=openid&nonce=example

授权码测试案例

（适用于公共客户端或单页应用SPA、移动应用程序）

在授权码授权（response_type=code / grant_type=authorization_code）中，多次重新发送代码（代码重放）
注意此代码的过期时间，理想情况下应该是短期的

其他涉及授权码的测试案例：

为另一个client_id发送有效代码
- 如果应用程序所有者提供了另一个client_id，或者测试人员能够在AS或OAuth提供者中注册另一个client_id，这是可能的
- 例如通过动态客户端注册
为另一个资源所有者发送有效代码
- 如果您有另一个测试用户或应用程序允许自注册，这是可能的
- 启动用户1的OAuth流程，在AS提供授权码的部分，在Burp/Zap中丢弃响应（因此代码不会被使用）
- 使用用户2执行另一个OAuth流程，然后将用户2获得的代码与用户1的代码交换
为另一个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"
}

如果响应返回访问令牌、刷新令牌等，将此报告为发现

其他关键测试

执行PKCE降级攻击测试
检查可能的SSRF
检查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

在同意页面测试点击劫持（CSP与frame-ancestors指令和/或X-Frame-Option在此处对缓解有用）
测试JWT的令牌生命周期（访问令牌、刷新令牌）
检查是否可以升级Scope。例如，如果初始Scope是scope=openid%20email，我们是否可以将其升级为scope=openid%20email%20profile？

OpenID Connect特定测试

在OpenID Connect中，检查配置是否支持动态客户端注册。参阅此链接中发现的通过OpenID动态客户端注册的SSRF Portswigger实验室

隐式流测试

如果使用隐式流，检查response_mode是否未设置为form_post
检查引用头中泄漏的凭据。"如果response_mode未设置为form_post，隐式流将授权令牌作为URL的一部分传输。这可能导致请求的令牌或代码在引用头、日志文件和代理中泄漏，因为这些参数在查询或片段中传递。" — OWASP WSTG

安全头检查

检查缺少的安全头（CSP（具有适当的指令）、HSTS、Referrer Policy、Permission Policy、X-Frame-Options、X-Content-Type-Options等）

端点安全测试

检查涉及OAuth流的端点是否容易受到CORS错误配置的影响（例如Access-Control-Allow-Origin: *，或者如果Origin接受任何任意域）
检查涉及OAuth流的端点是否使用未加密的网络连接

客户端测试

对暴露的客户端密钥执行测试
对不当令牌存储执行测试
对访问令牌注入执行测试，适用于客户端使用直接向客户端发出访问令牌的响应类型时（例如隐式授权类型）

缓解/修复/建议

始终验证所有参数是否存在，并验证它们的值（例如严格强制redirect_uri参数与确切的预期URI匹配）
使用PKCE扩展来正确保护授权码和令牌交换
不允许安全功能（如PKCE扩展）的回退
限制凭据的生命周期（短期的授权码、合理的访问令牌时间（根据用例5到15分钟）、长期有效的刷新令牌（理想情况下在使用后失效））
尽可能只使用凭据一次，例如授权码
配置可用的安全缓解措施，如CORS、反CSRF令牌（State参数）和反点击劫持头（具有frame-ancestors指令的CSP和/或X-Frame-Options）
仅当客户端有能力安全存储时才使用客户端密钥
遵循最佳实践安全存储令牌。将它们与其他凭据一样考虑安全考虑
避免已弃用的OAuth授权类型。参阅测试OAuth弱点以获取更多详细信息

参考资料

https://portswigger.net/web-security/oauth
https://portswigger.net/web-security/oauth/openid
https://www.cyberark.com/resources/threat-research-blog/how-secure-is-your-oauth-insights-from-100-websites
https://www.praetorian.com/blog/attacking-and-defending-oauth-2-0-part-1/
https://www.praetorian.com/blog/attacking-and-defending-oauth-2/
https://www.cobalt.io/blog/oauth-vulnerabilites
https://www.cobalt.io/blog/oauth-vulnerabilites-pt.-2
https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/05-Testing_for_OAuth_Weaknesses
https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/05.1-Testing_for_OAuth_Authorization_Server_Weaknesses
https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/05.2-Testing_for_OAuth_Client_Weaknesses
https://cheatsheetseries.owasp.org/cheatsheets/OAuth2_Cheat_Sheet.html