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
重定向URI测试
- 检查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、引用策略、权限策略、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
免责声明
本博客提供的信息仅供一般信息目的。虽然我总是力求准确,但某些细节可能不准确,提供的列表可能不完整。话虽如此,我强烈建议在做出任何决定或采取行动之前,根据行业标准文件和官方来源(上面参考部分列出了一些)验证任何关键信息。
此处表达的所有观点均为我个人观点,不代表我雇主的观点或立场。
"此列表是一个进行中的工作 🚧"
更多精彩内容 请关注我的个人公众号 公众号(办公AI智能小助手)
对网络安全、黑客技术感兴趣的朋友可以关注我的安全公众号(网络安全技术点滴分享)
公众号二维码
公众号二维码