代码审计-PHP-XSS - 是木木呐Beta的小屋

1. XSS 漏洞基础

跨站脚本（Cross-Site Scripting, XSS）是指攻击者将恶意脚本注入到受信任的网站中，当其他用户浏览该网站时，脚本会在其浏览器中执行，从而窃取 Cookie、会话劫持、钓鱼等。

按存储位置分为：

反射型：恶意脚本在请求参数中，服务器直接回显，不存储。
存储型：恶意脚本被存储到数据库或文件，每次访问都会触发。
DOM 型：纯前端漏洞，不经过服务器，PHP 审计通常只关注前两种。

2. PHP 中 XSS 的常见触发点（输出上下文）

在 PHP 代码中，输出数据到 HTML 的不同位置需要不同的转义，漏掉任一环节都可能产生 XSS。

输出位置	危险函数/语句	示例
HTML 主体内容	`echo`, `print`, `print_r`, `var_dump`, `<?= ?>`	`echo $_GET['name'];`
HTML 标签属性值	同上，但输出在属性值内	`<input value="<?php echo $val; ?>">`
JavaScript 字符串	输出到 `<script>` 标签或事件处理器	`var msg = "<?php echo $msg; ?>";`
CSS 样式	输出到 `<style>` 或 `style` 属性	`background: "<?php echo $color; ?>"`
URL 参数	输出到 `href` 或 `src`	`<a href="?q=<?php echo $q; ?>">`

3. 代码审计方法论：输入追踪与输出检查

审计 XSS 的核心思路是 “数据流追踪” ：

识别所有用户输入：$_GET, $_POST, $_COOKIE, $_REQUEST, $_SERVER（如 HTTP_USER_AGENT）, 文件上传名, 数据库读取等。
追踪数据流向：从输入点开始，经过各种函数处理，最终到达输出点。
检查输出点处是否做了正确的上下文转义。

审计四步法：

STEP 1：定位所有输出函数（echo, print, print_r, var_dump, printf, die, exit 等）。
STEP 2：查看输出内容是否包含用户可控数据（直接或间接）。
STEP 3：确认在输出之前是否应用了适当的转义函数（htmlspecialchars, htmlentities, filter_var, 自定义过滤）。
STEP 4：判断转义函数是否针对当前输出上下文正确使用（参数设置是否正确）。

4. PHP 安全函数分析

htmlspecialchars()

作用：将特殊字符转换为 HTML 实体（&, ", ', <, >）。
默认：ENT_COMPAT（只转义双引号，不转义单引号）。
重要参数：
ENT_QUOTES：转义单引号和双引号（推荐）。
ENT_HTML5：指定文档类型。
ENT_SUBSTITUTE：替换无效字符。
缺陷：仅对 HTML 主体有效，不适合属性、JavaScript、CSS 上下文（需额外处理）。

htmlentities()

转换所有可用字符为实体，默认字符集可能引发问题（如中文乱码），且性能开销大，一般不推荐用于防 XSS，除非特定需求。

strip_tags()

作用：移除 HTML 和 PHP 标签。
缺陷：无法防止属性中的 JavaScript 事件（如 onclick），且有绕过方法（如 <svg onload=alert(1)>），不推荐作为主要防护手段。

filter_var() 配合 FILTER_SANITIZE_STRING

已弃用（PHP 8.1+），且无法针对上下文。

自定义过滤（正则、黑名单）极其危险，几乎总有绕过方法。

5. 绕过安全函数的经典技巧

即便使用了 htmlspecialchars，如果参数配置不当或上下文错误，依然可被利用。

未转义单引号（默认 ENT_COMPAT）：

HTML

<input value='<?php echo htmlspecialchars($name); ?>'>

CodeBlock Loading...

若 $name = "' onclick='alert(1)"，则输出 <input value='' onclick='alert(1)'>，成功执行。

在 JavaScript 字符串上下文中：

HTML

<script>var name = "<?php echo htmlspecialchars($name, ENT_QUOTES); ?>";</script>

CodeBlock Loading...

若 $name = "alert(1)\";//"，输出 var name = "alert(1)\";//";，会提前闭合字符串并注入代码。

在 HTML 属性中未对 & 二次编码：

HTML

<a href="?page=<?php echo htmlspecialchars($page); ?>">link</a>

CodeBlock Loading...

若 $page = "javascript:alert(1)"，虽然 : 和 alert 不会被转义，但 href 属性支持 javascript: 协议，可直接执行。

利用浏览器容错：如 <img src=x onerror=alert(1)>，strip_tags 可能保留 onerror。
字符编码绕过：使用 alert 等实体编码，若输出在 HTML 属性且未正确解码，可能被浏览器解析。

6. 不同上下文下的转义要求

上下文	推荐的转义方法
HTML 主体	`htmlspecialchars($data, ENT_QUOTES
HTML 属性（普通）	同上，但属性值必须用双引号包裹（推荐）。
HTML 属性（URL）	先使用 `filter_var($url, FILTER_SANITIZE_URL)` 检查协议，再用 `htmlspecialchars` 输出。
JavaScript 字符串	使用 `json_encode()`（它会自动转义 Unicode 和特殊字符），然后输出。如 `var msg = <?= json_encode($msg); ?>;`
CSS 字符串	使用 `addcslashes` 转义 `\n, \r,`,`,`` 等，或使用 `json_encode` 并放在 JSON 中。 \
URL 参数	使用 `urlencode()` 编码参数值（但参数名不可控）。

7. 存储型 XSS 审计重点

存储型 XSS 的数据来自数据库，因此审计时不仅要追踪请求输入，还要追踪数据库读取后的输出。

常见场景：

用户评论、发帖、留言板。
用户资料（昵称、签名）。
系统配置项（如站点标题）若可编辑且未转义。

审计技巧：

查找 INSERT/UPDATE 操作，查看数据是否经过过滤（可能只做了 SQL 注入防护，忽略 XSS）。
查找 SELECT 后输出到模板的位置，确认是否转义。

8. 审计工具与辅助技巧

静态分析工具：RIPS, Psalm, PHPStan（可自定义规则）。
动态调试：Xdebug 配合浏览器开发者工具，观察输出。
自动化模糊测试：Burp Suite 的 Intruder 批量发送 XSS payload。
手动审计关键词：echo, print, $_GET, $_POST, htmlspecialchars, strip_tags, addslashes, htmlentities。

9. 完整审计案例（逐步分析）

假设我们有一段博客系统的 PHP 代码：

PHP

<?php
// 显示文章内容
$id = $_GET['id'];
$article = getArticleById($id);
?>
<div class="post">
    <h1><?php echo $article['title']; ?></h1>
    <div class="content">
        <?php echo $article['content']; ?>
    </div>
    <div class="meta">
        作者：<?php echo $article['author']; ?>，
        发布时间：<?php echo $article['time']; ?>
    </div>
    <input type="button" value="收藏" onclick="addFavorite(<?php echo $article['id']; ?>)">
</div>

CodeBlock Loading...

审计步骤：

识别输入点：$_GET['id']，用于查询文章。
追踪数据流：$id → getArticleById() → 返回 $article 数组 → 输出各字段。
检查输出点：

$article['title'] 输出在 HTML 主体（<h1> 内）——需要 htmlspecialchars。
$article['content'] 输出在 div.content 内——需要 htmlspecialchars，否则用户可以提交含 <script> 的正文。
$article['author'] 和 $article['time'] 同理。
最危险：onclick="addFavorite(<?php echo $article['id']; ?>)"——未加引号且直接输出数字，若 id 来自数据库且被篡改为 1); alert(1)//，会导致 XSS。

查看防护：代码中没有任何转义函数。
结论：存在反射型（通过 id 参数可能影响查询结果，但输出主要在内容）和存储型（文章内容）XSS，以及 JavaScript 上下文注入。

修复建议：

所有输出均使用 htmlspecialchars($val, ENT_QUOTES, 'UTF-8')。
对于 JavaScript 上下文，使用 json_encode($article['id']) 确保类型安全：onclick="addFavorite(<?= json_encode($article['id']) ?>)"。

10. 修复方案与安全编码规范

统一输出编码函数：封装一个 h($str) 函数，内部调用 htmlspecialchars，并在所有模板中使用。
使用模板引擎（如 Twig）自动开启转义，极大减少遗漏。
禁用 strip_tags，改用白名单过滤（如 HTMLPurifier）如果确实需要富文本。
设置正确的字符集：header('Content-Type: text/html; charset=utf-8'); 防止编码绕过。
CSP（内容安全策略）作为深度防御，限制脚本来源。
定期代码审查 + 自动化扫描（如 OWASP ZAP）。