SQL注入攻击（SQL injection）是目前网站安全以及服务器安全层面上是最具有攻击性，危害性较高，被黑客利用最多的一个漏洞，基本上针对于网站代码，包括JAVA JSP PHP ASP apache tomcat 语言开发的代码都会存在sql注入漏洞。
随着JAVA JSP架构的市场份额越来越多，许多平台都使用JAVA开发，本文通过对sql注入的详细分析，从代码层面以及服务器层面，根本上来防止sql注入攻击。
SQL注入漏洞的原理很简单，通俗来讲：就是程序员在编写网站代码的时候，一些执行数据库命令的代码，程序员没有认真写以及认真过滤，导致可以将外部的恶意参数拼接到SQL语句当中去，直接传入到数据库中去执行，导致黑客可以执行一些查询用户账户密码，修改信息，执行系统命令的安全操作。
网站安全服务
下面我们来搭建一个JAVA环境的网站，设计一个可以查询用户信息的一个api 服务接口，我们采用的都是springboot + jersey 来搭建我们的web服务查询框架。
数据库是Mysql 架构的，建立一个新的数据库表:admin，然后创建管理员账户跟密码(采用md5加密方式），这样我们的用户信息有了，就可以提供查询了。我们把springboot + jersey框架服务搭建起来，然后写一下查询的代码到框架里。Sine安全公司是一家专注于：服务器安全、网站安全、网站安全检测、网站漏洞修复,渗透测试,安全服务于一体的网络安全服务提供商。
我们再来测试下查询的接口，是否可以正常输出：
通过网站进行get请求提交，Web服务接口返回200并输出了用户名为admin的管理员账户以及密码。这样的输出是属于正常的，但是我们在网站端发送一条带有逗号的GET请求，会发现报错了。
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''xxxx''' at line 1。
也就是说上面的查询是错误的，因为我们添加了一个逗号在里面，导致传入到数据库并执行的同时，数据库返回的错误提示。
网站安全部署
SQL注入详情解析：
GET的网站时候参数的时候，传入了一个String类型的name参数值，并且通过字符串联起来，构建了数据库的查询语句。在正常操作的情况下，用户会传入合法的name参数值进行数据库查询，但是攻击者会编造一些恶意的参数，只要参数通过字符串拼接后依然是一句合法的SQL查询，此时SQL注入就发生了。正如我们上文输入的name=xxxx'or'a'='a与我们接口中的查询语句进行拼接后构成如下SQL语句如图：
当接口执行name=xxxx'or'a'='a这个SQL语句后，系统后台也就相当于免费的送给黑客了，黑客一看到管理员密码这个hash，都不用去cmd5解密了，攻击者就会直接使用123456这个密码去登录网站的后台管理系统。为什么？因为123456的md5哈希太常见了，这就是很多JAVA网站的现实，在网站安全以及弱口令方面简直做的不忍直视。
好了，现在我们应该明白了，SQL Injection原因就是由于传入的参数与系统的SQL拼接成了合法的SQL而导致的，而其本质还是将用户输入的数据当做了代码执行。在系统中只要有一个SQL注入点被黑客发现，那么黑客基本上可以执行任意想执行的SQL语句了，例如添加一个管理员，查询所有表，修改用户密码等等。
以上是对sql注入攻击的详情，下文会详细的介绍，如何去防范sql注入的攻击，知彼知己才能百战不殆。了解了sql的攻击原理，才能更好去防御sql注入攻击。
网站安全需要精心雕琢，服务器安全是100 - 1 = 0的业务，即使你防御了99%的攻击，那还不算胜利，只要有一次网站被入侵了，那就有可能给公司带来很严重的损失跟后果。如果不懂网站防SQL攻击的的话，也可以找专业的安全公司来部署防sql注入攻击部署，国内安全公司像绿盟、Sinesafe、在安全方面都是做的比较不错的。
SQL注入的其他防范办法
很多公司都会存在老系统中有大量SQL注入风险代码的问题，但是由于其已稳定支持公司业务很久，不宜采用大面积代码更新的方式来消除注入隐患，所以需要考虑其采用他方式来防范SQL注入。除了在在SQL执行方式上防范SQL注入，很多时候还可以通过架构上，或者通过其他过滤方式来达到防止SQL注入的效果。
一切输入都是不安全的：对于接口的调用参数，要进行格式匹配，例如admin的通过name查询的接口，与之匹配的Path应该使用正则匹配（因为用户名中不应该存在特殊字符），从而确保传入参数是程序控制范围之内的参数，即只接受已知的良好输入值，拒绝不良输入。注意：验证参数应将它与输出编码技术结合使用。
利用分层设计来避免危险：前端尽量静态化，尽量少的暴露可以访问到DAO层的接口到公网环境中，如果现有项目，很难修改存在注入的代码，可以考虑在web服务之前增加WAF进行流量过滤，当然代码上就不给hacker留有攻击的漏洞才最好的方案。也可以在拥有nginx的架构下，采用OpenRestry做流量过滤，将一些特殊字符进行转义处理。
尽量使用预编译SQL语句：由于动态SQL语句是引发SQL注入的根源。应使用预编译语句来组装SQL查询。
规范化：将输入安装规定编码解码后再进行输入参数过滤和输出编码处理；拒绝一切非规范格式的编码。
