CSP（Content Security Policy，内容安全策略），是浏览器层面为了防御XSS（跨站脚本攻击）而生的终极安全机制。

你可以把它理解成网站给浏览器装的一道「安全防盗门」：

• 正常的CSP，会给浏览器列一份「白名单」：只允许加载/执行白名单里的可信资源（比如自己服务器的JS、可信CDN的样式）。

• 不在白名单里的资源、内联脚本、恶意代码，浏览器会直接拦截，从根源上阻断XSS攻击。

而我们遇到的所有问题，本质都是：亲手给这道防盗门开了无数个大洞，让CSP彻底形同虚设。

二、CSP高危漏洞全拆解

1. 漏洞1：CSP中允许内联脚本执行（高危）

漏洞名称

CSP中允许内联脚本执行

漏洞原因

在script-src指令中配置了'unsafe-inline'，强制浏览器放行所有内联脚本（包括直接写在HTML里的<script>代码、onclick等内联事件）。

• 正常CSP默认禁止所有内联脚本，只有手动添加'unsafe-inline'才会放行。

• 这个配置等于告诉浏览器：“不管是我自己写的正常JS，还是黑客注入的恶意内联脚本，全给我放行”，直接废掉了CSP的核心防护。

风险后果

黑客只要能在网站任何输入点（评论区、个人资料、URL参数）注入一段恶意内联脚本，就能直接在用户浏览器执行，偷取Cookie、盗号、弹钓鱼广告，XSS攻击零门槛。

解决方案

• 将所有内联脚本、内联事件提取到独立的.js外部文件，彻底删除'unsafe-inline'。

• 必须保留内联脚本的场景：使用nonce（随机数）或hash（脚本哈希）白名单，仅放行可信内联脚本，不全局开放。

2. 漏洞2：在CSP中的不安全URL方案（高危）

漏洞名称

CSP中使用不安全URL方案（data:/blob:）

漏洞原因

在script-src等指令中配置了data:和blob:协议，允许浏览器加载/执行用这两个协议打包的资源。

• data:/blob:是特殊的打包协议，可以把JS、图片等资源直接编码嵌在URL里，不用单独存成文件。

• 开放data:/blob:给脚本，等于给黑客开了“把恶意代码藏在特殊链接里进门”的大门，CSP完全无法拦截。

风险后果

• 黑客可以把恶意JS转成base64，用data:text/javascript;base64,xxx的形式注入，浏览器直接执行，结合'unsafe-inline'形成双重漏洞叠加，XSS攻击成功率拉满。

解决方案：

• 直接从script-src中删除data:和blob:，仅给图片（img-src）等非脚本资源按需放行。

• 必须使用的场景：严格限制仅放行特定类型（如仅图片），绝对不允许脚本类型的data:/blob:。

3. 漏洞3：在源指令中过度使用宽泛的通配符（高危）

漏洞名称

CSP源指令过度使用*通配符

漏洞原因

在script-src、base-uri、form-action等指令中使用了*通配符，代表“允许任意来源的所有资源”。

• 正常CSP应该只放行可信域名（如'self'、可信CDN域名），*通配符等于完全放弃白名单能力。

• 这个配置等于告诉浏览器：“不管脚本来自哪个网站，是合法的还是黑客的，全给我放行”。

风险后果

黑客可以从任何恶意网站、广告链接引入恶意JS，网站毫无阻拦地执行，彻底失去来源管控能力，XSS、数据泄露风险极高。

解决方案

• 彻底删除所有*通配符，替换为具体可信域名，如script-src 'self' https://trusted.cdn.com。

• 核心原则：脚本（script-src）绝对禁止使用*通配符，仅在必要的非脚本资源中谨慎使用。

4. 漏洞4：绕过对象白名单配置（高危）

漏洞名称漏洞名称

CSP对象源白名单绕过（object-src全放行）

漏洞原因

• object-src指令配置为* data: blob:，无限制放行所有插件/嵌入式对象。

• object-src是CSP中专门管控Flash、<object>/<embed>等插件资源的指令，现代网站几乎不再使用这类插件。

• 全放行配置等于完全不限制插件来源，黑客可以注入恶意Flash/嵌入式对象，直接在用户浏览器执行。

风险后果

黑客可以通过恶意插件执行任意代码，绕过CSP的脚本防护，实现提权、数据窃取等攻击，属于额外的攻击入口。

解决方案

• 最优方案：直接配置object-src 'none'，完全禁用所有插件/嵌入式对象，现代网站99%场景适用，对业务零影响。

• 必须使用插件的场景：仅放行可信域名，绝对禁止*、data:、blob:。

5. 漏洞5：在CSP中使用了不安全的eval()（中危）

漏洞名称

CSP中允许'unsafe-eval'

漏洞原因

在script-src指令中配置了'unsafe-eval'，允许浏览器执行eval()、new Function()等动态代码。

• 正常CSP默认禁止eval()执行，手动添加'unsafe-eval'才会放行。

• 这个配置等于给黑客开了“动态代码执行”的绿灯，黑客可以用eval()解密、变形恶意代码，绕过WAF和前端防护。

风险后果

放大XSS攻击威力，让黑客可以用更隐蔽的方式注入恶意代码，即使有基础防护也能轻易绕过。

解决方案

• 直接删除'unsafe-eval'，重构代码，用静态代码替代eval()等动态执行逻辑（如用JSON.parse()替代eval()解析JSON）。

• 必须使用的场景：严格限制使用范围，不全局开放'unsafe-eval'。

6. 低危补充：在CSP中未强制执行脚本中的可信类型

漏洞名称

CSP未开启可信类型（Trusted Types）

漏洞原因

未配置require-trusted-types-for 'script'指令，未开启CSP的进阶DOM XSS防护。

• 可信类型是CSP的扩展防护，强制浏览器只允许执行经过验证的可信脚本，拦截危险的DOM操作（如innerHTML）。

• 未配置该指令，等于没装“第二道锁”，DOM XSS风险依然存在。

风险后果

属于锦上添花的防护缺失，优先级低于上述5个高危漏洞，不影响核心安全，但会降低XSS防护能力。

解决方案

• 在CSP中添加require-trusted-types-for 'script'; trusted-types default;，开启可信类型防护。

• 前端无法适配的场景：可标记为低危不整改，不影响等保/密评合规。

三、所有CSP漏洞的本质总结

很多人会觉得这是5个独立的问题，但实际上，它们的本质完全一致：

我们配置的CSP，不是在“防护”，而是在主动告诉浏览器：
不管什么JS、谁发来的、哪里来的、用什么方式包装的，全都允许执行。

等于给网站装了防盗门，却亲手把锁拆了、门大开，还贴了纸条：“黑客请随意进”。

这5个配置同时存在，CSP的XSS防护等于彻底报废，没有任何防御能力，黑客可以从任何地方、用任何方法把恶意代码塞进来，浏览器全执行，没有任何阻拦。

四、最终修复：一份可直接复制的安全CSP模板

把所有高危配置一次性替换，给你一份零风险的标准CSP配置：

Content-Security-Policy:
  # 默认只允许自家域名的资源
  default-src 'self';
  # 脚本只允许自家服务器，彻底删除unsafe-inline、unsafe-eval、data:、blob:、*
  script-src 'self';
  # 样式允许自家和inline（样式inline通常可保留，脚本inline必须删）
  style-src 'self' 'unsafe-inline';
  # 图片允许自家和data:（仅图片，脚本绝对不加）
  img-src 'self' data:;
  # 字体只允许自家
  font-src 'self';
  # 接口请求只允许自家
  connect-src 'self';
  # 媒体资源只允许自家
  media-src 'self';
  # 直接禁用所有插件，彻底堵死object-src漏洞
  object-src 'none';
  # 禁止篡改页面基础URL
  base-uri 'self';
  # 表单只能提交到自家域名
  form-action 'self';
  # iframe只允许自家
  frame-src 'self';
  # Worker脚本只允许自家
  worker-src 'self';
  # 子资源只允许自家
  child-src 'self';
  # 开启可信类型进阶防护（可选，前端适配后添加）
  # require-trusted-types-for 'script'; trusted-types default;

核心配置原则

1. 脚本（script-src）绝对红线：禁止'unsafe-inline'、'unsafe-eval'、data:、blob:、*通配符，只放行可信域名。

2. 非脚本资源按需放行：仅给图片、字体等非脚本资源，按需放行data:，绝不给脚本开放。

3. 插件彻底禁用：object-src 'none'，现代网站完全用不到，零业务影响，彻底堵死漏洞。

4. 通配符零容忍：所有指令彻底删除*，只配置具体可信域名。

五、修复后验证

1. 浏览器控制台验证：打开F12控制台，查看是否有CSP相关报错，确保业务功能正常。

2. 安全扫描验证：重新执行安全扫描，确认所有CSP相关告警已消除。

3. CSP校验工具验证：使用CSP Evaluator等工具，验证CSP策略的安全性。

4. 等保/密评合规验证：确认配置符合等保2.0、密评的安全要求，无高危配置。

六、写在最后

CSP是防御XSS的最后一道防线，而我们遇到的这些问题，本质都是“主动放弃了这道防线”。

很多时候，开发为了兼容业务、快速解决CSP拦截报错，会随手加上'unsafe-inline'、*、data:这些“万能钥匙”，却忽略了这些配置带来的致命安全风险。

CSP的核心是「限制」，不是「放行」。

**这个时间这么短，使用这个系统时间戳输出作为结果到底合不合理？这个时间又这么长，通过秒表的方式符合测试的要求么？

往往出现这种情况时总会想：这几种情况有没有一个标准来解答这种情况呢？这种困惑在纳秒级、毫秒级、秒级、分钟、小时、天或者周等不同时间量级的测试中尤为突出，盲目的选择计时方式，轻则导致结果误差过大，重则影响性能瓶颈分析与解决方案的决策。从而梳理了在不同时间量级下的最优计时方案，为以后的测试中提供一个合适的参考。

一、毫秒级（ms）及以上

适用场景

接口响应时间、业务流程总耗时、单机任务执行时长、分布式压测场景下的请求耗时等。

耗时范围1ms~10ms时，是日常性能测试中最常见的场景，这个时候可以选择系统时间戳、专业性能测试工具（JMeter/LoadRunner/Locust）。

二、秒级（s）及以上

耗时范围1s-60s时，这个时候除了可以选择系统时间戳、专业性能测试工具（JMeter/LoadRunner/Locust），还可以选择人工秒表计时或者工业级的计时工具。

三、纳秒-微秒级（ns-μs）：硬件级高精度，杜绝误差

适用场景

函数级指令耗时、硬件IO延迟、芯片级处理时延、短周期算法核心逻辑耗时等，耗时范围＜1ms（μs/ns级），对精度要求极致。

这个时候就要考虑使用CPU TSC（时间戳计数器）、示波器。

四、几十分钟至数小时长以上

适用场景

完整算法执行、大规模数据处理、超算/DCU/FPGA平台全流程测试、系统稳定性压测等，耗时范围≥30min，核心关注总耗时与稳定性。

这个时候就可以考虑使用手机秒表、工业级硬件秒表（支持外部触发、抗干扰强）``人工电子秒表

五、总结

作为测试工程师，面对不同时间量级的性能测试，“选对计时工具”是保证结果可信的第一步。

• 毫秒级及以上任务，系统时间戳、专业压测工具、手机秒表均可灵活选用，精度足够且适配性强；
• 纳秒级任务必须依赖CPU TSC、示波器等硬件级高精度方案，杜绝普通系统时间戳的误差问题；
• 几十分钟至数小时的长周期任务，人工/手机/工业秒表是最合理、最可靠的选择。

单台windows最大tcp端口是65535个（默认1024个），客户端每发一次请求就会占据一个端口，如果超出这个数量或者说tcp端口释放比较的慢，就会出现被占用的错误。

JMeter默认是使用短链接方式（关闭 Keep-Alive）进行请求的，windows中端口默认释放时间是120s，即使这个请求结束后，如果还没到达端口释放的时间，这个端口会一直被占用状态。

如何避免？

1、多机负载

使用两台或更多的机器进行负载测试；

2、虚拟机

原理和多机负责其实是一个，只不过如果只有一台电脑，那这个时候我们就可以考虑开虚拟机的方式进行，当然要保证你的机器配置足够，否则即使用负载的方式进行也会因为资源不够导致结果不准确或者报错超时。

3、开启Keep-Alive

打开Jmeter中的Keep-Alive后，可以让请求保持长链接的状态，而不是请求完就断开。

4、修改Time_wait、最大连接数

windows默认连接数1024个，这里将windows默认的tcp释放时间缩短，将tcp默认链接数量设置最大，在windows的regedit注册表中修改即可

cmd输入regedit进入到负载机的注册表，找到HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters路径：

在Parmeters右键新建DWORD值，命名为MaxUserPort，然后选择十进制并输入数据65534后保存

在同样的注册表位置新建TcpTimeWaitDelay，值类型DWORD，数值数据为5s(时间可以更短)

确定后重启测试机即可。

在linux中，权限用户分为三组，分别是所有者用户，所属组用户、其他用户；
权限功能分为读（read）简写r，写（write）简写w，可执行（execute）简写x；还有-，表示无任何权限
这三种用户权限是有各自的权重的，分别为 4 2 1 0

一、基础权限：3 位数字（用户 / 组 / 其他）

例如：
以 755（rwx r-x r-x） 为例，三位数字分别对应：
第一位 7：文件所有者的权限（r+w+x，4+2+1=7）
第二位 5：所属组用户的权限（r+x，4+1=5）
第三位 5：其他用户的权限（r+x，4+1=5）

755全部组合起来一起的权限就是：所有者用户可读可写可执行，所属组用户可读可执行，但不能写；其他用户可读可执行不能写；

二、基础权限组合：0-7 的数字含义

每类对象（u/g/o）的权限是上述 3 个基础权限的数字和，范围为 0-7，具体组合如下：

三、完整权限表示：3 位数字组合（u-g-o）

总结

基础权限：3 位数字，对应u-g-o的r(4)、w(2)、x(1)组合，范围000-777。
权限对文件和目录的含义不同，核心区别在于x（文件是执行，目录是进入）和w（文件是修改内容，目录是增删文件）。
通过chmod命令可设置权限（如chmod 755 file），ls -l可查看权限字符（如-rwxr-xr-x）。

流程图：

结构图：

示例：从百度查询‘测试信息’。



开始执行1次后，能否看到结果树中返回了对应的响应信息，包括响应正常、响应异常的部分（绿色正常、红色异常）

如果想对此api进行一定时间的测试，只需要修改持续时间即可，如设置持续时间为300秒；300后自动停止

聚合报告中能看到请求了多少次、响应时间等信息

正常逻辑下，当用户找回密码时会将找回地址发送到对应的邮箱中，然后通过邮件中的找回地址重新设置，

实际上发现邮箱并没有收到邮件，而是将找回信息直接暴露在网页上，可以直接通过上面的找回地址重置用户名的密码，按照此方式只要知道网站的已知用户邮箱就可以做到重置其他用户的密码了。


漏洞已反馈至网站负责人

发现第一次未勾选Use Multipart/from-data传参是按照url格式进行的，而勾选Use Multipart/from-data后发现传参是一段一段的，而且其中还带有其他参数，查了下二者含义，区别如下：

1、数据编码方式

不使用 multipart/form-data：

数据通常以 URL 编码（application/x-www-form-urlencoded）的形式发送。
这种编码方式适用于纯文本数据，比如登录表单中的用户名和密码。
数据会被转换成键值对的形式，如 key1=value1&key2=value2。

使用 multipart/form-data：

数据被编码为多个部分（每个部分代表一个字段），每个部分之间由边界符分隔。
这种编码方式支持上传文件和其他二进制数据。
每个部分可以包含不同的内容类型，如文本、图片、视频等。

2. 适用场景

不使用 multipart/form-data：

适用于简单的表单提交，其中所有数据都是文本形式。
不适合上传文件或其他二进制数据。

使用 multipart/form-data：

适用于需要上传文件的场景，比如文件上传功能。
也适用于需要发送复杂数据结构的情况，如包含文件和文本信息的表单。

关于边界符、格式：
（边界分隔符作用主要是为了区分不同部分的特殊字符串，起到分隔作用）
--boundary_string
Content-Disposition: form-data; name="description"

这是文件描述
--boundary_string
Content-Disposition: form-data; name="file"; filename="example.txt"
Content-Type: text/plain

... 文件内容 ...
--boundary_string--

总结起来就是，当抓包请求时发现请求格式带有以上边界形式的数据时，在JMeter中记得把Use Multipart/from-data勾选就可以了。