# 码支付前台submit.php文件SQL注入漏洞分析
[![码支付前台SQL注入漏洞分析与安全修复方案](https://blog.xn--ubt767m.wang/content/uploadfile/text2image/67eac76c7cf77.png "码支付前台SQL注入漏洞分析与安全修复方案")](https://blog.xn--ubt767m.wang/content/uploadfile/text2image/67eac76c7cf77.png "码支付前台SQL注入漏洞分析与安全修复方案")
## 漏洞概述
码支付系统前台`submit.php`文件存在SQL注入漏洞，该漏洞源于对用户输入参数未进行有效过滤和预处理。攻击者可利用此漏洞构造恶意请求，直接操作数据库，可能导致敏感数据泄露、数据篡改或服务器权限被窃取。

## 漏洞分析
### 漏洞定位
在支付回调处理逻辑中，`submit.php`文件通过`$_REQUEST`全局变量直接接收外部参数：
```php
$orderid = $_REQUEST['pay_id'];
$key = $_REQUEST['param'];

漏洞成因

1. 未过滤输入参数：直接使用$_REQUEST获取参数且未进行类型转换或过滤处理
2. 拼接SQL语句：在订单查询环节采用字符串拼接方式构造SQL语句

   $row = $DB->get_row("SELECT * FROM pay_order WHERE orderid='{$orderid}' LIMIT 1");

攻击向量

攻击者可通过控制pay_id参数实施注入：

/submit.php?pay_id=1' AND (SELECT 1 FROM (SELECT SLEEP(5))a)-- 

此Payload将触发时间盲注，通过响应延迟判断注入结果。

漏洞验证

验证步骤

1. 使用拦截工具修改支付回调请求

2. 注入测试Payload：

   POST /submit.php HTTP/1.1
   Content-Type: application/x-www-form-urlencoded
   
   pay_id=1' AND 1=1--&param=test

3. 对比正常请求与注入请求的响应差异
4. 使用时间延迟函数验证漏洞可利用性

修复建议

短期修复方案

// 强制类型转换
$orderid = (int)$_REQUEST['pay_id'];

// 参数过滤
$key = $DB->escape($_REQUEST['param']);

长期安全方案

1. 使用预处理语句：

   $stmt = $DB->prepare("SELECT * FROM pay_order WHERE orderid = ? LIMIT 1");
   $stmt->bind_param("s", $orderid);
   $stmt->execute();

2. 输入验证机制

   • 白名单验证参数格式
   • 限制pay_id为纯数字格式

     if(!preg_match('/^\d+$/', $orderid)){
     die('Invalid order ID');
     }

3. 安全增强措施

   • 禁用$_REQUEST全局变量
   • 设置数据库账号最小权限
   • 启用WAF防护注入攻击

总结

该SQL注入漏洞暴露出系统在输入验证和查询构造方面的安全隐患。建议开发团队立即实施参数类型强制转换，并逐步迁移到预处理语句体系。同时建议对全站进行安全审计，排查类似漏洞，完善安全开发规范。