客户端登录也危险？--防范SQL注入漏洞

最主要的原因是程序员在编程设计时，没有对用户提交的参数数据做充分的检查过滤，导致参数代入到SQL命令中，原有SQL命令的“语义”被篡改，且被数据库成功执行。这很可怕，它可以利用它获得数据库的敏感信息，添加用户，导出文件等操作，甚至有可能获取数据库乃至系统用户最高权限。

某个宁静的夜晚，你打开了windows操作系统，随便点击了一个数据库管理程序，输入用户名和密码登录，然后大方地查看操作数据。这一切看起来是那么的和谐和安全。但你是否会想到，客户端登录功能存在着漏洞，不法分子会随时通过它破解登录，最终盗取你的珍贵数据。

漏洞？我的登录用户名和密码只有自己知道，绝对没给人，怎么会给破解呢？恩，你做的很好，只不过这不是你的问题，是软件的设计者疏忽导致的。我们称该漏洞为“SQL注入漏洞”。

举个例子吧，以下是某个客户端的登录界面，该用户名是Ocean，密码是123456（只做演示）。



点击登录按钮，OK，验证成功进入主界面。

接下来我们输入错误的用户名和密码，看看有什么问题出现。





大家都看到了，错误的用户名和密码系统都会进行提示，用户不能登入系统。那再输入另外一个用户名“Ocean’ or 1==1 –”看看。



点击登录，咦，奇怪，密码都不用输入，怎么就成功呢？！没错，这就是SQL注入（SQL Injection）啦。

SQL注入定义：

SQL命令就是前端应用程序和后端数据库之间的接口，它能够对数据库进行查找、增加、修改和删除等操作。攻击者可利用应用程序根据提交的数据动态生成SQL命令的特性，在URL、表单域，或者其他的输入域中输入自己的SQL，改变原有的SQL命令的操作，将被修改的SQL命令注入到后端数据库引擎执行，其在web开发中尤为常见。

最主要的原因是程序员在编程设计时，没有对用户提交的参数数据做充分的检查过滤，导致参数代入到SQL命令中，原有SQL命令的“语义”被篡改，且被数据库成功执行。这很可怕，它可以利用它获得数据库的敏感信息，添加用户，导出文件等操作，甚至有可能获取数据库乃至系统用户最高权限。

例子分析：

先看看该客户端的界面、本地服务器与数据库的工作流程：



1. 客户端登陆界面把获取到的用户名和密码作为参数，传给到本地服务器；

2. 本地服务器把收到参数代入到SQL查询命令中，如Select * from users where usr=’ “+用户名+”’ and psw=’ “+密码+”’;

3. 本地服务器通过SQL命令从数据库提供的接口获取相应的数据并返回；

4. 本地服务器传回数据给客户端显示。

如果用户名是Ocean，密码是123456的，则查询命令为：select * from users where usr=’Ocean’ and psw=’ 123456’;

如果用户名为“Ocean’ or 1==1 –“，则命令变为select * from users where usr=’Ocean’or 1==1 –’ and psw=“’’;

结果很明显，第一条SQL语句按要求查找，第二条查询命令语义被更改。因为在SQL里，“–“是注释的符号，它直接把“and psw=“’’”给忽略掉了，结果只剩下select * from users where usr=’Ocean’or 1==1；又因为“or 1==1”总返回真，所以用户名和密码都不用判断就能获取数据了。到这里，大家应该都很清楚该漏洞的危险性了吧。

另外，还有一种是针对MSSQL更危险的注入，它能够控制系统，在这里就不详细多说了。

防范方法：

很简单，程序员只要在获取到的用户名和密码进行错误字符过滤，把“’”给去掉，那么这样的注入就没办法实现了。

总的来说，这里有几种解决办法（转自《Go Web编程》）：

1. 对用户输入的特殊字符（如&*’）进行转义处理，或编码转换；

2. 严格限制应用的数据库的操作权限，给此用户提供仅仅能够满足其工作的最低权限，从而最大限度的减少注入攻击对数据库的危害；

3. 检查输入的数据是否具有所期望的数据格式，严格限制变量的类型；

4. 所有的查询语句建议使用数据库提供的参数化查询接口，参数化的语句使用参数而不是将用户输入变量嵌入到SQL语句中，既不要直接拼接SQL语句。例如使用Query()等等；

5. 在应用发布之前建议使用专业的SQL注入检查工具进行检测，以及时修补被发现的SQL注入漏洞。网上有这方面的开源工具，例如sqlmap、SQLninja等；

6. 避免网站打印出SQL错误信息，比如类型错误、字段不匹配，把代码里的SQL语句暴露出来，以防止攻击者利用这些错误信息进行SQL注入。