MediaWiki API存在URL参数执行JavaScript的XSS风险及解决咨询

问题成因 #

这个XSS漏洞的核心原因是api.php的help模块在处理modules参数时，直接将用户传入的参数值嵌入到页面的JavaScript上下文或HTML中，未做任何转义或验证：

• 当发起action=help请求时，系统会尝试生成对应模块的帮助页面，若模块参数被替换为恶意JS代码（比如alert(document.cookie)），系统没有把它当作纯文本处理，而是直接将其插入到页面的<script>标签或可执行的代码区域，导致浏览器直接执行这段恶意脚本。
• 本质是违反了Web安全的「输入验证+输出转义」原则，既没有对用户可控输入做合法性校验，也没有在输出时根据上下文做对应的编码转义。

有效缓解措施 #

1. 严格的输入白名单验证 #

在api.php的help模块处理逻辑中，对modules参数做白名单校验：

• 只允许符合MediaWiki模块命名规则的输入（比如仅包含字母、数字、下划线、连字符，且匹配已注册的模块名称）
• 若参数值不在白名单内，直接返回错误，拒绝处理请求

2. 输出上下文转义 #

如果必须保留动态输出参数值的逻辑，要根据输出上下文做对应转义：

• 若输出到HTML文本节点：用htmlspecialchars()（PHP）这类函数转义特殊字符（<、>、"、'、&）
• 若输出到<script>标签内的字符串：使用JS转义（比如把引号转义为\"，反斜杠转义为\\，或者用json_encode()将参数值转为合法的JS字符串）

3. 升级MediaWiki到最新稳定版 #

检查当前使用的MediaWiki版本，若为旧版本，很可能官方已发布补丁修复这类XSS漏洞，直接升级到最新稳定版是最省心的解决方案。

4. 配置Content Security Policy (CSP) #

在服务器端或MediaWiki配置中添加严格的CSP规则，限制脚本执行范围：

• 示例规则：Content-Security-Policy: default-src 'self'; script-src 'self'
• 这样即使存在XSS漏洞，浏览器也会阻止未被允许的内联脚本或外部脚本执行，大幅降低攻击风险

5. 补充参数清理（作为辅助措施） #

对modules参数做字符过滤，移除或转义可能的恶意代码字符（比如alert、(、)、eval等），但注意这只能作为辅助，不能替代白名单和转义，因为攻击者可以通过编码绕过简单过滤。

内容的提问来源于stack exchange，提问作者Arpine Harutyunyan