在数据库中建立一张表：
代码如下:
CREATE TABLE `article` (
字段名为articleid, 其数据类型为整数类型, 长度为11位, 不能为空值, 并且每次插入新数据时自动递增编号, 作为主键使用。
标题字段为可变长度字符串，最大长度为100个字符，采用utf8字符集编码，不允许为空值，默认值为空字符串。
`content`文本字段采用utf8字符集编码，该字段不允许为空
PRIMARY KEY (`articleid`)
该语句的存储引擎设定为MyISAM，自增起始值为7，字符集采用latin1；关于向表中添加数据的具体实现代码，这里不作展示，用户可从资源获取后直接载入数据库系统。
现在，要创建一个处理用户指令的界面，在这个界面中，我们有意不审查用户输入的信息，保留一个SQL注入的后门，以便进行检测。
代码如下：
代码如下:
我们直接在浏览器中输入：
该网址指向一个特定的网页文件，其路径包含特定参数，这个参数的值为数字一，用于标识特定的内容，这个网页文件的功能是展示相关的艺术信息，通过这个链接可以访问到详细的数据展示页面。
即可访问article表中id为1的一条记录
访问结果如下：
现在，我们借助这个薄弱环节，在不了解该薄弱环节的情况下，只能借助工具配合人工检查，来展示怎样获取article表。
输入地址栏内容：'采用输出文件方式'e:/sql.txt'%23
%23是井号的计算机编码表示，在浏览器地址输入时直接使用井号会导致数据丢失，必须输入%23才能确保井号被正确识别，这样就能屏蔽后续的数据库查询指令。
执行完毕，进入E盘，察觉到生成了sql.txt文档，点开该文件，其内容为数据表article里的某条数据信息。
这仅有条目是为何？莫非此数据表仅含条目？并非如此，因我们仅查询了id为1的条目，那么能否将article表的所有条目一次性完整获取？
能够实现，前提是你的SQL查询设计得足够通用，这一点再次强调了编写SQL查询时的通用性要求。
审视一下，若在浏览器的地址输入框里键入'导入数据到文件 'e:/sql.txt'%23'，整合进数据库指令后呈现为：
查询文章表中的所有数据,条件是文章编号等于'5',然后将结果输出到'e:/whf.txt'文件中,注释内容为'#'
仔细分析下之后，我们可以这样子构造SQL语句：
查询所有文章记录,条件为文章编号是空值,或者条件永远为真,结果输出到指定文件'e:/whf.txt'中,注释标记为#
如此一来，无论怎样WHERE子句永远成立，换言之，此SQL指令等同于以下写法：
查询所有文章信息，将其写入到指定路径的文本文件中，文件路径为'e:/whf.txt'，并添加注释说明。
明白了，这个sql语句先运行select命令，把表article的所有数据全部找出来，接着再执行into outfile 'e:/whf.txt'#'这个操作，把数据导出到那个文件里。
不信的话，你执行下……
借助SQL注入缺陷，可以推断数据表名称，字段名称，用户密码的字符数量（借助LEFT函数）等，当然，如果能够像先前展示那样直接导出数据表中的所有信息，那么就无需再去推测数据表和字段的具体名称了。
有点累了，就写到这里了。
掌握SQL注入技术后，我有了些心得体会，主要涉及后台入侵和数据库窃取两个方面，内容比较基础，正如文首所言，仅是个人归纳，并非其他目的。
