支持本站 — 捐款将帮助我们持续运营

目标:1000 元,已筹:752

75.2%
一、 漏洞 CVE-2025-64484 基础信息
漏洞信息
                                        # OAuth2-Proxy 头部伪装漏洞

N/A
                                        
神龙判断

是否为 Web 类漏洞: 未知

判断理由:

N/A
提示
尽管我们采用了先进的大模型技术,但其输出仍可能包含不准确或过时的信息。
神龙会尽力确保数据准确,但也请结合实际情况进行甄别与判断。
神龙祝您一切顺利!
漏洞标题
OAuth2-Proxy vulnerable to header smuggling via underscore, leading to potential privilege escalation
来源:美国国家漏洞数据库 NVD
漏洞描述信息
OAuth2-Proxy is an open-source tool that can act as either a standalone reverse proxy or a middleware component integrated into existing reverse proxy or load balancer setups. In versions prior to 7.13.0, all deployments of OAuth2 Proxy in front of applications that normalize underscores to dashes in HTTP headers (e.g., WSGI-based frameworks such as Django, Flask, FastAPI, and PHP applications). Authenticated users can inject underscore variants of X-Forwarded-* headers that bypass the proxy’s filtering logic, potentially escalating privileges in the upstream app. OAuth2 Proxy authentication/authorization itself is not compromised. The problem has been patched with v7.13.0. By default all specified headers will now be normalized, meaning that both capitalization and the use of underscores (_) versus dashes (-) will be ignored when matching headers to be stripped. For example, both `X-Forwarded-For` and `X_Forwarded-for` will now be treated as equivalent and stripped away. For those who have a rational that requires keeping a similar looking header and not stripping it, the maintainers introduced a new configuration field for Headers managed through the AlphaConfig called `InsecureSkipHeaderNormalization`. As a workaround, ensure filtering and processing logic in upstream services don't treat underscores and hyphens in Headers the same way.
来源:美国国家漏洞数据库 NVD
CVSS信息
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N
来源:美国国家漏洞数据库 NVD
漏洞类别
对HTTP头部进行脚本语法转义处理不恰当
来源:美国国家漏洞数据库 NVD
漏洞标题
OAuth2-Proxy 安全漏洞
来源:中国国家信息安全漏洞库 CNNVD
漏洞描述信息
oauth2-proxy是OAuth2 Proxy开源的一个反向代理软件。 OAuth2-Proxy 7.13.0之前版本存在安全漏洞,该漏洞源于HTTP标头处理不当,可能导致权限提升。
来源:中国国家信息安全漏洞库 CNNVD
CVSS信息
N/A
来源:中国国家信息安全漏洞库 CNNVD
漏洞类别
其他
来源:中国国家信息安全漏洞库 CNNVD
二、漏洞 CVE-2025-64484 的公开POC
#POC 描述源链接神龙链接
1CVE-2025-64484https://github.com/B1ack4sh/Blackash-CVE-2025-64484POC详情
2CVE-2025-64484https://github.com/Ashwesker/Blackash-CVE-2025-64484POC详情
3CVE-2025-64484https://github.com/Ashwesker/Ashwesker-CVE-2025-64484POC详情
三、漏洞 CVE-2025-64484 的情报信息
  • 标题: RFC 822 - STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES -- 🔗来源链接

    标签:x_refsource_MISC

    神龙速读:
                                            该链接的内容为空,无法处理。
                                            
    RFC 822 - STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES
  • https://datatracker.ietf.org/doc/html/rfc2616#section-4.2x_refsource_MISC
  • 标题: Header smuggling via underscore leading to potential privilege escalation · Advisory · oauth2-proxy/oauth2-proxy · GitHub -- 🔗来源链接

    标签:x_refsource_CONFIRM

    神龙速读:
                                            ### 关键信息摘要
    
    - **漏洞标题**: Header smuggling via underscore leading to potential privilege escalation
    - **严重性**: High
    - **CVE ID**: CVE-2025-64484
    - **受影响版本**: <=7.12.0
    - **修复版本**: 7.13.0
    - **漏洞描述**: 
      - **影响**: 
        - OAuth2 Proxy部署在将下划线规范化为破折号的HTTP标题中的应用之前(例如,基于WSGI的框架,如Django、Flask、FastAPI和PHP应用)。
        - 认证用户可以通过注入下划线变体的X-Forwarded-*头部旁路代理的过滤逻辑,导致上游应用中的特权升级。OAuth2 Proxy自身的验证/授权并未被攻破。
      - **补丁**: 
        - 此更改缓解了一个Header Smuggling漏洞,攻击者可以通过使用不同的大写或替换下划线旁路标题剥离请求头。
        - 默认所有指定的头部将被规范化,这意味着大写和下划线和破折号在匹配要移除的头时将被忽略。例如,X-Forwarded-For和X_Forwarded-for将被视为等效并被移除。
        - 但是,如果你有合理的理由需要保留类似的标题并且不想移除它,我们引入了一个新的配置字段,用于通过AlphaConfig管理的头部,称为InsecureSkipHeaderNormalization。
    - **绕过**: 
      - 确保上游服务中的过滤和处理逻辑不以相同方式对待下划线和连字符。
    - **参考资料**:
      - https://github.security.telekom.com/2020/05/smuggling-http-headers-through-reverse-proxies.html
      - https://www.uptimia.com/questions/why-are-http-headers-with-underscores-dropped-by-nginx
      - https://datatracker.ietf.org/doc/html/rfc2616#section-4.2
      - https://datatracker.ietf.org/doc/html/rfc822#section-3.2
                                            
    Header smuggling via underscore leading to potential privilege escalation · Advisory · oauth2-proxy/oauth2-proxy · GitHub
  • 标题: Why Are HTTP Headers With Underscores Dropped By Nginx? -- 🔗来源链接

    标签:x_refsource_MISC

    神龙速读:
                                            From the screenshot, the following key information about the vulnerability can be extracted:
    
    - **Problem**: Nginx, by default, drops HTTP headers with underscores.
    - **Reason**: This behavior is related to the CGI legacy and header mapping.
    - **Impact**: It can cause issues in web applications using custom headers with underscores or third-party services.
    - **Solution**: To handle underscore headers in Nginx, add the "underscores_in_headers on;" directive to the server, http, or location block in the Nginx configuration.
                                            
    Why Are HTTP Headers With Underscores Dropped By Nginx?
  • 标题: Smuggling HTTP headers through reverse proxies -- 🔗来源链接

    标签:x_refsource_MISC

    神龙速读:
                                            ### 关键信息总结
    
    - **漏洞类型**: Smuggling HTTP Headers Through Reverse Proxies
    - **影响范围**: 由于HTTP头部规范化和解析器差异导致的漏洞,尤其是在使用mTLS验证中用于传递认证数据的场景。
    - **漏洞原理**:
      - **Apache与认证绕过**: 当Apache作为反向代理服务器时,其默认的规范化和转发机制可能导致认证头部被转发并被应用层识别,即使这些头部在Apache层面被unset。
      - **-headers撞库**: 在某些框架(如Flask、Django)中,由于反向代理传递的headers未被删除干净,可能导致认证信息混迭。
    - **影响组件**:
      - **Web应用语言**: PHP、Python (如Django、Flask)、其他WSGI应用等。
      - **应用服务器与服务端**: Apache、Nginx、Gunicorn等。
    - **缓解措施**:
      - 始终在Apache配置的根Level unset认证相关的头部。
      - 不使用Adrain、Hyphen字符去构建敏感头字段,避免规范化导致的风险。
      - 考虑关注头字段的转发路径及可能的转化规则,在搭建中间件时要特别关注并剔除可能产生混淆的头字段。
    
    ### 说明
    
    该漏洞涉及到多种web前端与后端的技术点,在实际业务的搭建中,防护的措施与技术实现需要前后端有良好的配合及规范,防止发现不一致的解析行为。
                                            
    Smuggling HTTP headers through reverse proxies
  • https://nvd.nist.gov/vuln/detail/CVE-2025-64484
四、漏洞 CVE-2025-64484 的评论

暂无评论


发表评论