JAVA网站如何防止sql注入攻击，是目前许多网站运营者比较头疼的一个安全问题，
随着java orm技术的快速崛起，Java web开发的网站，在大数据网站发展上已经越来越远离SQL
注入攻击的问题了，在现在互联网中，使用PHP和Python构建的web应用是目前SQL注入的重灾
区。本文虽然是从JAVA的角度来研究SQL注入代码的问题，但原理上同样适用于其他开发语言，
希望读者可以通过此文，融会贯通.
下面介绍一下几个java常用的框架介绍：MyBatis 是支持定制化 SQL、存储过程以及高级映
射的优秀的持久层框架， 其几乎避免了所有的 JDBC 代码和手动设置参数以及获取结果集。同
时，MyBatis 可以对配置和原生Map使用简单的 XML 或注解，将接口和 Java 的 POJOs
(Plain Old Java Objects,普通的 Java对象)映射成数据库中的记录，因此mybatis现在在市场中采
用率也非常高。这里我们定义如下一个mapper，来实现通过用户名查询管理员的接口：Sine安全
公司是一家专注于：服务器安全、网站安全、网站安全检测、网站漏洞修复,渗透测试,安全服务于
射的优秀的持久层框架， 其几乎避免了所有的 JDBC 代码和手动设置参数以及获取结果集。同
时，MyBatis 可以对配置和原生Map使用简单的 XML 或注解，将接口和 Java 的 POJOs
(Plain Old Java Objects,普通的 Java对象)映射成数据库中的记录，因此mybatis现在在市场中采
用率也非常高。这里我们定义如下一个mapper，来实现通过用户名查询管理员的接口：Sine安全
公司是一家专注于：服务器安全、网站安全、网站安全检测、网站漏洞修复,渗透测试,安全服务于
一体的网络安全服务提供商。
原来在mybatis中如果以${}形式声明为SQL传递参数，mybatis将不会进行参数预处理，会直接动
态拼接SQL语句，此时就会存在被注入的风险，所以在使用mybatis作为持久框架时应尽量避免采
用${}的形式进行参数传递，如果无法避免（有些SQL语句如like、in、order by等，程序员可能依
然会选择${}的方式传参），那就需要对传入参数自行进行转义过滤。
态拼接SQL语句，此时就会存在被注入的风险，所以在使用mybatis作为持久框架时应尽量避免采
用${}的形式进行参数传递，如果无法避免（有些SQL语句如like、in、order by等，程序员可能依
然会选择${}的方式传参），那就需要对传入参数自行进行转义过滤。
很多JAVA开发的网站，使用了比较基础的JDBC的方式进行数据库操作，直接使JDBC构
建DAO在比较老的系统中还是很常见的，但这并不意味着使用JDBC就一定不安全，如果我将传
入的参数 xxxx'or'a'='a 整体作为参数进行name查询，那就不会产生SQL注入。在JDBC中，提
供了PreparedStatement （预处理执行语句）的方式，可以对SQL语句进行查询参数化，使用预
处理后的代码如下：
建DAO在比较老的系统中还是很常见的，但这并不意味着使用JDBC就一定不安全，如果我将传
入的参数 xxxx'or'a'='a 整体作为参数进行name查询，那就不会产生SQL注入。在JDBC中，提
供了PreparedStatement （预处理执行语句）的方式，可以对SQL语句进行查询参数化，使用预
处理后的代码如下：
同样，我们使用上文的注入方式注入 ，此时我们发现，SQL注入并没有成功。现在我们来打印一
下被被预处理后的SQL，看看有什么变化。看到了吗?所有的 ' 都被 \' 转义掉了,从而可以确保
SQL的查询参数就是参数，不会被恶意执行，从而防止了SQL注入攻击。
下被被预处理后的SQL，看看有什么变化。看到了吗?所有的 ' 都被 \' 转义掉了,从而可以确保
SQL的查询参数就是参数，不会被恶意执行，从而防止了SQL注入攻击。
JPA是Sun公司用来整合ORM技术，所有开发网站按照ORM标准而定义的Java Persistence
API（java持久层API），JPA只是一套接口，目前引入JPA的项目都会采用Hibernate作为其具体
实现，随着无配置Spring Boot框架的流行，JPA越来越具有作为持久化首选的技术，因为其能让
程序员写更少的代码，就能完成现有的功能，例如强大的JpaRepository，常规的SQL查询只需
按照命名规则定义接口，便可以不写SQL（JPQL/SQL）就可以实现数据的查询操作，从SQL注
入防范的角度来说，这种将安全责任抛给框架远比依靠程序员自身控制来的保险。因此如果项目
使用JPA作为数据访问层，基本上可以很大程度的消除SQL注入的风险。但是话不能说的太死，
在我见过的一个Spring Boot项目中。
虽然采用了JPA作为持久框架，但是有一位老程序员不熟悉于使用JPQL来构建查询接口，依旧使用
字符串拼接的方式来实现业务，而为项目安全埋下了隐患。Sine安全公司是一家专注于：服务器安
全、网站安全、网站安全检测、网站漏洞修复,渗透测试,安全服务于一体的网络安全服务提供商。
API（java持久层API），JPA只是一套接口，目前引入JPA的项目都会采用Hibernate作为其具体
实现，随着无配置Spring Boot框架的流行，JPA越来越具有作为持久化首选的技术，因为其能让
程序员写更少的代码，就能完成现有的功能，例如强大的JpaRepository，常规的SQL查询只需
按照命名规则定义接口，便可以不写SQL（JPQL/SQL）就可以实现数据的查询操作，从SQL注
入防范的角度来说，这种将安全责任抛给框架远比依靠程序员自身控制来的保险。因此如果项目
使用JPA作为数据访问层，基本上可以很大程度的消除SQL注入的风险。但是话不能说的太死，
在我见过的一个Spring Boot项目中。
虽然采用了JPA作为持久框架，但是有一位老程序员不熟悉于使用JPQL来构建查询接口，依旧使用
字符串拼接的方式来实现业务，而为项目安全埋下了隐患。Sine安全公司是一家专注于：服务器安
全、网站安全、网站安全检测、网站漏洞修复,渗透测试,安全服务于一体的网络安全服务提供商。
网站防sql注入的方案部署如下：
1.尽量使用预编译SQL语句：由于动态SQL语句是引发SQL注入攻击的根源。应使用预编译语句来
组装SQL查询等其他的数据库查询，添加，更改。
组装SQL查询等其他的数据库查询，添加，更改。
2.代码安全规范化：将输入安装规定编码解码后再进行输入参数安全过滤和输出编码的高效处理；
拒绝一切非规范格式的编码。
拒绝一切非规范格式的编码。
3.很多网站都会存在老系统中有大量SQL注入风险代码的问题，但是由于其已稳定支持公司业务
很久，不宜采用大面积代码更新的方式来消除sql注入的安全隐患，所以需要考虑采用其他方式
来防止SQL注入。除了在在SQL数据库执行方式上防范SQL注入攻击，很多时候还可以通过架
构上，或者通过其他过滤方式来达到防止SQL注入攻击的效果。
很久，不宜采用大面积代码更新的方式来消除sql注入的安全隐患，所以需要考虑采用其他方式
来防止SQL注入。除了在在SQL数据库执行方式上防范SQL注入攻击，很多时候还可以通过架
构上，或者通过其他过滤方式来达到防止SQL注入攻击的效果。
4.利用分层设计来避免危险：前端尽量静态化，尽量少的暴露可以访问到DAO层的接口到公网环
境中，如果现有的项目，很难修改存在注入的代码，可以考虑在web服务之前增加WAF进行流量
过滤，当然代码上就不给hacker留有攻击的漏洞才最好的方案。也可以在拥有nginx的架构下，
采用OpenRestry做流量过滤，将一些特殊字符进行转义处理。
境中，如果现有的项目，很难修改存在注入的代码，可以考虑在web服务之前增加WAF进行流量
过滤，当然代码上就不给hacker留有攻击的漏洞才最好的方案。也可以在拥有nginx的架构下，
采用OpenRestry做流量过滤，将一些特殊字符进行转义处理。
关于java JPA的防SQL注入代码，我们就不详细的讨论了，因为框架下的注入漏洞属于框架漏洞范
畴（如CVE-2016-6652），程序员只要遵循JPA架构框架的开发规范，就无需担心注入问题，框
架都为你做好幕后工作了。
畴（如CVE-2016-6652），程序员只要遵循JPA架构框架的开发规范，就无需担心注入问题，框
架都为你做好幕后工作了。
网站安全需要精心雕琢，服务器安全是100 - 1 = 0的业务，即使你防御了99%的攻击，那还不算
胜利，只要有一次网站被入侵了，那就有可能给公司带来很严重的损失跟后果。如果不懂网站安
全部署的话，也可以找专业的安全公司来部署防sql注入攻击，国内安全公司像绿盟、Sinesafe、
在安全方面都是做的比较不错的。
胜利，只要有一次网站被入侵了，那就有可能给公司带来很严重的损失跟后果。如果不懂网站安
全部署的话，也可以找专业的安全公司来部署防sql注入攻击，国内安全公司像绿盟、Sinesafe、
在安全方面都是做的比较不错的。
