浅谈SQL注入

什么是SQL注入

SQL注入是影响企业运营最具有破坏性的漏洞之一。

应用程序向后台数据库进行SQL查询时，如果为攻击者提供了影响该查询的能力，就会引起SQL注入。
初步注入–绕过验证，直接登录
中级注入–借助异常获取信息。
危害扩大–获取服务器所有的库名、表名、字段名
最终目的–获取数据库中的数据

1. SQL注入不仅能通过输入框，还能通过Url达到目的。

2. 除了服务器错误页面，还有其他办法获取到数据库信息。

3. 可通过软件模拟注入行为，这种方式盗取信息的速度要比你想象中快的多。

4. 漏洞跟语言平台无关，并非asp才有注入漏洞而asp.net就没有注入漏洞，一切要看设计者是否用心。

原理分析

在接口中接受了一个String类型的name参数，并且通过字符串拼接的方式构建了查询语句。在正常情况下，用户会传入合法的name进行查询，但是黑客却会传入精心构造的参数，只要参数通过字符串拼接后依然是一句合法的SQL查询，此时SQL注入就发生了。SQL Injection原因就是由于传入的参数与系统的SQL拼接成了合法的SQL而导致的，而其本质还是将用户输入的数据当做了代码执行。在系统中只要有一个SQL注入点被黑客发现，那么黑客基本上可以执行任意想执行的SQL语句了

预防措施

• JDBC的预处理
  在JDBC中，提供了 PreparedStatement （预处理执行语句）的方式，可以对SQL语句进行查询参数化

• Mybatis下注入防范
  MyBatis 是支持定制化 SQL、存储过程以及高级映射的优秀的持久层框架， 其几乎避免了所有的 JDBC 代码和手动设置参数以及获取结果集。同时，MyBatis 可以对配置和原生Map使用简单的 XML 或注解，将接口和 Java 的 POJOs(Plain Old Java Objects,普通的 Java对象)映射成数据库中的记录，因此mybatis现在在市场中采用率也非常高。
  在mybatis中如果以$形式声明为SQL传递参数，mybatis将不会进行参数预处理，会直接动态拼接SQL语句，此时就会存在被注入的风险，所以在使用mybatis作为持久框架时应尽量避免采用${}的形式进行参数传递，如果无法避免（有些SQL如like、in、order by等，程序员可能依旧会选择${}的方式传参），那就需要对传入参数自行进行转义过滤。

• JPA注入防范
  JPA只是一套接口，目前引入JPA的项目都会采用Hibernate作为其具体实现，随着无配置Spring Boot框架的流行，JPA越来越具有作为持久化首选的技术，因为其能让程序员写更少的代码，就能完成现有的功能，例如强大的JpaRepository，常规的SQL查询只需按照命名规则定义接口，便可以不写SQL（JPQL/SQL）就可以实现数据的查询操作，从SQL注入防范的角度来说，这种将安全责任抛给框架远比依靠程序员自身控制来的保险。

SQL注入的其他防范办法

• 一切输入都是不安全的：对于接口的调用参数，要进行格式匹配，例如admin的通过name查询的接口，与之匹配的Path应该使用正则匹配（因为用户名中不应该存在特殊字符），从而确保传入参数是程序控制范围之内的参数，即只接受已知的良好输入值，拒绝不良输入。注意：验证参数应将它与输出编码技术结合使用。
• 利用分层设计来避免危险：前端尽量静态化，尽量少的暴露可以访问到DAO层的接口到公网环境中，如果现有项目，很难修改存在注入的代码，可以考虑在web服务之前增加WAF进行流量过滤，当然代码上就不给hacker留有攻击的漏洞才最好的方案。也可以在拥有nginx的架构下，采用OpenRestry做流量过滤，将一些特殊字符进行转义处理。
• 尽量使用预编译SQL语句：由于动态SQL语句是引发SQL注入的根源。应使用预编译语句来组装SQL查询。
• 规范化：将输入安装规定编码解码后再进行输入参数过滤和输出编码处理；拒绝一切非规范格式的编码。