假设你正在进行 Web 应用审计，发现有某个 Web 页面接受来自用户端提供的动态数据，这些数据通过
GET ， POST 或 Cookie 参数或 HTTP User-Agent 请求头发送。
因而，你想测试是否可以通过参数构造出 SQL 注入漏洞，如果有漏洞，则可以利用它们从后端 DBMS
（Database Management System，数据库管理系统）中获取尽可能多的信息，甚至进一步控制底层的文件
系统和操作系统。
http://192.168.136.131/sqlmap/mysql/get_int.php?id=1
http://192.168.136.131/sqlmap/mysql/get_int.php?id=1+AND+1=1
页面显示跟原来的一样（AND+1=1 条件取值为 True（译者注：url 编码中 + 会被转成空格）），而：
http://192.168.136.131/sqlmap/mysql/get_int.php?id=1+AND+1=2
页面显示跟原来的不一样（AND+1=2 条件取值为 False）。这可能说明 index.php 的 GET 参数 id 存
在 SQL 注入漏洞。此外，这种情形也表明用户输入的数据在 SQL 语句传送到 DBMS 之前没有被过滤。
这种设计缺陷在动态网页应用中十分常见，此类型漏洞与后端 DBMS 或后端编程语言并没有关系，漏洞的引
入通常存在于代码的编写逻辑里面。从 2013 年开始，
已将此类漏洞列入 （译者注：原链接失效，重新添加了有效链接）严重
Web 应用漏洞的 名单。
OWASP（Open Web Application Security Project，
开放 Web 应用安全组织） 最常见
前十
从上面的例子我们发现了存在可以利用的参数，现在我们可以通过在每一次的 HTTP 请求中修改 id 进行相
关的漏洞检测。
重回上面的情景，根据以往经验，我们可以对 get_ini.php 页面中如何使用用户提交的参数值构建出相
应的 SELECT 语句做一个大致的猜测。参考下面的 PHP 伪代码：
$query = "SELECT [column name(s)] FROM [table name] WHERE id=" . $_REQUEST['id'];
