如果测试人员输入John作为用户名（用户名文本框），输入Smith作为密码（密码文本框），上述SQL语句就变成：
| SELECT * FROM Users WHERE User_Name = ‘John’ AND Password = ‘Smith’ |
如果测试人员输入John’-作为用户名，不输入密码，那么SQL语句变成：
| SELECT * FROM Users WHERE User_Name = ‘John’– AND Password = ‘’; |
我们可以注意到，SQL语句中John后面的部分成为了注释。如果用户表中有一些用户用户名为“John”，那么程序能够允许测试人员以用户John的身份登录，这样，测试人员可以看到用户John的隐私信息。
如果测试人员不知道任何程序中已存在的用户该怎么办呢？在这种情况下，测试人员可以尝试相似的用户名像“admin”，“administrator”，“sysadmin”。如果这些用户名在数据库中都不存在，测试人员可以输入John’ or ‘x’=’x作为用户名，Smith’ or ‘x’=’x作为密码。那么SQL语句如以下所示：
| SELECT * FROM Users WHERE User_Name = ‘John’ or ‘x’='x’ AND Password = ‘Smith’ or ‘x’=’x’; |
因为‘x’=’x’这一条件总是成立的，结果集包含用户表中所有行。程序允许测试人员以用户表中第一个用户的身份登录进去。
重点：测试人员在尝试下列SQL注入之前应该请求拥有数据库管理员或者开发人员权限以备份有问题的表格。
如果测试人员输入John’; DROP table users_details;’—作为用户名，任意值作为密码，那么SQL语句如下所示：
| SELECT * FROM Users WHERE User_Name = ‘John’; DROP table users_details;’ –‘ AND Password = ‘Smith’; |
这条语句将造成表格“users_details”从数据库中永久删除。
虽然上述例子说明的是页面中登录功能上运用SQL注入技术，但是测试人员应在应用程序中所有接受用户输入的页面运用该技术测试，如搜索页面，反馈页面等等。
SQL注入可能出现在运用了SSL的程序中，即使是防火墙也不能防御SQL注入攻击。
本文中，我尽量以简单的形式解释SQL注入技术。再次强调，SQL注入只能在测试环境中测试，不能再开发环境，生产环境或者其他任何环境下测试。除了手工测试程序是否易受SQL注入攻击，我们还应该使用web vulnerability scanner（一款扫描工具）来检查SQL注入。
