简介这是一份基于PHP开发简易博客系统的完整项目压缩包定位为PHP初学者和Web开发入门者的实战练习资源。项目围绕“brophp”框架风格与layout界面布局展开通过“index.php?id用户”的URL参数体现路由与用户请求处理逻辑能够帮助学习者理解典型博客系统的前后端协作方式。资源共包含636个文件压缩包大小约2.75MB。其中以php源码文件为主辅以html页面模板、css样式、javascript交互脚本以及gif、png、jpg等图片素材另有sql数据库脚本、db数据和少量tpl模板文件覆盖了从页面展示到数据存储的完整资源链条便于对照学习代码结构与文件组织方式。该资源目前已有102人学习使用。代码注释详细、目录层次清晰借助这个项目可以系统练习PHP基础语法、MVC分层思想、MySQL增删改查、URL参数路由、模板渲染和用户注册登录等常见功能模块也能培养错误处理与代码组织的良好习惯。对于希望独立完成一个小型博客系统的初学者来说是一份值得动手拆解和改造的参考样本。1. 一个压缩包暴露的BroPHP入口风险拿到一份名为 Blog.rar_brophp layout index.php?id_用户的开发包最值得关注的不是博客模板效果而是这个命名里隐藏的入口链路BroPHP 框架、layout 布局目录、index.php 单一入口以及一个直接由 URL 携带的 id 参数。这三个要素在遗留 PHP 项目里经常同时出现而它们恰恰是 SQL 注入、模板变量覆盖和水平越权的温床。接手过老代码审计的工程师会有同感第一件事不是扫漏洞而是先顺着入口把框架的分发规则摸清楚。下面会用一条可复现的分析路径讲清 BroPHP 从 index.php 到 controller再到 layout 模板的完整流程并把 id 参数的过滤、绑定和权限校验写成可以直接抄的代码。2. BroPHP 从 index.php 到控制器的 id 参数分发2.1 BroPHP 的入口文件到底做了什么BroPHP 的入口文件和 ThinkPHP 早期版本很像通常只有三四行?php define(APP_PATH, ./); require(APP_PATH . Core/Brophp.php); Brophp::run();APP_PATH定义项目根目录require加载核心类Brophp::run()执行框架的启动流程。run 方法内部会依次完成配置加载、注册自动加载、解析当前模块/控制器/操作名、初始化请求对象、过滤输入参数最后将控制权交给控制器。这里有一个关键点如果run()之前发生错误框架会直接输出 PHP 警告而不会走日志系统所以线上环境必须在入口文件上方加入错误捕获。如果要看run()到底做了什么可以直接打开Core/Brophp.php追踪执行顺序。在我的经验里入口越简单依赖框架默认行为越多可预测性就越差。很多遗留项目会在入口文件里塞入一堆常量和全局变量甚至直接 new 一个数据库连接这会让审计者很难判断哪个环节污染了 id 参数。所以看到入口文件超过十行就要做好心理准备。2.2 控制器中 id 参数如何进入查询一个典型文章展示控制器代码可能是这样的public function show() { $id $_GET[id]; $article M(article)-find($id); $this-assign(article, $article); $this-display(show); }M(article)-find($id)在 BroPHP 的模型底层会拼出类似SELECT * FROM article WHERE id $id的语句。这里最大的风险就是$id仅来自$_GET没有经过任何整形转换或参数绑定。攻击者提交id1 or 11整个表的内容就会被 dump 出来。即便框架提供了I(get.id, 0, intval)这类输入函数如果团队编码习惯不统一同一个项目里很容易混用安全与不安全两种写法。我一般拿到一个 PHP 包会先搜索_GET[id]后面紧跟着find、where、delete的代码把结果清单拉出来这些就是这个包所有可能被注入的点。2.3 路由配置决定 id_用户 会被如何解析有些老项目把参数命名为id_用户这看起来像是中文参数在复制过程中被截断了。实际排查时要考虑到 PHP 的变量命名规则外部变量中的空格和点号都会自动转换为下划线所以 URL 里的id.user在$_GET中会变成id_user。而id_用户中的中文和下划线会原样保留PHP 允许这样的键名存在。因此如果控制器里写的是$_GET[id]而 URL 传的是id_用户就永远取不到值。这时候需要遍历$_GET来找可能的目标参数foreach ($_GET as $key $value) { if (strpos($key, id) 0 || strpos($key, 用户) ! false) { $realId intval($value); } }这段代码的目的一是容错二是把含有id或用户的键名统一映射到一个安全的整型变量中。注意strpos返回 0 时要使用判断否则id出现在开头时会被误判为 false。2.4 在入口处做一层全局限流与参数清洗与其在每个控制器里重复写过滤不如直接在入口文件加一个统一处理函数。这样能保证后续所有控制器拿到的参数都是经过 trim 和 strip_tags 处理的function clean_inputs() { foreach ($_GET as $k $v) { if (is_array($v)) { $_GET[$k] array_map(clean_inputs, $v); } else { $_GET[$k] trim(strip_tags($v)); } } foreach ($_POST as $k $v) { if (is_array($v)) { $_POST[$k] array_map(clean_inputs, $v); } else { $_POST[$k] trim(strip_tags($v)); } } } clean_inputs(); Brophp::run();这里做了两件事递归处理数组参数去掉 HTML 标签和首尾空白。注意strip_tags不能防 SQL 注入它只是移除script之类的内容真正的防线仍然是后面的 PDO 参数绑定。这个函数也要注意递归时的引用问题上面这段代码中array_map(clean_inputs, $v)将字符串值递归处理后返回但对于二维数组也可以正常工作。这段代码放在入口还有一个好处可以统一记录原始请求方便后面审计。表单一多控制器代码就很容易漏掉过滤集中处理可以把漏掉的面缩到最小。2.5 两种 URL 模式下的路由解析差异BroPHP 的配置项URL_MODEL控制着 URL 解析方式。理解它才能解释为什么同一个index.php?id_用户在两个项目里表现完全不同。URL_MODELURL 形态解析入口注意点1index.php/article/show/id/3PATH_INFO对中文参数支持差2index.php?marticlecshowid3$_GET参数名混乱时易出错自定义blog/article/3router 规则规则文件易被绕过当URL_MODEL1时PATH_INFO会被按/分割参数对key/value依次纳入$_GET。如果 URL 是index.php/id_用户/3框架会把id_用户当作控制器名导致请求直接 404。所以遇到带下划线的中文参数优先怀疑项目处于普通 GET 模式否则控制器根本没有机会执行。2.6 入口文件本身的安全配置参考除了参数过滤入口文件还需要关闭错误显示和危险函数。老项目的php.ini往往没有做生产环境加固导致id1这类请求直接把 SQL 语句打到浏览器上。建议在入口文件顶部加上ini_set(display_errors, 0); error_reporting(E_ALL);这样开发环境仍然记录所有错误但不会在页面上输出。log_errors要打开并将日志路径指向项目外的目录ini_set(log_errors, 1); ini_set(error_log, /data/logs/php_errors.log);这段配置能让注入探测遇到盲区无论参数怎么变形页面都不会回显数据库错误攻击者只能靠布尔盲注慢慢猜。对于排查者来说日志里反而留下了清晰的攻击痕迹可以溯源。3. layout 布局模板中的用户 id 渲染与逃逸3.1 layout 文件与子模板的拼接方式BroPHP 的 layout 机制会在控制器的display()方法中自动读取布局文件。假设布局放在Layout/layout.html内容大致如下html headtitle{$title}/title/head body div idmain{__CONTENT__}/div /body /html控制器在调用时$this-assign(title, 用户中心); $this-assign(content, ./View/User/info.html); $this-display(Layout/layout.html);模板引擎先将info.html的内容解析出来替换到{__CONTENT__}然后再对 layout 整体进行变量替换。这个顺序决定了info.html中定义的变量必须已经在控制器里赋值否则就会输出空字符串。在info.html中渲染用户 id 的常见写法是div classcard span用户ID{$info.id}/span /div模板编译器会把{$info.id}处理为 PHP 变量输出是否调用htmlentities取决于框架版本。我建议在审计时直接打开Core/Template.php搜索htmlspecialchars或htmlentities如果搜不到就说明该版本默认不转义。3.2 layout 模板变量输出的安全边界为了快速判断项目中各模板变量的输出风险我整理了一个对照表模板写法编译结果安全性{$info.id}直接输出变量依赖框架是否自动转义{:htmlspecialchars($info[id])}先转义再输出安全{php} echo $info[id];{/php}原生 PHP 输出完全无转义{$info.id|intval}调用 intval 过滤对数字型参数安全这里特别要注意模板中{$info.id}和{$info[id]}的区别。前者是属性访问方式编译时先尝试读取$info-id失败后回退到$info[id]如果传入的$info是数字索引数组很可能取到 null造成页面数据缺失。老项目里经常因为这种模板写法问题把明明正确的数据渲染成空开发人员又会去控制器里加各种抑制符反而掩盖了真实错误。建议统一使用{$info[id]}并关闭模板的错误抑制选项。3.3 控制器向 layout 传递 id 时的类型陷阱当 layout 需要用到当前访问用户的 id 时经常能看到这样的赋值$uid $_GET[id]; $this-assign(uid, $uid);这会导致模板里{$uid}变成攻击者可控的字符串。如果后续还有一段内联 JavaScript用它拼 DOM 或请求地址XSS 就会直接打进来。安全的做法是$uid intval($_GET[id]); if ($uid 0) { $uid 0; } $this-assign(uid, $uid);intval能把1 or 11变成1把字符串变成 0可以消除大量字符型操作风险。但当id0时如果模板把它拼成 SQL 条件就会变成WHERE id 0可能匹配到主键为 0 的记录或返回空集。对于数据库表主键从 1 开始的情况还需要加一层$uid 1的检查否则会把 0 传给下游。3.4 layout 目录的访问控制解压后的 Blog.rar 中Layout目录如果直接暴露在 Web 根目录会带来源码泄露。Apache 下可以在站点配置或.htaccess里增加FilesMatch \.(html|tpl|layout)$ Require all denied /FilesMatchNginx 可以直接location ~* \.(html|tpl)$ { deny all; }这里需要说明的是.htaccess只对 Apache 生效而且前提是AllowOverride开启。对于 Nginxdeny all会直接返回 403但在某些反向代理场景下可能被忽略最好在应用层再判断一次请求的文件后缀。3.5 layout 的多模板加载与变量覆盖问题有些项目允许控制器根据用户 id 动态选择不同的 layout 模板写法类似$layoutId intval($_GET[layout_id]); $this-display(Layout/layout_ . $layoutId);这里如果layout_id可控攻击者传入../install/index之类路径可能会让模板引擎读取到安装向导或其他敏感文件。正确做法是对 layout 名做白名单校验$allowed [layout_default, layout_mobile]; if (!in_array($layoutId, $allowed)) { $layoutId layout_default; } $this-display(Layout/{$layoutId});注意in_array第三个参数可以设为true开启严格模式防止数字和字符串比较时的松散判断。这个技巧在电商类多皮肤项目中很实用能同时堵住模板路径穿越和变量覆盖。4. 定位并修复 id 参数引发的 SQL 注入与水平越权4.1 用 grep 画出 id 参数的调用链排查老项目我习惯先从命令行开始把id参数相关的 PHP 代码全部捞出来grep -rn \$_GET\[id\] --include*.php app/ | head -30输出里可以看到哪些文件使用了$_GET[id]紧接着看下一行是不是find、where、delete。如果是就基本确定注入点。更精确地可以把控制器的操作名和 SQL 关键词拼在一起搜索grep -rn find(\$id\|where.*\$id\|delete(\$id --include*.php app/注意转义$防止 shell 变量替换。拿到这个结果后按控制器分好类再对每个控制器检查是否有登录态和归属判断。4.2 参数绑定与整型校验的修复模板修复 SQL 注入最稳妥的是把拼接写法改为数组条件// 修复前 $article M(article)-where(id $id)-find(); // 修复后 $id I(get.id, 0, intval); if ($id 0) { $this-error(参数错误); } $article M(article)-where([id $id])-find();参数说明where([id $id])在框架底层会生成 PDO 预处理语句占位符:id由框架自动绑定SQL 注入在这个层面被彻底封住。I是 BroPHP 提供的输入获取函数第二个参数是默认值第三个参数是过滤函数。这里intval会把非数字内容直接归零所以后面必须用$id 0把非法参数挡在查询前。各写法的对比查询写法是否预处理适用场景where(id $id)否遗留代码必须改where(id :id, [id $id])是需要写原生 SQL 的场景where([id $id])是简单等值条件推荐4.3 水平越权的归属校验SQL 注入堵住后还有一类不涉及注入但同样严重的问题用户 A 可以通过修改id值访问用户 B 的个人资料。比如 URL 是index.php?museraprofileid1把id改成 2 就能看到别人的数据。修复时必须在查询条件中带上当前登录人的唯一标识。假设表结构是user_profile包含字段id、user_id、nickname正确的查询是$profileId intval($_GET[id]); $loginUserId $_SESSION[user_id]; $profile M(user_profile) -where([id $profileId, user_id $loginUserId]) -find(); if (!$profile) { $this-error(资料不存在或无权访问); }这个查询的语义是id 和 user_id 两个条件同时满足才返回数据。如果攻击者把 id 改成别人的记录但 user_id 仍是他自己的登录 id联查结果为空自然就无法越权。注意不要只在事后用if ($profile[user_id] $_SESSION[user_id])判断因为如果前面的查询本身没有加 user_id 条件攻击者依然能先拿到数据再被拦截虽然不会展示但已经造成了数据读取。4.4 本地验证注入与越权的 curl 命令拿到一个编译好的包我习惯先在本地搭一套环境然后用 curl 验证。注意备份数据库不要在生产环境执行破坏性请求。检测 SQL 注入的简单命令curl -i http://localhost/index.php?marticlecshowid1如果在返回头或页面中看到 SQL 语法错误、堆栈信息或SQLSTATE说明参数未经过滤直接拼进了 SQL。此时终止测试直接跳到修复步骤。检测水平越权需要先登录两个账号拿到各自的 cookiecurl -b PHPSESSIDtest_user1 http://localhost/index.php?musercprofileid2如果返回了 id2 的昵称、手机号等敏感数据说明越权确认。这里的PHPSESSID需要替换成实际登录后的会话标识不同框架的 cookie 名可能不同一般在浏览器开发者工具的 Network 面板里能看到。4.5 处理非规范参数名 id_用户 的通用逻辑有些老业务会把中文直接用作参数名形成index.php?id_用户3这种 URL。PHP 对这类键名能够正常解析但 PHP 版本升级后某些写法会触发编码警告。为了统一处理可以写一个提取函数function getIdFromRequest() { $candidates array_merge(array_keys($_GET), array_keys($_POST)); foreach ($candidates as $key) { if (strpos($key, id) 0) { $value isset($_GET[$key]) ? $_GET[$key] : $_POST[$key]; $id intval($value); if ($id 0) { return $id; } } } return 0; }这个函数会把所有以id开头的参数都尝试转成整型一旦遇到大于 0 的值就返回。好处是不用关心参数名中的下划线和中文坏处是如果同一个请求里同时出现了id和id_用户返回值可能不确定。因此在业务侧需要约定所有入口统一使用id放弃历史遗留的中文参数名。4.6 给查询结果做必要的数据掩码即使权限校验正确在列表页展示用户 id 时也不应该把整个表结构暴露出来。尤其是注册用户可访问的页面最好对手机号、邮箱等敏感字段统一做掩码处理foreach ($list as $row) { if (isset($row[mobile]) strlen($row[mobile]) 11) { $row[mobile] substr($row[mobile], 0, 3) . **** . substr($row[mobile], -4); } }掩码要在控制器完成而不是在模板里用正则处理。模板层做的掩码容易被后续改动绕过也容易因为编码不一致而失效。这段代码把中间的 4 位替换为星号保留前三位和后四位既满足展示需求又降低了数据被成批抓走后的泄露影响。5. 给遗留 BroPHP 项目补上最后一层防护5.1 入口全局限流与请求日志与其在每个控制器里追着改不如在入口文件加一个请求日志函数记录所有进入 index.php 的原始 URI 和客户端信息function writeAccessLog() { $logLine sprintf( %s\t%s\t%s\t%s\n, date(Y-m-d H:i:s), $_SERVER[REMOTE_ADDR], $_SERVER[REQUEST_URI], json_encode($_SESSION, JSON_UNESCAPED_UNICODE) ); file_put_contents(./logs/access.log, $logLine, FILE_APPEND); } writeAccessLog();日志文件要设定为按月切分避免单个文件过大。建议在 Nginx 的access_log之外再保留一份应用层日志因为 Nginx 日志里没有 session 信息无法判断是否越权。拿到日志后用一条命令筛选遍历特征grep -oP \bid\K[0-9] logs/access.log | sort | uniq -c | sort -rn | head -30解释\bid\K匹配id但只保留后面的数字uniq -c统计次数。如果发现某个 id 的访问次数显著高于其它并且对应的时间点集中那大概率是遍历扫描。5.2 为敏感控制器加统一签名校验对于用户更新资料、删除记录这类敏感操作即使有 session 校验我还是会再加一个签名参数。签名算法不复杂关键是不要泄露密钥。$secret your-secret-key; $uid intval($_SESSION[user_id]); $time time(); $sign md5($uid . $time . $secret); $checkSign $_GET[sign] ?? ; if (!hash_equals($sign, $checkSign)) { $this-error(签名无效); }hash_equals是 PHP 5.6 起提供的安全比较函数可以防止时序攻击。签名中的$time建议让前端生成后端验证time()与签名中的时间差不超过 5 分钟避免重放攻击。5.3 给旧的 select 查询补上 limit 和密集点最后一处容易忽略的是列表页的 id 参数例如index.php?muserclistid1这里的id可能被当作分页偏移。查询老代码时常看到findAll()不带 limit如果 id 参数影响了 SQL 的 limit 子句可能直接导致全表扫描。$pageSize 15; $offset max(0, intval($_GET[id]) - 1) * $pageSize; $list M(user_profile)-limit($offset . , . $pageSize)-select();注意这里$offset是整型拼进 limit 前也要保证是数字。可以将$offset用abs再包裹一层防止负数导致 SQL 异常。5.4 一条命令复核剩余模块做完上面的修改最后一个动作是全局检查还有没有遗漏的拼接 SQL 点。用 grep 搜出所有where调用排除数组写法后剩下的就是需要手工确认的grep -rn -where(\\|-where(\$ --include*.php app/如果输出为空说明所有查询都走数组或参数绑定。再配合之前 curl 验证过的越权用例整个 Blog.rar 中的 id 参数链路就算清理干净了。以后拿到类似的压缩包直接从入口跑一遍这个流程十分钟内就能判断这个包能不能接手。本文还有配套的精品资源点击获取