基本概念
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等等。