mysql注入 —— 二次注入

系统对传入值做转义处理,无法直接注入,但取出值自动转义,代码未再次转义就用于SQL语句(非预处理方式),导致间接注入成功。以含注册、登录、修改密码功能的系统为例,修改密码时因未对值转义,使验证旧密码部分被忽略。

场景:
系统对传入值使用mysql_escape_string做了转义处理,不能直接注入,
但取出值时会自动转义,而代码中未再次转义就放到sql语句中使用(非预处理方式),使得间接注入成功,

实际场景:一个含有注册、登录、修改密码功能的系统。

数据库中有一个用户名为admin,密码为admin的用户,

现注册一个用户名为admin ' #,密码为12345的用户。

登录后将其密码修改为test

因为修改密码时会取出反转义后的用户名,代码将其直接用于sql语句,所以导致验证旧密码的部分被忽略执行。

修改密码的sql语句:

UPDATE users SET password = '$pass' WHERE username = '$user' and password = '$cur_pass';

因为未对$user做转义,所以会执行

UPDATE users SET password = 'test' WHERE username = 'admin'#' and password = '123456';

#后的代码会被忽略执行,所以最后等于无附加条件执行把admin的密码改为test

### 关于 vauditdemo 代码中的二次注入问题 #### 背景介绍 二次注入是一种安全漏洞,通常发生在应用程序未能正确处理用户输入的情况下。当恶意用户的输入被存储并再次作为查询的一部分执行时,可能会引发 SQL 注入攻击。这种类型的注入不仅依赖于即时的输入验证不足,还可能涉及先前存储的数据未经过滤或转义。 在 `vauditdemo` 的上下文中,如果该应用存在二次注入风险,则可能是由于以下原因之一: 1. 用户输入未经充分清理即存入数据库。 2. 后续从数据库读取这些数据时,未对其进行适当的转义或参数化处理[^1]。 --- #### 解决方案概述 为了有效解决 `vauditdemo` 中可能出现的二次注入问题,可以从以下几个方面入手: 1. **严格过滤用户输入** 应用程序应始终假设用户输入不可信,并对其实施严格的校验和清洗机制。例如,在接收任何外部数据之前,可以通过白名单方式限定允许的字符集,或者移除潜在危险字符(如单引号 `'` 和分号 `;`)。这一步骤有助于减少非法数据进入系统的可能性。 2. **采用预编译语句 (Prepared Statements) 或 ORM 工具** 使用支持占位符语法的技术栈来构建 SQL 查询能够显著降低注入风险。以 Python 的 SQLAlchemy 为例,它提供了强大的抽象层,使得开发者无需手动拼接字符串即可完成复杂的 CRUD 操作。以下是基于 SQLAlchemy 构建动态查询的一个简单例子: ```python from sqlalchemy import create_engine, text engine = create_engine('sqlite:///example.db') with engine.connect() as connection: user_input = "test_user" query = text("SELECT * FROM users WHERE username = :username") result = connection.execute(query.bindparams(username=user_input)) rows = result.fetchall() ``` 3. **对已保存数据重新加工后再使用** 如果某些场景下确实需要加载历史记录并与当前逻辑交互,则务必先对该部分内容做额外的安全防护措施。比如调用专门函数去除多余空白、HTML 特殊标签以及 Unicode 编码序列等特殊符号。 4. **定期审计现有代码库** 利用静态分析工具扫描项目源码查找隐患点;同时鼓励团队成员遵循最佳实践撰写新功能模块。对于像 `vauditdemo` 这样的开源项目而言,社区反馈也是改进质量的重要途径之一[^5]。 --- #### 示例演示 假定我们正在维护一个简单的博客平台,其中评论区允许访客留言。然而,假如管理员试图展示所有包含关键词 `"admin"` 的帖子列表时却遭遇了意外行为——因为某条早前发布的消息里暗藏了一段破坏性的指令片段! 原始错误版本如下所示: ```php <?php // 假设 $_GET['keyword'] 来自 URL 参数 $keyword = $_GET['keyword']; $sql = "SELECT id,title,content FROM posts WHERE content LIKE '%$keyword%'"; $result = mysqli_query($conn,$sql); ?> ``` 上述写法显然存在问题,因为它直接嵌套了未经审查过的变量 `$keyword` 。一旦有人故意构造形似 `%'; DROP TABLE posts; -- %` 的请求串,整个数据库结构都面临崩溃威胁。 修正后的推荐做法则是借助 PDO 扩展实现绑定参数传递: ```php <?php try { $pdo = new PDO('mysql:host=localhost;dbname=test', 'root', ''); // 准备带问号标记的模板表达式 $stmt = $pdo->prepare("SELECT id,title,content FROM posts WHERE content LIKE ?"); // 将百分比通配符附加至实际搜寻词两端 $searchTerm = '%' . htmlspecialchars($_GET['keyword']) . '%'; // 绑定具体值给对应位置上的占位符 $stmt->bindParam(1, $searchTerm, PDO::PARAM_STR); // 正常执行检索动作 if ($stmt->execute()) { while ($row = $stmt->fetch(PDO::FETCH_ASSOC)) { echo "<p>{$row['title']}</p>"; } } else { throw new Exception("Query failed."); } } catch(Exception $e){ die("Error encountered: ".$e->getMessage()); } ?> ``` 此番调整之后,即使面对再刁钻古怪的形式也不会轻易泄露敏感资料或是造成物理损坏。 --- ### 结论 针对 `vauditdemo` 可能存在的二次注入缺陷,应当综合运用多种手段加以防范。除了强化前端界面提示外,更重要的是要确保后端服务具备足够的鲁棒性和安全性设计原则。只有这样,才能真正意义上杜绝此类高危事件的发生概率。 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值