关键看问题是否源于框架自身设计缺陷或默认配置不当，还是由开发者编写的逻辑、权限、流程控制等引入：框架漏洞在未改配置时即可复现，如yii_debug=true泄露堆栈、gii未关闭暴露界面、csrf未启用；业务漏洞则请求合法但业务规则被绕过，如支付金额未校验、订单归属未判断、密码重置未绑定token；框架漏洞常暴露cactiverecord等类名，修复靠删配置或升级版本；业务漏洞无框架异常，修复须改代码加校验逻辑。
区分 Yii 1.1.28 中的框架漏洞和业务代码漏洞，关键看问题是否源于框架自身设计缺陷或默认配置不当，还是由开发者编写的逻辑、权限、流程控制等引入。
看触发条件是否依赖框架组件行为
框架漏洞通常在未修改默认配置、未自定义逻辑的前提下即可复现。例如：
- 调试模式开启（YII_DEBUG=true）：任意未捕获异常直接返回完整堆栈，暴露路径、数据库结构——这是框架对 YII_DEBUG 的硬编码响应，与业务代码无关；
-
Gii 模块未关闭：即使没写任何新控制器，只要访问
/index.php?r=gii就可能进入代码生成界面——属于框架自带模块的暴露风险； -
CSRF 配置缺失：
main.php中'request'=>array('enableCsrfValidation'=>false)或干脆没配——框架默认不强制开启，但业务表单一旦没加 token 校验，就构成可利用面。
看输入是否绕过业务校验却仍被框架接受
业务漏洞往往表现为“请求合法、参数合规、权限看似正常，但结果违反业务规则”。典型特征是：框架层面完全放行，问题出在业务判断缺失。例如：
- 支付接口接收
amount=1参数，后端未比对数据库中该商品原始价格，直接扣款——框架没拦，但业务逻辑没做价格一致性校验； - 用户 A 调用
/api/order/status?id=1002成功获取订单状态，而该订单实际归属用户 B——框架路由和 action 执行都没问题，但控制器里漏了WHERE user_id = Yii::app()->user->id这类归属判断； - 密码重置接口允许通过修改 URL 中的
user_id参数接管任意账号——框架照常解析参数并执行 reset 动作，但业务层没验证 token 与目标用户的绑定关系。
看错误信息是否暴露框架内部结构
框架漏洞常伴随特定痕迹：
- HTTP 响应头含
X-Powered-By: Yii Framework/1.1.28，且报错页面出现CActiveRecord、CWebApplication、CDbCommand等类名——说明异常未被捕获，框架原生错误机制生效； - 日志文件中大量
CHttpException: Unable to resolve the request "xxx"或CDbException堆栈，且路径指向protected/yiilite.php或framework/web/下文件——属框架层抛出； - 而业务漏洞一般不引发框架级异常，更多是静默成功返回错误结果（如返回
{"code":0,"msg":"success"}，但实际改错了别人的数据）。
看修复方式是否需要改框架配置或升级版本
框架漏洞修复通常不涉及重写业务逻辑：
- 删掉
defined('YII_DEBUG') or define('YII_DEBUG',true)； - 注释
'gii'=>array(...)模块配置； - 在
main.php的request组件中补上'enableCsrfValidation'=>true； - 升级到 1.1.30+ 并应用官方安全补丁（如修复 CVE-2020-15148 反序列化链）。
业务漏洞修复则必须修改控制器、模型或服务层代码，比如加权限检查、重校价格、引入状态机、限制接口调用顺序等——这些改动不会让框架版本号变化，也不会影响其他项目模块。
