自建WordPress伪静态Windows避坑指南速查手册

找建站公司报价三千五，改个伪静态规则还要加钱？别被割韭菜了。

这份WordPress伪静态Windows速查手册，是你自己搞定的底气。

威胁场景：当URL变成攻击者的入口

很多运营同事觉得，Windows服务器上的WordPress，只要装好IIS，伪静态规则配好，链接变短了，SEO分数高了，万事大吉。

现实很骨感。在Windows环境下，IIS对URL的处理逻辑和Linux下的Nginx或Apache完全不同。如果你照搬Linux的.htaccess规则，或者直接使用网上那些未经验证的IIS web.config片段，极大概率会留下安全后门。

我见过太多案例。一家做外贸的企业，网站上了SEO，流量不错。结果某天后台被植入恶意脚本，服务器CPU跑满，IP被墙。检查发现，是因为伪静态规则配置错误，导致静态资源路径被错误解析为PHP执行路径。攻击者上传了一个名为index.php的图片，利用IIS的解析漏洞，直接执行了代码。

这就是典型的“配置即漏洞”。在Windows + IIS + WordPress的组合中，伪静态不仅是SEO工具，更是安全边界。

核心风险点：

• 路径遍历漏洞： 错误的重写规则可能允许用户访问/../../wp-config.php等敏感文件。
• 任意文件执行： 如果规则未严格限制文件扩展名，上传的图片可能被当作PHP执行。
• 信息泄露： 调试信息或源码在特定URL下暴露。

别以为这是小概率事件。根据MDN Web Docs关于URL规范的定义，浏览器和服务器对URL的解析存在差异，攻击者往往利用这种“解析差”来绕过WAF和服务器防护。

漏洞原理：IIS重写引擎的“陷阱”

要防坑，先懂原理。Windows下的WordPress伪静态，依赖IIS的URL Rewrite Module。

很多人喜欢直接复制这段“万能”配置：

<rewrite><rules><rule name="WordPress" patternSyntax="Wildcard"><match url="*" /><conditions><add input="{Request_FILENAME}" pattern="^/index\.php$" /><add input="{Request_FILENAME}" pattern="^/wp-admin" /></conditions><action type="R" url="/index.php?{R:1}" /></rule></rules>
</rewrite>

这是错的，也是危险的。

为什么？

1. 条件逻辑反了： patternSyntax="Wildcard" 下的条件判断，{Request_FILENAME} 指向的是物理文件路径。如果请求的是/about/，物理路径是/about/index.html或空，但规则没有正确排除静态文件。
2. 缺乏安全过滤： 这段代码没有检查请求的文件是否存在。如果请求/hack.php，而该文件不存在，IIS可能会将其重写为index.php?hack.php，如果WordPress没有正确过滤未定义参数，或者插件存在漏洞，就可能出问题。
3. 未处理特殊字符： Windows文件系统对大小写不敏感，但对URL编码敏感。攻击者可以使用%2e%2e/（../）进行路径遍历。

正确的安全逻辑应该是：

1. 如果请求的是已存在的文件（如/wp-login.php、/style.css），直接返回该文件，绝不经过index.php。
2. 如果请求的是已存在的目录（如/images/），直接返回目录索引或403，绝不经过index.php。
3. 只有当请求的文件和目录都不存在时，才将其传递给WordPress核心处理。

这就是“白名单”思维。先放行安全的，剩下的再交给核心引擎，而不是“先扔给核心，让核心去猜”。

防护方案：代码对比与安全配置

下面是针对Windows IIS的安全版伪静态配置。请将其保存为web.config，放在WordPress根目录。

不安全配置（常见错误）：

<!-- 危险：未检查文件存在性，可能导致路径遍历或执行漏洞 -->
<rewrite><rules><rule name="UnsafeWP" patternSyntax="Wildcard"><match url="*" /><action type="R" url="/index.php?{R:1}" /></rule></rules>
</rewrite>

安全配置（推荐）：

<configuration><system.webServer><rewrite><rules><!-- 规则1：如果请求的是已存在的文件，直接终止，不重写 --><rule name="ExistingFiles" stopProcessing="true"><match url="(.*)" ignoreCase="false" /><conditions logicalGrouping="MatchAll"><add input="{REQUEST_FILENAME}" matchType="IsFile" ignoreCase="false" /></conditions><action type="None" /></rule><!-- 规则2：如果请求的是已存在的目录，直接终止，不重写 --><rule name="ExistingDirectories" stopProcessing="true"><match url="(.*)" ignoreCase="false" /><conditions logicalGrouping="MatchAll"><add input="{REQUEST_FILENAME}" matchType="IsDirectory" ignoreCase="false" /></conditions><action type="None" /></rule><!-- 规则3：排除wp-admin、wp-includes等敏感路径，防止直接访问底层文件 --><rule name="ExcludeSensitive" stopProcessing="true"><match url="^wp-(admin|includes)/.*$" /><action type="AbortRequest" /></rule><!-- 规则4：将所有其他请求重写为index.php --><rule name="MainWP" stopProcessing="true"><match url=".*" /><conditions><add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" /><add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" /></conditions><action type="Rewrite" url="index.php" /></rule></rules></rewrite><!-- 安全加固：禁止目录浏览 --><directoryBrowse enabled="false" /><!-- 安全加固：禁止访问敏感文件 --><security><requestFiltering><fileExtensions allowUnlisted="false"><add fileExtension=".php" allowed="true" /><add fileExtension=".css" allowed="true" /><add fileExtension=".js" allowed="true" /><add fileExtension=".jpg" allowed="true" /><add fileExtension=".png" allowed="true" /><add fileExtension=".webp" allowed="true" /><add fileExtension=".svg" allowed="true" /><add fileExtension=".ico" allowed="true" /><!-- 根据实际需要添加其他允许的文件类型 --></fileExtensions></requestFiltering></security></system.webServer>
</configuration>

关键点解析：

1. stopProcessing="true"： 确保一旦匹配到前面的安全规则，后续规则不再执行。这是防止规则冲突的关键。
2. negate="true"： 在MainWP规则中，条件设置为“不是文件”且“不是目录”。只有同时满足这两个条件，才执行重写。这确保了所有真实存在的静态资源都被直接服务，不会经过PHP引擎。
3. AbortRequest： 对wp-admin和wp-includes下的深层路径进行拦截，防止直接访问wp-includes/js/jquery/jquery.js等文件时，被错误地解析为PHP执行（虽然现代IIS版本已较少出现此类问题，但防御性编程是必须的）。
4. requestFiltering： 明确指定允许的文件扩展名。任何未列出的扩展名（如.asp、.exe、.config）都会被IIS直接拒绝，从源头上杜绝了“上传webshell”的可能性。

部署步骤：

1. 备份原有的web.config。
2. 用记事本或VS Code打开WordPress根目录下的web.config。
3. 替换为上述安全配置。
4. 保存后，在IIS管理器中重启应用程序池。
5. 测试：访问/wp-login.php，应正常加载；访问/style.css，应正常加载；访问/non-existent-page/，应返回404或重定向到首页，而不是报错。

检测与修复：如何验证你的配置是否安全

配置完成后，不能只靠“看起来没问题”。必须进行主动测试。

1. 路径遍历测试

尝试访问以下URL，确保返回404或403，而不是文件内容：

• /../../wp-config.php
• /..%2f..%2fwp-config.php
• /wp-includes/../wp-config.php

如果返回了DB_HOST等敏感信息，说明配置失败，立即回滚并检查web.config中的negate条件。

2. 任意文件执行测试

在wp-content/uploads/目录下，手动创建一个文件test.php，内容如下：

<?php echo "Hacked"; ?>

然后访问/wp-content/uploads/test.php。

• 安全状态： 应返回404或403，或者IIS直接拒绝执行。
• 危险状态： 如果页面显示“Hacked”，说明IIS正在执行该PHP文件，你的配置存在严重漏洞。此时必须检查requestFiltering部分，确保.php扩展名仅在特定目录下允许执行，或者更严格地，禁止在uploads目录下执行任何PHP脚本。

修复方案： 如果测试失败，在web.config的<location>标签中，针对wp-content/uploads目录单独配置，禁止PHP执行：

<location path="wp-content/uploads"><system.webServer><handlers><remove name="PHP" /><remove name="php" /><remove name="PHP-7.4" /><!-- 根据你安装的PHP版本名称移除 --></handlers></system.webServer>
</location>

3. 信息泄露测试

访问/wp-json/，检查是否暴露了过多的插件和用户信息。虽然这不是伪静态直接导致的，但良好的IIS配置应包含对/wp-json/的速率限制或访问控制。

安全加固清单：上线前的最后检查

在将网站投入生产环境之前，请对照以下清单逐项检查：

• IIS版本： 确保IIS是最新版本，已安装所有安全补丁。Windows Server 2012 R2及以下版本存在已知漏洞，建议升级。
• PHP版本： 使用PHP 8.1或更高版本。旧版本PHP存在大量未修复的安全漏洞。
• HTTPS强制： 在IIS中配置“重定向”，将所有HTTP请求强制跳转到HTTPS。未加密的传输是信息泄露的主要渠道。
• SSL证书： 使用Let's Encrypt或企业级证书，确保证书链完整。MDN Web Docs建议，现代浏览器对证书颁发机构有严格限制，使用自签名证书会导致安全警告，严重影响用户信任。
• 文件权限： WordPress核心文件权限应为644，目录权限为755。wp-config.php权限应设为600，仅允许IIS应用池用户读取。
• 隐藏版本信息： 在wp-config.php中定义WP_DEBUG为false，并在functions.php中移除wp_version输出。
• 定期备份： 配置每日自动备份，包括数据库和文件。备份文件应存储在异地服务器或对象存储中，防止勒索病毒加密。
• 监控告警： 部署简单的日志监控，对频繁的404错误、异常的PHP执行请求进行告警。

特别提醒：

不要使用在线生成的web.config。很多在线工具生成的配置过于宽松，或者包含不必要的规则。手动编写或复制上述经过验证的配置，是最安全的选择。

最后的话：

网站安全不是一次性的工作，而是持续的运维过程。但基础配置的正确性，决定了你的安全底线。

你更倾向模板建站还是定制开发？欢迎评论，分享你的安全配置经验。