【MySQL安全】什么是SQL注入，怎么避免这种攻击：前端防护、后端orm框架、数据库白名单
基本概念
SQL注入是OWASP Top 10安全风险之一，它利用了应用程序对用户输入数据的不当处理。当应用程序直接将用户输入拼接到SQL查询中而没有进行适当的过滤或转义时，就可能发生SQL注入攻击。
攻击原理
假设有一个登录表单的SQL查询：
SELECT * FROM users WHERE username = '[用户输入的用户名]' AND password = '[用户输入的密码]'如果攻击者输入：
用户名: admin' --
密码: 任意实际执行的SQL变为：
SELECT * FROM users WHERE username = 'admin' --' AND password = '任意'--是SQL注释符号，使得密码检查被忽略，攻击者可以无需密码就以admin身份登录。
防御措施
现代的web系统基本上很难出现sql注入
1. 可以从前端进行防护，检验用户名是否有非法字符，如'-' 等
2. 即使前端防护过了，后端也不会写显式sql，一般会用一些orm框架，就是把数据库中的表当作类，每一行就是一个类的实例
这样做有2个好处，一是可以防止sql注入，因为你会发现，在这个例子中本质上是利用了字符串的拼接。二是提供了更上一层的抽象，每个数据库虽然都是遵循sql标准，但是各个语法都会有些许差别，假如你的系统从mysql迁移到oracle数据库，那写显式sql你就必须更改每一条语句。一个系统中的查询逻辑可能多达几千条，难道一条一条改嘛，所以现代的web系统都增加orm框架
3. 就是从数据库角度进行防护，比如白名单，我定义好有哪些语句可以查询，sql注入本质上是更改了查询的逻辑，更改后的不在白名单里，根本不让你查。
所以现代web系统基本上不会存在sql注入的风险
orm框架
@Entity //这个类是一个 JPA 实体，对应数据库中的一张表。
@Table(name = "users") //显式指定该类映射到数据库中的表名为 users
public class User {@Id //标注 id 字段是表的主键private Long id;private String name;
}Query<User> query = session.createQuery( "FROM User WHERE name = :name", User.class
);
query.setParameter("name", inputName);
这个是java语法，就是数据库中有一个user表，表中有两个字段，id和name，我把这个表抽象成一个类，查询的时候输入用户名，用User.name的私有成员代替，避免字符串直接拼接。
现在每一个后端语言，都有orm框架，甚至在这个框架之上又衍伸出来更高一层的框架，比如java的mybatis等等。