权限管控结合防护杜绝SQL注入越权

权限管控与SQL注入防护从来不是两套孤立的安全措施，把它们割裂开来看，恰恰是很多系统出现越权漏洞的根源。SQL注入的本质是让数据库执行了预期之外的查询逻辑，而越权的本质是让系统返回了当前身份不应获取的数据。当一条被注入的SQL语句绕过了应用层的身份判断，直接以数据库账号的权限读取或修改数据时，权限管控就形同虚设。所以真正有效的防护，必须让权限判断发生在数据库访问之前、之中、之后三个环节，并且用最小权限原则约束数据库连接本身。

假设一个订单查询接口接收参数order_id，后端拼接SQL为SELECT * FROM orders WHERE id='$order_id'。攻击者提交order_id为1' OR '1'='1，SQL变成SELECT * FROM orders WHERE id='1' OR '1'='1'，此时如果应用层只校验了用户已登录，但没有校验该订单是否属于当前用户，数据库就会返回全表订单。这个漏洞链里，SQL注入负责打破查询条件限制，越权则因为缺少数据归属校验而成立。如果数据库连接账号还拥有UPDATE或DELETE权限，攻击者甚至可以通过注入执行跨用户的修改操作。很多系统只做登录态校验，不做数据级权限校验，等于把安全全部押在SQL语句本身不被篡改上，一旦注入成功，越权就是必然结果。

应用连接数据库时，绝对不要使用root或具有ALL PRIVILEGES的账号。应当为每个业务模块创建独立账号，并且只授予该模块必需的SELECT、INSERT、UPDATE、DELETE权限。例如订单查询模块的账号只读订单表，不授予用户表、支付表的任何权限。这样即使SQL注入成功，攻击者也无法通过该连接读取或修改其他业务数据。更严格的做法是使用数据库视图和存储过程，让应用账号只能访问预定义的视图，无法直接操作基表。视图本身可以内置固定的WHERE条件，比如只暴露状态为正常的数据，这样注入语句也无法绕过视图的过滤逻辑。数据库层的最小权限是权限管控的最后一道物理防线，它不依赖应用代码是否正确，只要账号权限收紧，注入造成的破坏范围就会被大幅压缩。

拼接SQL是注入漏洞的温床，参数化查询是目前最可靠的解决方案。参数化查询的核心是让SQL语句的结构和参数值分离，数据库驱动会把参数值当作纯数据处理，而不是SQL语法的一部分。以Java的PreparedStatement为例：

String sql = "SELECT * FROM orders WHERE id = ? AND user_id = ?";
PreparedStatement ps = connection.prepareStatement(sql);
ps.setInt(1, orderId);
ps.setInt(2, currentUserId);
ResultSet rs = ps.executeQuery();

这段代码中，orderId和currentUserId无论传入什么内容，都只会被当作整数参数，不可能改变SQL语句的结构。即使攻击者传入1 OR 1=1，数据库也只会把它当作一个非法整数或字符串值，查询结果为空或报错，而不会返回全表数据。参数化查询同时解决了注入问题，并且把用户身份作为查询条件写死在SQL里，天然实现了数据归属校验。很多开发者只参数化了order_id，却忘了把user_id也作为条件传入，结果注入防住了，越权依然存在。所以参数化查询必须与身份条件同时使用，缺一不可。

即使使用了参数化查询，也不能假设所有请求都来自正常业务流程。攻击者可能直接篡改请求参数，尝试访问其他用户的数据。应用层必须在每次数据访问前，明确校验当前用户对目标数据是否有操作权限。具体做法是：先从会话中获取当前用户ID，然后查询目标数据时始终带上user_id或通过关联表校验归属关系。例如查询订单前，先执行SELECT user_id FROM orders WHERE id = ?，然后比较返回的user_id是否等于当前会话中的用户ID，不相等则直接拒绝。对于列表查询，必须在WHERE条件中强制加入user_id = ?，不允许出现不带归属条件的全表查询接口。对于管理端接口，则需要基于角色的权限控制，在进入业务逻辑前校验当前角色是否有该操作的权限码。权限校验逻辑应当集中在统一的中间件或AOP切面中，避免每个接口各自实现导致遗漏。

很多团队使用ORM框架后放松了对SQL注入的警惕，认为框架自动处理了安全。实际上ORM只是减少了手写SQL的概率，如果使用原生SQL或动态查询拼接，注入风险依然存在。以MyBatis为例，使用${}拼接参数就是高危写法，必须改用#{}预编译参数。对于需要动态拼接排序字段或表名的情况，不能直接接受用户输入，应当使用白名单映射。例如用户传入sort=name，后端映射为允许的字段名order_column，再拼接到SQL中。对于JPA或Hibernate，使用JPQL时同样要使用命名参数而不是字符串拼接。ORM框架本身不能防止越权，开发者仍然需要在查询条件中显式加入归属字段。框架只是工具，安全逻辑必须由开发者主动实现。

很多系统的权限模型只做到了接口级控制，即判断当前用户是否有权限调用某个API，却没有做到数据级控制，即判断当前用户是否有权限访问API返回的每一条数据。接口级权限通过角色或权限码控制，数据级权限则需要在查询时注入数据范围条件。例如一个销售管理系统中，普通销售员可以调用客户列表接口，但只能看到自己名下的客户；销售主管可以调用同一个接口，但能看到本团队所有客户。这种数据范围差异不能靠前端隐藏按钮实现，必须在后端查询时动态拼接数据范围条件。实现方式可以是基于用户角色的数据权限规则引擎，在SQL生成前自动附加org_id或owner_id条件。数据级权限是防止越权的关键，接口级权限只是第一道门，数据级权限才是真正决定能看到什么内容的闸门。

对于涉及资金、个人信息导出、权限变更等敏感操作，即使通过了前面的所有校验，也应当增加二次验证机制。例如修改绑定手机号时，除了登录态校验，还需要短信验证码或密码确认。二次验证的作用是防止攻击者通过CSRF或会话劫持等方式冒用身份执行敏感操作。同时，所有敏感操作必须记录审计日志，包括操作者ID、操作时间、目标数据ID、操作前后值对比。审计日志本身要存储在独立数据库中，并且限制应用账号只有写入权限没有修改和删除权限。一旦发生越权事件，审计日志是追溯攻击路径和评估影响范围的核心依据。很多企业忽视审计日志的完整性，导致事后无法确定哪些数据被泄露，这是安全体系中的重大缺口。

没有任何单一措施能百分之百防止SQL注入和越权，必须建立纵深防御体系。网络层部署WAF可以拦截部分明显的注入特征，但WAF不能作为主要防线，因为编码绕过和逻辑注入往往能穿透规则。应用层必须做好参数化查询和权限校验，数据库层必须收紧账号权限，同时开启数据库审计日志。监控层面，应当对异常查询模式进行实时告警，例如短时间内大量返回全表数据的查询、包含UNION SELECT或OR 1=1特征的SQL语句、非工作时间的大量数据导出操作。安全团队需要定期对代码进行静态扫描和人工渗透测试，重点检查所有接收用户输入的SQL语句和所有数据查询接口的归属校验逻辑。安全是一个持续过程，不是上线前的一次性检查。

权限管控的最佳实践是在架构设计阶段就明确数据归属模型和权限边界。对于多租户系统，所有业务表必须包含租户ID字段，并且所有查询必须自动附加租户ID条件，从框架层面杜绝跨租户访问。对于用户级数据，所有表必须包含user_id字段，查询时强制附加该条件。不要在业务代码中散落权限判断，而是通过统一的查询拦截器或数据权限插件自动注入条件。例如在MyBatis中实现一个Interceptor，在执行任何SELECT语句前检查是否包含租户ID条件，如果没有则自动追加或直接拒绝执行。这种架构级的强制约束比依赖开发者自觉要可靠得多。同时，数据库表结构设计时应当避免使用自增ID作为唯一业务标识，可以考虑使用UUID或带租户前缀的复合主键，增加攻击者遍历数据的难度。

第一个误区是只对用户输入做转义而不使用参数化查询。转义函数容易被绕过，不同数据库的转义规则也不一致，参数化查询才是根本解法。第二个误区是认为内网系统不需要防护。大量真实案例表明，内网系统因为权限管控松散，一旦被植入恶意软件或内部人员恶意操作，造成的损失比公网系统更大。第三个误区是前端隐藏按钮当作权限控制。前端只是用户体验层，真正的权限判断必须发生在服务端，攻击者可以直接调用API绕过前端。第四个误区是过度依赖WAF而忽视代码修复。WAF规则可以被绕过，而且WAF无法理解业务逻辑中的越权问题。第五个误区是数据库账号权限过大，很多中小项目直接使用root账号连接数据库，一旦注入成功就是灾难性的。这些误区在实际项目中反复出现，根本原因是对安全边界的理解不清晰，把安全寄托在单一措施上。

要快速评估一个系统在SQL注入和越权防护上的成熟度，可以对照以下清单逐项检查：数据库连接账号是否已最小化权限；所有SQL是否使用参数化查询；所有数据查询接口是否强制附加归属条件；ORM框架中是否杜绝了字符串拼接；敏感操作是否有二次验证和审计日志；是否存在不带任何过滤条件的全表查询接口；管理端接口是否有基于角色的权限码校验；多租户场景是否所有表都包含租户ID并自动过滤；是否部署了数据库审计和异常查询监控；是否定期进行渗透测试和代码安全扫描。任何一项不满足，都意味着系统存在可被利用的漏洞链。安全建设没有捷径，把每一项基础工作做扎实，才能让权限管控和SQL注入防护真正形成合力。