浏览器能否安全获取用户提供的外部URL的JSON资源？风险及缓解方案有哪些？

核心结论 #

在无法确认外部URL可信度的前提下，绝对不能直接在浏览器前端执行这类未做防护的跨域资源抓取逻辑，会引入多项高风险安全漏洞。

存在的主要安全漏洞 #

• SSRF（服务端请求伪造）衍生风险：如果攻击者传入的resource参数指向内网服务地址（比如http://127.0.0.1:内部端口/内部接口、企业私有服务域名），浏览器会直接发起对应的请求。若内网服务没有配置严格的跨域限制，你前端拿到返回的内网敏感数据后，只要后续存在页面渲染、日志上报等逻辑，就会导致内网数据泄露。
• XSS（跨站脚本攻击）风险：即使你期望外部返回的是JSON格式，恶意攻击者完全可以构造返回内容为携带恶意脚本的非法内容。如果你的后续逻辑存在直接把返回内容插入DOM、用eval类方法动态解析、或者做不安全的内容拼接渲染操作，就会触发跨站脚本攻击，进而窃取用户登录凭据、伪造用户操作。
• CORS配置滥用风险：为了让前端能正常拿到跨域返回的JSON，你大概率需要放开服务端的CORS限制，这会让你的站点暴露在更多跨域攻击风险下，恶意资源站点甚至可以利用不合理的CORS配置窃取用户在你站点的登录状态。
• 恶意流量转发风险：攻击者可以利用你的站点作为跳板，对第三方站点发起请求攻击，比如传入DDoS目标站点的资源地址，访问该链接的用户都会被动参与对目标站点的攻击，你的站点域名也会被第三方安全策略标记为恶意来源。

可行的缓解方案 #

• 用服务端代理中转所有外部请求，禁止前端直接发起外部资源请求：所有外部资源的抓取都由你的后端服务执行，前端仅和你自己的后端接口交互。后端需要做严格的校验规则：
  • 禁止请求内网IP段、私有域名、本地回环地址，提前拦截所有指向内部网络的请求
  • 限制仅允许HTTP/HTTPS协议，屏蔽file、ftp、gopher等所有危险协议
  • 校验返回内容的Content-Type必须为JSON格式，同时限制返回内容的大小阈值，避免恶意大文件占满服务资源
  • 对恶意请求来源做频率限制、黑名单拦截
• 严格校验返回内容结构：拿到JSON数据后做严格的 schema 校验，仅提取你业务需要的指定字段，禁止直接把未知结构的完整返回内容渲染到页面、或者执行任何动态解析逻辑。
• 使用隔离上下文渲染内容：如果确实需要把外部资源内容在前端渲染，用单独的沙箱iframe加载，配置iframe的sandbox属性禁用脚本执行、禁用跨域访问，完全和主站的运行上下文隔离。

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