摘要：

　　在WEB应用程序的中，是非常重要的一部分，但常常容易被忽视掉。在安全测试中，防止注入***尤其重要。本文介绍了SQL注入***产生的后果以及如何进行测试。

关键字：安全测试 SQL 注入***　防火墙

　　正文：

　　WEB应用程序的安全测试，防止SQL注入***，下面举一些简单的例子加以解释。——Inder P Singh。

　　许多应用程序运用了某一类型的。测试下的应用程序有一个接受用户输入的用户界面，这些输入值用来执行下列任务。

　　给用户显示相关的存储数据。例如，程序通过用户输入的登录信息检查用户凭证（权限），从而只显示相关的功能和数据。

　　将用户输入的数据存储到数据库中。例如，用户填写了一张表格并提交，程序立即将之存储到数据库中；从而，用户可以在本次会话和下次会话中获取这些数据。

　　一些用户输入值可能会被接下来程序将执行的SQL语句运用到，而程序有可能不会正确执行用户输入的值。如果是这样的话，蓄意用户可以向程序提供非法数据，这些数据接下来被运用到框架中并且用来在数据库中执行SQL语句。这就是SQL注入。该行为的结果令人鸣起警钟。

SQL注入可能导致以下结果：

　　用户可以以另一用户的身份登录到程序，甚至是管理员的身份。

　　用户可以看到其他用户的隐私信息，如其他用户的简介细节，交易细节。

　　用户可以修改应用程序配置信息以及其他用户的数据。

　　用户可以修改数据库的结构，甚至是删除应用数据库中的表格。

　　用户可以控制数据库服务器并且按照自己意愿随意执行命令。

　　因为允许SQL注入的结果是相当严重的，所以在应用程序的安全测试阶段应对SQL注入进行测试。通过对SQL注入技术有一个总体的概括，让我们来理解一些SQL注入的实际例子！

　　重点：SQL注入问题只能在测试环境中测试

　　若应用程序页面有登录功能，程序有可能使用如下所示的动态SQL语句。这条语句本应从用户表中返回至少一条用户详细信息作为结果，当SQL语句中含有输入的用户名和密码时。

如果测试人员输入John作为用户名（用户名文本框），输入Smith作为密码（密码文本框），上述SQL语句就变成：

　　如果测试人员输入John’-作为用户名，不输入密码，那么SQL语句变成：

　　我们可以注意到，SQL语句中John后面的部分成为了注释。如果用户表中有一些用户用户名为“John”，那么程序能够允许测试人员以用户John的身份登录，这样，测试人员可以看到用户John的隐私信息。

　　如果测试人员不知道任何程序中已存在的用户该怎么办呢？在这种情况下，测试人员可以尝试相似的用户名像“admin”，“administrator”，“sysadmin”。如果这些用户名在数据库中都不存在，测试人员可以输入John’ or ‘x’=’x作为用户名，Smith’ or ‘x’=’x作为密码。那么SQL语句如以下所示：

　　因为‘x’=’x’这一条件总是成立的，结果集包含用户表中所有行。程序允许测试人员以用户表中第一个用户的身份登录进去。

　　重点：测试人员在尝试下列SQL注入之前应该请求拥有数据库管理员或者开发人员权限以备份有问题的表格。

　　如果测试人员输入John’; DROP table users_details;’—作为用户名，任意值作为密码，那么SQL语句如下所示：

　　这条语句将造成表格“users_details”从数据库中永久删除。

　　虽然上述例子说明的是页面中登录功能上运用SQL注入技术，但是测试人员应在应用程序中所有接受用户输入的页面运用该技术测试，如搜索页面，反馈页面等等。

　　SQL注入可能出现在运用了SSL的程序中，即使是防火墙也不能防御SQL注入***。

　　本文中，我尽量以简单的形式解释SQL注入技术。再次强调，SQL注入只能在测试环境中测试，不能再开发环境，生产环境或者其他任何环境下测试。除了手工测试程序是否易受SQL注入***，我们还应该使用web vulnerability scanner（一款扫描工具）来检查SQL注入。