Content-Disposition头场景下CSRF下载数据外带绕过CORB方案咨询

不存在无用户交互的通用技术方案，可以把该场景下自动下载的文件内容走私到攻击者服务器，现有浏览器安全机制已经完全封堵了对应的利用路径，具体分析如下：

核心安全限制说明 #

• 针对iframe嵌入触发下载的场景：只要响应携带Content-Disposition: attachment头，浏览器触发下载的流程完全脱离当前恶意页面的JS上下文——页面只能触发浏览器跳转到目标URL启动下载，根本拿不到下载过程中的任何响应字节，下载的文件会直接存入用户本地的下载目录，网页沙箱里的JS没有权限访问本地文件系统的对应路径，自然读不到文件内容。
• 针对fetch/XHR类脚本请求场景：你提到的CORB拦截是硬限制，CORB做MIME判定时不会因为响应头的顺序出现逻辑绕过：只要响应最终的Content-Type被识别为application/json，跨源场景下渲染进程根本拿不到响应体，哪怕你手动修改请求的mode配置也没用，JSON属于CORB强制拦截的高风险类型，没有放通可能。
• 不要尝试靠window.open、跨源窗口引用之类的方式读内容：下载触发时新窗口/iframe会直接关闭导航到下载流程，你挂再多事件监听也拿不到响应数据。

无通用价值的极端边界场景 #

以下场景仅存在理论可能，不具备通用攻击的可行性：

• 极老旧的未更新浏览器（如2018年以前的Chrome、legacy Edge版本）存在MIME嗅探缺陷，可能因为响应头顺序错误把JSON响应判定为可直接渲染的文本，这种情况下可以直接在iframe里渲染内容读取，但这类浏览器目前全球市场占比不足0.1%，几乎碰不到存在这类缺陷的用户环境。
• 如果用户主动将下载完成的文件拖拽到恶意页面、或者手动通过文件选择器上传该文件，确实可以拿到内容，但这属于需要用户明确交互的场景，不属于无感知的CSRF数据走私范畴。
• 如果用户设备已经安装了拥有本地文件读取、下载管理权限的恶意浏览器扩展，那本身客户端已经失陷，和当前接口的响应头配置缺陷没有关系。

内容的提问来源于stack exchange，提问作者patrick jason