SQL查询安全与SQL注入概述
SQL查询是应用与数据库交互的核心操作，若查询逻辑存在安全漏洞，攻击者可能通过构造恶意输入篡改SQL语句结构，非法获取或操作数据库数据，这种攻击方式就是SQL注入。提升SQL查询安全性的核心目标就是阻断这类恶意注入路径，从根源上避免数据库被非法访问。
SQL注入的常见攻击场景
当应用直接将用户输入的内容拼接到SQL语句中执行时，就容易出现注入漏洞。比如用户登录场景，若后端代码直接拼接用户名和密码到查询语句，攻击者输入admin' OR '1'='1作为用户名，就可能绕过密码验证直接登录。
防范SQL注入的核心原则
1. 优先使用参数化查询
参数化查询是将SQL语句的逻辑和用户输入的参数分开处理，数据库会将输入内容仅作为数据而非SQL指令执行，从机制上杜绝注入可能。这是防范SQL注入最有效的方法，所有涉及用户输入的查询都应优先采用这种方式。
以下是不同语言中使用参数化查询的示例：
// Java中使用PreparedStatement实现参数化查询 String sql = "SELECT * FROM user WHERE username = ? AND password = ?"; PreparedStatement pstmt = connection.prepareStatement(sql); // 设置参数，输入内容会被当作纯数据处理 pstmt.setString(1, username); pstmt.setString(2, password); ResultSet rs = pstmt.executeQuery();
# Python中使用pymysql实现参数化查询 import pymysql conn = pymysql.connect(host='127.0.0.1', user='root', password='123456', database='test') cursor = conn.cursor() # 参数用%s占位，执行时传入参数元组 sql = "SELECT * FROM user WHERE username = %s AND password = %s" cursor.execute(sql, (username, password)) result = cursor.fetchall()
2. 严格校验用户输入内容
对所有用户输入的内容进行合法性校验，过滤掉可能用于注入的特殊字符，比如单引号、分号、注释符号等。校验规则应根据输入字段的实际用途制定，比如手机号字段只允许数字和指定长度，邮箱字段符合邮箱格式规范。
需要注意校验要在服务端进行，前端校验仅能提升用户体验，无法作为安全防护手段。以下是简单的输入校验示例：
// Node.js中校验用户名输入，只允许字母数字和下划线
function validateUsername(username) {
const reg = /^[a-zA-Z0-9_]{4,20}$/;
return reg.test(username);
}
3. 遵循数据库最小权限原则
给应用连接数据库的账号分配最小必要权限，不要使用root、sa等最高权限账号。比如普通业务查询账号只授予SELECT权限，仅需要写入数据的账号授予INSERT权限，避免攻击者通过注入获取到过高权限后执行删表、删库等危险操作。
同时定期审查数据库账号权限，及时回收不再使用的账号和多余权限，降低权限滥用的风险。
4. 避免直接拼接SQL语句
严禁将用户输入的内容直接拼接到SQL语句字符串中，即使做了部分字符替换也可能存在绕过风险。如果必须使用动态SQL，要对拼接的内容做严格的类型转换和特殊字符转义，比如数字类型的输入先转换为整数再使用，字符串类型的输入对单引号等字符做转义处理。
以下是PHP中简单的转义示例，不过仍建议优先使用参数化查询：
// PHP中使用mysqli_real_escape_string转义特殊字符（仅作为补充方案） $username = mysqli_real_escape_string($conn, $_POST['username']); $password = mysqli_real_escape_string($conn, $_POST['password']); $sql = "SELECT * FROM user WHERE username = '$username' AND password = '$password'";
5. 敏感信息加密存储
数据库中的密码、身份证号等敏感信息不要明文存储，要使用哈希算法加密后存储，比如使用bcrypt、Argon2等专门的密码哈希算法，避免即使发生注入攻击，攻击者也无法直接获取用户的明文敏感信息。
6. 定期更新与漏洞排查
及时更新数据库版本和使用的ORM框架、数据库驱动，修复已知的安全漏洞。同时定期使用SQL注入检测工具扫描业务接口，排查潜在的注入风险，对发现的漏洞及时修复。
常见误区与注意事项
很多开发者认为只要过滤了单引号就能防范SQL注入，实际上攻击者可以通过其他方式构造恶意语句，比如利用宽字节注入、二次注入等方式绕过简单过滤。因此不要依赖单一的过滤规则，要组合使用上述多个原则提升安全性。
另外，ORM框架虽然默认会使用参数化查询，但如果开发者在ORM中手动拼接SQL语句，仍然可能出现注入漏洞，使用ORM时也要注意避免直接拼接用户输入内容。