预防SQL注入：前端数据不可信,从零基础到精通，收藏这篇就够了！

.markdown-body pre,.markdown-body pre>code.hljs{color:#333;background:#f8f8f8}.hljs-comment,.hljs-quote{color:#998;font-style:italic}.hljs-keyword,.hljs-selector-tag,.hljs-subst{color:#333;font-weight:700}.hljs-literal,.hljs-number,.hljs-tag .hljs-attr,.hljs-template-variable,.hljs-variable{color:teal}.hljs-doctag,.hljs-string{color:#d14}.hljs-section,.hljs-selector-id,.hljs-title{color:#900;font-weight:700}.hljs-subst{font-weight:400}.hljs-class .hljs-title,.hljs-type{color:#458;font-weight:700}.hljs-attribute,.hljs-name,.hljs-tag{color:navy;font-weight:400}.hljs-link,.hljs-regexp{color:#009926}.hljs-bullet,.hljs-symbol{color:#990073}.hljs-built_in,.hljs-builtin-name{color:#0086b3}.hljs-meta{color:#999;font-weight:700}.hljs-deletion{background:#fdd}.hljs-addition{background:#dfd}.hljs-emphasis{font-style:italic}.hljs-strong{font-weight:700}

SQL注入预防：切记前端数据不可靠

SQL注入（SQL Injection）是当应用程序允许用户输入未经验证的数据直接插入到数据库查询中时，攻击者可以利用这一点插入恶意SQL语句，从而获得数据库的机密信息或执行其他恶意操作。为了有效预防SQL注入，我们需要理解如何使用正确的参数化查询来避免漏洞。

在我们来详细分析一下问题之前，首先理解两种常见的数据库查询方式：#{}（Mybatis）和${}（Mybatis）。这两者的行为大不相同，直接影响到是否容易受到SQL注入攻击。

1. 参数化查询：#{} vs ${}

#{}：防止SQL注入的武器

在Mybatis框架中，#{}表示一个参数化的占位符。在执行SQL时，Mybatis会自动将传入的值作为参数处理，确保它们作为“值”而非SQL代码来执行。这种方式有效避免了SQL注入的风险，因为数据库引擎将处理它们时，不会将它们作为SQL语句的一部分执行，而是会将它们视作数据。

例如，下面的SQL语句使用了#{value}：

<select name="query">
    select * from t where ${name} like #{value}
</select>

假设value传入的是用户输入的字符串，它会被Mybatis自动转义或处理为查询参数，而不是直接嵌入到SQL中，从而有效避免了恶意SQL注入的发生。

${}：危险的模板字符串

相比之下，${}表示的是字符串的直接插入，Mybatis会把传入的参数直接替换到SQL中，这可能导致SQL注入漏洞。举个例子：

<select name="query">
    select * from t where ${name} like #{value}
</select>

如果name是用户输入的，像field=title，那它会直接作为SQL的一部分被插入到查询中。这就给黑客提供了可乘之机，尤其当field参数由前端直接传入时，攻击者可以在field中注入恶意代码。

2. 黑客的攻击：如何利用SQL注入

假设攻击者发现了上述SQL的漏洞，可以利用field参数注入恶意SQL代码。攻击者可能这样构造请求：

/query?field=title like '% and author = '刘慈欣' or title&value=java

这样，SQL查询就会变成：

select * from t where title like '%' and author = '刘慈欣' or title like '%java%'

这条SQL语句被执行后，查询不仅会根据title字段查找包含java的记录，还会因为and author = '刘慈欣'的条件被引入，绕过了原本应该只查找title的限制，返回了可能包含敏感信息的记录。这就是SQL注入的典型场景。

3. 解决方案：严格控制前后端传递的字段值

要避免SQL注入，首先要理解数据的来源和用途，尤其是前端传来的数据。攻击者可能通过前端表单或URL参数传递恶意数据，因此我们需要在后端对传入的所有参数进行严格检查与处理。

一种有效的解决方法是前端的字段和后端的字段值不一致。即使前端传递的字段是title，后端接收的字段可能设置为name，这样即便攻击者将恶意代码传递给field，后端不直接接受这个传值，而是根据自己的逻辑匹配实际的数据库字段，避免了直接拼接恶意SQL。

例如，假设前端传入：

<select name="field">
    <option value="s1">Title</option>
    <option value="s2">Description</option>
</select>

而后端接收到的field和value可能会映射到不同的数据库字段名，如下所示：

@PostMapping("/query")
public Response query(String field, String value){
    Map<String, Object> params = new HashMap<>();
    // 根据前端传入的field动态映射数据库字段
    String mappedField = mapFieldToDatabaseColumn(field); // 比如 s1 -> title, s2 -> description
    params.put("name", mappedField);  // 传递映射后的字段名
    params.put("value", "%" + value + "%");
    session.selectList("query", params);
}

然后在Mybatis的SQL映射中，使用#{}来防止SQL注入：

<select name="query">
    select * from t where ${name} like #{value}
</select>

通过这种方式，攻击者即使构造了类似title like '% and author = '刘慈欣' or title&value=java的恶意请求，后台也不会直接执行，因为SQL中的name被映射到了安全的数据库字段，不会直接执行不受信任的SQL逻辑。

4. 结论：从根源上避免SQL注入

SQL注入的本质是对用户输入数据的处理不当导致的安全漏洞。通过参数化查询（#{}）和避免直接拼接SQL（${}），可以大大降低SQL注入的风险。同时，后端对前端数据的严格验证和控制，如字段映射和过滤，也能够有效防止潜在的攻击。

对于开发者来说，永远记住：前端数据永远不可信，即使是最简单的下拉框，也不能完全信任其传来的值。通过采取适当的安全措施，我们可以有效避免SQL注入，并保护系统免受攻击。

黑客/网络安全学习包

资料目录

1. 成长路线图&学习规划

2. 配套视频教程

3. SRC&黑客文籍

4. 护网行动资料

5. 黑客必读书单

6. 面试题合集

因篇幅有限，仅展示部分资料，需要点击下方链接即可前往获取

优快云大礼包：《黑客&网络安全入门&进阶学习资源包》免费分享

1.成长路线图&学习规划

要学习一门新的技术，作为新手一定要先学习成长路线图，方向不对，努力白费。

对于从来没有接触过网络安全的同学，我们帮你准备了详细的学习成长路线图&学习规划。可以说是最科学最系统的学习路线，大家跟着这个大的方向学习准没问题。

因篇幅有限，仅展示部分资料，需要点击下方链接即可前往获取

优快云大礼包：《黑客&网络安全入门&进阶学习资源包》免费分享

2.视频教程

很多朋友都不喜欢晦涩的文字，我也为大家准备了视频教程，其中一共有21个章节，每个章节都是当前板块的精华浓缩。

因篇幅有限，仅展示部分资料，需要点击下方链接即可前往获取

优快云大礼包：《黑客&网络安全入门&进阶学习资源包》免费分享

3.SRC&黑客文籍

大家最喜欢也是最关心的SRC技术文籍&黑客技术也有收录

SRC技术文籍：

黑客资料由于是敏感资源，这里不能直接展示哦！

4.护网行动资料

其中关于HW护网行动，也准备了对应的资料，这些内容可相当于比赛的金手指！

5.黑客必读书单

**

**

6.面试题合集

当你自学到这里，你就要开始思考找工作的事情了，而工作绕不开的就是真题和面试题。

更多内容为防止和谐，可以扫描获取~

因篇幅有限，仅展示部分资料，需要点击下方链接即可前往获取

优快云大礼包：《黑客&网络安全入门&进阶学习资源包》免费分享