有多种方法可以测试应用程序的漏洞，例如 SQL 注入。测试分为三种不同的方法：

盲注：

MySQL 示例：

http://localhost/test.php?id=sleep(30)

如果此 SQL 语句由数据库解释，则页面加载需要 30 秒。

错误信息：

http://localhost/test.php?id='"

如果启用了错误报告并且此请求易受 sql 注入攻击，则会产生以下错误：

您的 SQL 语法有错误；检查与您的 MySQL 服务器版本相对应的手册，以在第 5 行的 '"' 附近使用正确的语法

基于重言式的注射：

http://localhost/test.php?username=' or 1=1 /*&password=1

在这种情况下，提供重言式或始终为真的陈述提供了可预测的结果。在这种情况下，可预测的结果将是使用数据库中的第一个用户（通常是管理员）登录攻击者。

有一些工具可以自动使用上述方法来检测 Web 应用程序中的 SQL 注入。有免费的开源工具，例如Wapiti和Skipfish可以做到这一点。 Sitewatch提供的免费服务比这些开源工具要好很多。我可以这么说是因为我是 Sitewatch 的开发人员。

最好不要测试您的站点以进行 SQL 注入。最好避免潜在的 SQL 注入。当有用户输入时，永远不要通过自己进行字符串处理来形成 SQL 查询。在所有查询中使用绑定参数（如果可能以任何有害方式使用所有用户数据，也要清理所有用户数据，并对查询设置合理限制）。那就是查询sql_execute("select user from user_db where id="+input_id)是不安全的（想象一下，如果它的input_id = "1 OR 1==1 --"），但是stored_procedure = "select user from user_db where id = ? LIMIT 1;"，sql_execute_with_param(stored_procedure, input_id);是安全的。

显然，这仅适用于您尝试使自己的网站安全的情况。如果您试图找出其他应用程序中的缺陷，那就另当别论了，并且可能违反了说明该站点不适用于黑帽的常见问题解答。但是 OWASP 有一篇非常好的关于测试SQL 注入的文章。

如果您从零开始，我会建议以下其中一项：

1. 雇用知道自己在做什么的人
2. 使用自动化工具作为最初的权宜之计。一些选项包括 Burp Pro、ZAP 和 SQL Map。

但是请记住，当您向 Web 应用程序发送奇怪且具有潜在危险的输入时，您很有可能会破坏应用程序的完整性。

你可以彻底破坏你的网络应用程序，或者你可以将奇怪的输入存储在应用程序的数据库中，然后以某种方式提取和解析——甚至可能不是你的应用程序。

这种测试的一般规则很简单：在从已知良好的备份中恢复之前，您还没有完成测试。在完成自动注入测试之前，您不应考虑将您的应用程序置于正常运行状态。