一、什么是SQL注入式攻击?
所谓SQL注入式攻击，就是攻击者把SQL命令插入到Web表单的输入域或页面请求的查询字符串，欺骗服务器执行恶意的SQL命令。在某些表单中，用户输入的内容直接用来构造(或者影响)动态SQL命令，或作为存储过程的输入参数，这类表单特别容易受到SQL注入式攻击。常见的SQL注入式攻击过程类如：
⑴ 某个ASP.NET Web应用有一个登录页面，这个登录页面控制着用户是否有权访问应用，它要求用户输入一个名称和密码。
⑵ 登录页面中输入的内容将直接用来构造动态的SQL命令，或者直接用作存储过程的参数。下面是ASP.NET应用构造查询的一个例子：
System.Text.StringBuilder query = new System.Text.StringBuilder("SELECT * from Users WHERE login = ’")。Append(txtLogin.Text)。Append("’ AND password=’")。Append(txtPassword.Text)。Append("’");
⑶ 攻击者在用户名字和密码输入框中输入"’或’1’=’1"之类的内容。
⑷ 用户输入的内容提交给服务器之后，服务器运行上面的ASP.NET代码构造出查询用户的SQL命令，但由于攻击者输入的内容非常特殊，所以最后得到的SQL命令变成：SELECT * from Users WHERE login = ’’ or ’1’=’1’ AND password = ’’ or ’1’=’1’.
⑸ 服务器执行查询或存储过程，将用户输入的身份信息和服务器中保存的身份信息进行对比。
⑹ 由于SQL命令实际上已被注入式攻击修改，已经不能真正验证用户身份，所以系统会错误地授权给攻击者。
如果攻击者知道应用会将表单中输入的内容直接用于验证身份的查询，他就会尝试输入某些特殊的SQL字符串篡改查询改变其原来的功能，欺骗系统授予访问权限。
系统环境不同，攻击者可能造成的损害也不同，这主要由应用访问数据库的安全权限决定。如果用户的帐户具有管理员或其他比较高级的权限，攻击者就可能对数据库的表执行各种他想要做的操作，包括添加、删除或更新数据，甚至可能直接删除表。
二、如何防范?
好在要防止ASP.NET应用被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参数的传递方式将防止攻击者利用单引号和连字符实施攻击。此外，它还使得数据库权限可以限制到只允许特定的存储过程执行，所有的用户输入必须遵从被调用的存储过程的安全上下文，这样就很难再发生注入式攻击了。
⑶ 限制表单或查询字符串输入的长度。如果用户的登录名字最多只有10个字符，那么不要认可表单中输入的10个以上的字符，这将大大增加攻击者在SQL命令中插入有害代码的难度。
⑷ 检查用户输入的合法性，确信输入的内容只包含合法的数据。数据检查应当在客户端和服务器端都执行——之所以要执行服务器端验证，是为了弥补客户端验证机制脆弱的安全性。
在客户端，攻击者完全有可能获得网页的源代码，修改验证合法性的脚本(或者直接删除脚本)，然后将非法内容通过修改后的表单提交给服务器。因此，要保证验证操作确实已经执行，唯一的办法就是在服务器端也执行验证。你可以使用许多内建的验证对象，例如RegularExpressionValidator，它们能够自动生成验证用的客户端脚本，当然你也可以插入服务器端的方法调用。如果找不到现成的验证对象，你可以通过CustomValidator自己创建一个。
⑸ 将用户登录名称、密码等数据加密保存。加密用户输入的数据，然后再将它与数据库中保存的数据比较，这相当于对用户输入
的数据进行了“消毒”处理，用户输入的数据不再对数据库有任何特殊的意义，从而也就防止了攻击者注入SQL命令。System.Web.Security.FormsAuthentication类有一个HashPasswordForStoringInConfigFile，非常适合于对输入数据进行消毒处理。
⑹ 检查提取数据的查询所返回的记录数量。如果程序只要求返回一个记录，但实际返回的记录却超过一行，那就当作出错处理。
但在国内，这样的公司还只是占相当少的一部分，大多数的是国内的一些企业，国营，私营或者所谓的一些合资公司，而其中的相当一部分并不是很重视人力资源，虽然这个名词现在在社会上已经被炒的火热，好多公司因为是刚刚起步，或者还处于发展阶段，往往忽视了人的因素而过多将目光移到最终的结果上了，所以很多公司甚至没有人事管理部门，或者即使有也只是更多考虑到的是公司的能够在雇佣员工的过程中能够省下多少，很少能够考虑到公司的长远发展，是否能够使员工有归属感，使员工与公司保持一种相濡与沫的关系，难道双赢比独赢来得更有价值么？？盘剥到极致真的能带来极大的快感么？？所以现在很多程序员都在超负荷的工作，写程序本来就相对枯燥，但有些公司还（暗示性的）强制程序员加班，甚至不允许听音乐，上网，聊天，作为程序员，我们几乎把所有的时间都放在了工作上，我们一样是普通人，我们不是禁欲者，我们也要娱乐，却无人问津，可能仅仅因为我们同公司相比只是弱势群体，老板可以随时辞掉我们，我们就要为此付出所有么，这样的工作真的如此伟大值得我们奉献一切么？如果有些管理者看到我的文章觉得事实并不是如此，那么请他到程序员大本营或其他论坛的程序人生里面看看，或许那里的牢骚有点过盛，但那的的确确都是程序员们的心声，只不过要对老板说出来很难！我们跳槽是因为我们找不到方向，在工作中得不到归属感和成就感！
我曾经听过这样一段话，觉得很有见解"一个企业要生存十年，要看领导者的能力；要生存五十年，要看企业的管理水平；要生存百年，要看企业的文化"，现在的社会正逐步走向正规化，而正规化的前提则是建立在整个社会的信用和文化之上的。"无恒产者无恒心"，太多的公司企业只是随波逐流，缺乏长远发展的目光和目标，所以我们程序员也茫然不知未来的所在。
我个人是一个理想主义者，可能我不能办一个公司，但这不能抹煞我的认知和想法，我认为一个理想的企业文化应该考虑到公司与员工共同的利益，针对每个层次的员工制定相应的发展规划，考虑到员工个人能力和特点，给予充分的施展空间，是公司和员工的关系建立在信任之上，达到双赢的目的，让员工工作并快乐着！这其中肯定是要有太多的工作需要做的，而且要以减少一部分
公司的利益为前提，但长远的来看，绝对是值得的。
而对程序员，对于技术牛人应该给他空间和时间去钻研，并充分的信任他支持他，在生活上尽量地考虑减少其负担，千里马需要的是伯乐，上好的草料是次要的。对于科班出身的程序员，应该给他们更多的培训，是他们能够不断的接触到新知识，技术骨干的位置更适合他们；对于第三类程序员，我觉得他们更加灵活，应该给他们更多的选择机会，使他们能够找到自己的定位，看到自己
将来的发展方向，使他们不再迷茫。另外，在工作环境上营造一种快乐而积极向上的氛围，在制度尽量保证灵活，不拘泥于形势。并对员工的能力给予一定的肯定和评价，并以此提供合理的福利待遇。在这样的公司的员工应该算是幸福的了，当然，目前这也只是我的一个理想而已：）
写这篇文章的目的只是代表一部分像我一样的程序员提出一些心声，并以此得到一个结论：谁来关怀程序员？
|