网络安全成为了现在互联网的焦点，这也恰恰触动了每一位用户的神经，由于设计的漏洞导致了不可收拾的恶果，验证了一句话“出来混的，迟早是要还的”，所以我想通过专题博文介绍一些常用的***技术和防范策略。

    具体来说，它是利用现有应用程序，将(恶意)的SQL命令注入到后台数据库引擎执行的能力，它可以通过在Web表单中输入(恶意)SQL语句得到一个存在安全漏洞的网站上的数据库，而不是按照设计者意图去执行SQL语句。

   记住下面几条：

    1.永远不要信任用户的输入，要对用户的输入进行校验，可以通过正则表达式，或限制长度，对单引号和双"-"进行转换等。

　　2.永远不要使用动态拼装SQL，可以使用参数化的SQL或者直接使用存储过程进行数据查询存取。

　　3.永远不要使用管理员权限的数据库连接，为每个应用使用单独的权限有限的数据库连接。

　　4.不要把机密信息明文存放，请加密或者hash掉密码和敏感的信息。

　　5.应用的异常信息应该给出尽可能少的提示，最好使用自定义的错误信息对原始错误信息进行包装，把异常信息存放在独立的表中。


通过正则表达校验用户输入

　　首先我们可以通过正则表达式校验用户输入数据中是包含：对单引号和双"-"进行转换等字符。

　　然后继续校验输入数据中是否包含SQL语句的保留字，如：WHERE，EXEC，DROP等。

通过参数化存储过程进行数据查询存取

     当我们试图在URL中嵌入恶意的SQL语句时，参数化存储过程已经帮我们校验出传递给数据库的变量不是×××，而且使用存储过程的好处是我们还可以很方便地控制用户权限，我们可以给用户分配只读或可读写权限。

　　但我们想想真的有必要每个数据库操作都定义成存储过程吗?而且那么多的存储过程也不利于日常的维护。

参数化SQL语句

    我们知道一旦有恶意SQL代码传递过来，而且被拼接到SQL语句中就会被数据库执行，那么我们是否可以在拼接之前进行判断呢?命名SQL参数。这样我们就可以避免每个数据库操作(尤其一些简单数据库操作)都编写存储过程了，而且当用户具有数据库中jobs表的读权限才可以执行该SQL语句。

添加新架构　　

    数据库架构是一个独立于数据库用户的非重复命名空间，您可以将架构视为对象的容器,也降低了数据库表名被猜测出来的可能性。

ORM框架

    现在开发都采用了框架，很多框架自带的有一些ORM模块，可以使用，如果没使用框架那就过了！

 

我们在本文中介绍了SQL Injection的基本原理，通过介绍什么是SQL Injection，怎样进行SQL Injection和如何防范SQL Injection。 作为一名Web应用开发人员，一定不要盲目相信用户的输入，而要对用户输入的数据进行严格的校验处理，否则的 话，SQL Injection将会不期而至。