Magento2站点遭恶意注入：CSP拦截后代码仍生效，仅Windows受影响

核心逻辑误区 #

你混淆了CSP的管控范围：CSP拦截的是外部资源加载行为，但攻击者使用的new Function(atob(XXX))()是内联动态代码执行逻辑，两者属于CSP规则的不同管控维度，这是你最先忽略的核心点。

具体遗漏的关键细节 #

• CSP规则的权限边界：CSP的script-src白名单仅限制从外部URL加载的脚本，对new Function、eval这类内联执行的动态代码，只有当CSP明确禁用unsafe-eval时才会拦截。Adobe Commerce 2.4.x默认CSP配置为兼容KnockoutJS等核心组件，通常会保留'unsafe-eval'权限，直接给这类恶意代码开了执行口子。
• Windows环境的特殊触发条件：
  • 攻击者可能利用Windows系统的字符编码差异，atob(XXX)解码后的代码在Windows下可解析为有效执行逻辑，其他系统解码结果无效，导致仅Windows设备触发恶意行为；
  • Windows设备上的第三方工具（如杀毒软件、浏览器扩展、系统代理）可能存在绕过CSP的逻辑，或提前执行了解码后的代码，不受浏览器CSP拦截限制；
  • 若服务器为Windows环境，Adobe Commerce的静态资源编译、缓存机制可能存在平台差异，导致恶意代码被嵌入页面内联脚本，而非通过外部资源加载。
• SQL注入的实际影响形式：你推测的SQL注入，大概率是攻击者将new Function(atob(XXX))()直接写入数据库（如CMS页面、产品描述等可渲染字段），属于存储型XSS。这种情况下代码是页面渲染时直接输出的内联内容，完全不涉及外部资源加载，CSP的资源白名单规则根本无法管控。
• CSP配置的细节漏洞：检查你的CSP规则，是否存在script-src 'unsafe-inline'、data:等允许内联执行的配置，或CSP仅设置为警告模式（而非强制拦截），这也会导致恶意代码正常执行。

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