web服务器解析差异是真实攻击面，取决于配置、后缀、mime类型等而非代码合法性；apache的.htaccess可绕过解析限制，nginx与apache双后缀处理逻辑不同，iis6存在分号和目录解析漏洞，html文件在ssi或特定cms中亦可执行。
不同 Web 服务器对同一 HTML（或类 HTML）文件的解析行为不一致，是真实存在的攻击面，不是理论风险。关键在于：你上传的文件是否被当作 HTML 渲染、执行，取决于服务器配置、后缀名、MIME 类型、目录结构，甚至请求路径中的符号——而不是你写的代码本身是否“合法”。
Apache 的 .htaccess 文件执行与解析绕过
当目标用的是 Apache，且 AllowOverride All 生效时，.htaccess 不仅能上传，还能被当作可执行配置生效。
- 上传一个内容为
AddType application/x-httpd-php .jpg的.htaccess文件，后续上传的shell.jpg就可能被解析为 PHP - 若服务器禁用了
AllowOverride或关闭了FileInfo指令，该方法直接失效——别硬试 -
.htaccess必须放在目标可访问的 Web 目录下，且不能被FilesMatch或Location规则显式禁止读取 - 注意：部分 WAF 会拦截含
AddType或SetHandler的.htaccess内容，可尝试大小写变形（如addtype）或空格/制表符混淆
Nginx 与 Apache 对双后缀的处理差异
双后缀如 shell.php.jpg 在 Nginx 和 Apache 下表现完全不同，本质是解析器对“哪个后缀起效”的判定逻辑不同。
- Apache 默认按从右到左顺序匹配后缀，
.jpg无 handler → 回退到.php→ 若已注册 PHP handler，则执行 - Nginx 默认只认最后一个后缀（
.jpg），除非显式配置了location ~ \.php$+fastcgi_split_path_info，否则不进 PHP-FPM - 常见误判：看到 Apache 能解析
.php.jpg，就以为 Nginx 也行——实际大概率 404 或直接下载 - 绕过技巧：Nginx 下可尝试
shell.jpg/.php（路径遍历式）或利用fastcgi_index index.php配合空字节（%00）截断，但需 PHP 版本 ≤ 5.3.4 且magic_quotes_gpc=off
IIS6.0 的分号解析与目录解析漏洞
IIS6.0 是解析差异最典型的靶子，但必须确认版本——IIS7+ 已默认修复，盲目测试只会暴露自己。
- 目录解析：
/upload/xxx.asp/1.jpg→ IIS6 认为这是xxx.asp目录下的文件，于是把1.jpg当作 ASP 脚本执行 - 分号解析：
shell.asp;.jpg→ 分号后内容被忽略，等价于上传shell.asp - 注意：IIS6 默认可执行扩展名不止
.asp，还有.asa、.cer、.cdx，这些常被黑名单遗漏 - 现实限制：现代云主机几乎不再部署裸 IIS6，但内网老旧系统、政企历史平台仍大量存在，探测前先用
OPTIONS或SERVER响应头确认版本
HTML 文件本身被服务端动态解析的隐蔽路径
很多测试者只盯着 PHP/JSP/ASP，却忽略 HTML 文件在特定条件下也能“活过来”。
- 若服务器启用了 SSI（Server Side Includes），上传含
<!--#exec cmd="id"-->的test.shtml可能命令执行 - 某些 CMS（如早期 WordPress 插件）允许通过
?page=template加载本地 HTML 文件，并启用 PHP 解析（include()+eval()组合） - Node.js 应用若用
res.sendFile()返回用户可控路径，且未校验扩展名，/static/../routes/admin.js可能泄露源码；更危险的是配合模板引擎（如 EJS）的，传入恶意 HTML 路径可触发服务端渲染执行 - 重点：这类漏洞不依赖“上传后缀”，而依赖“服务端如何加载并解释你提供的路径或内容”，所以必须结合源码审计或目录枚举（如扫描
/backup/、/templates/）定位可利用点
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
