什么是SQL注入式攻击？sql
所谓SQL注入式攻击，就是攻击者把SQL命令插入到Web表单的输入域或页面请求的查询字符串，欺骗服务器执行恶意的SQL命令。在某些表单中，用户输入的内容直接用来构造（或者影响）动态SQL命令，或做为存储过程的输入参数，这类表单特别容易受到SQL注入式攻击。常见的SQL注入式攻击过程类如：数据库
⑴ 某个应用有一个登陆页面，这个登陆页面控制着用户是否有权访问应用，它要求用户输入一个名称和密码。安全
⑵ 登陆页面中输入的内容将直接用来构造动态的SQL命令，或者直接用做存储过程的参数。例如：服务器
SELECT * from Users WHERE login = 'username' AND password = 'password'
加密
⑶ 攻击者在用户名字和密码输入框中输入"'或'1'='1"之类的内容。spa
⑷ 用户输入的内容提交给服务器以后，服务器运行上面的代码构造出查询用户的SQL命令，但因为攻击者输入的内容很是特殊，因此最后获得的SQL命令变成：.net
SELECT * from Users WHERE login = '' or '1'='1' AND password = '' or '1'='1'
unix
⑸ 服务器执行查询或存储过程，将用户输入的身份信息和服务器中保存的身份信息进行对比。code
⑹ 因为SQL命令实际上已被注入式攻击修改，已经不能真正验证用户身份，因此系统会错误地受权给攻击者。orm
若是攻击者知道应用会将表单中输入的内容直接用于验证身份的查询，他就会尝试输入某些特殊的SQL字符串篡改查询改变其原来的功能，欺骗系统授予访问权限。
系统环境不一样，攻击者可能形成的损害也不一样，这主要由应用访问数据库的安全权限决定。若是用户的账户具备管理员或其余比较高级的权限，攻击者就可能对数据库的表执行各类他想要作的操做，包括添加、删除或更新数据，甚至可能直接删除表。
例如，尽管SELECT是只读的，但不表明SQL只能这样。SQL使用分号表示结束，若是输入没有正确过滤，就没有什么能阻止咱们在字符串后构造与查询无关的指令。
咱们指望得sql语句：
SELECT
email, passwd, login_id, full_name
FROM
members
WHERE
email =
'xxxxx'
;
SELECT
email, passwd, login_id, full_name
FROM
members
WHERE
email =
'x'
;
DROP
TABLE
members;
';
SELECT
email, passwd, login_id, full_name
FROM
members
WHERE
email =
'x'
;
INSERT
INTO
members (
'email'
,
'passwd'
,
'login_id'
,
'full_name'
)
VALUES
(
'steve@unixwiz.net'
,
'hello'
,
'steve'
,
'Steve Friedl'
);'
如何防范？
好在要防止SQL注入式攻击闯入并非一件特别困难的事情，只要在利用表单输入的内容构造SQL命令以前，把全部输入内容过滤一番就能够了。过滤输入内容能够按多种方式进行。
⑴ 对于动态构造SQL查询的场合，可使用下面的技术：
第一：替换单引号，即把全部单独出现的单引号改为两个单引号，防止攻击者修改SQL命令的含义。再来看前面的例子，"SELECT * from Users WHERE login = ''' or ''1''=''1' AND password = ''' or ''1''=''1'"显然会获得与"SELECT * from Users WHERE login = '' or '1'='1' AND password = '' or '1'='1'"不一样的结果。
第二：删除用户输入内容中的全部连字符，防止攻击者构造出类如"SELECT * from Users WHERE login = 'mas' -- AND password =''"之类的查询，由于这类查询的后半部分已经被注释掉，再也不有效，攻击者只要知道一个合法的用户登陆名称，根本不须要知道用户的密码就能够顺利得到访问权限。
第三：对于用来执行查询的数据库账户，限制其权限。用不一样的用户账户执行查询、插入、更新、删除操做。因为隔离了不一样账户可执行的操做，于是也就防止了本来用于执行SELECT命令的地方却被用于执行INSERT、UPDATE或DELETE命令。
⑵ 用存储过程来执行全部的查询。SQL参数的传递方式将防止攻击者利用单引号和连字符实施攻击。此外，它还使得数据库权限能够限制到只容许特定的存储过程执行，全部的用户输入必须听从被调用的存储过程的安全上下文，这样就很难再发生注入式攻击了。如：
不安全版
|
1
2
|
Statement s =
connection
.createStatement();
ResultSet rs = s.executeQuery(
"SELECT email FROM member WHERE name = "
+ formField);
|
安全版
|
1
2
3
|
PreparedStatement ps =
connection
.prepareStatement(
"SELECT email FROM member WHERE name = ?"
);
ps.setString(1, formField);
ResultSet rs = ps.executeQuery();
|
⑶ 限制表单或查询字符串输入的长度。若是用户的登陆名字最多只有10个字符，那么不要承认表单中输入的10个以上的字符，这将大大增长攻击者在SQL命令中插入有害代码的难度。
⑷ 检查用户输入的合法性，确信输入的内容只包含合法的数据。数据检查应当在客户端和服务器端都执行——之因此要执行服务器端验证，是为了弥补客户端验证机制脆弱的安全性。
在客户端，攻击者彻底有可能得到网页的源代码，修改验证合法性的脚本（或者直接删除脚本），而后将非法内容经过修改后的表单提交给服务器。所以，要保证验证操做确实已经执行，惟一的办法就是在服务器端也执行验证。你可使用许多内建的验证对象，例如 RegularExpressionValidator，它们可以自动生成验证用的客户端脚本，固然你也能够插入服务器端的方法调用。若是找不到现成的验证对象，你能够经过CustomValidator本身建立一个。
⑸ 将用户登陆名称、密码等数据加密保存。加密用户输入的数据，而后再将它与数据库中保存的数据比较，这至关于对用户输入的数据进行了"消毒"处理，用户输入的数据再也不对数据库有任何特殊的意义，从而也就防止了攻击者注入SQL命令。 System.Web.Security.FormsAuthentication类有一个 HashPasswordForStoringInConfigFile，很是适合于对输入数据进行消毒处理。
⑹ 检查提取数据的查询所返回的记录数量。若是程序只要求返回一个记录，但实际返回的记录却超过一行，那就看成出错处理。