对SQL注入式攻击的基本了解

  什么是SQL注入式攻击?大家对这个的概念清楚吗?对于SQL注入式攻击，我们需要如何去做防范呢?在本文的内容当中，我们就来学习一下关于SQL注入式攻击的知识吧。

　　SQL注入式攻击就是攻击者在输入域或者页面请求的查询字符串，欺骗服务器执行恶意的SQL命令。在某些表单中，用户输入的内容直接用来构造(或者影响)动态SQL命令，或作为存储过程的输入参数，这类表单特别容易受到SQL注入式攻击。

　　SQL注入攻击的总体思路是：

　　1.发现SQL注入位置;

　　2.判断后台数据库类型;

　　3.确定XP_CMDSHELL可执行情况

　　4.发现web虚拟目录

　　5.上传ASP木马;

　　6.得到管理员权限。

　　为什么会存在sql注入呢，只能说SQL出身不好。因为sql作为一种解释型语言，在运行时是由一个运行时组件解释语言代码并执行其中包含的指令的语言。基于这种执行方式，产生了一系列叫做代码注入(code injection)的漏洞 。它的数据其实是由程序员编写的代码和用户提交的数据共同组成的。程序员在Web开发时，没有过滤敏感字符，绑定变量，导致攻击者可以通过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字符串篡改查询改变其原来的功能，欺骗系统授予访问权限。

　　系统环境不同，攻击者可能造成的损害也不同，这主要由应用访问数据库的安全权限决定。如果用户的帐户具有管理员或其他比较高级的权限，攻击者就可能对数据库的表执行各种他想要做的操作，包括添加、删除或更新数据，甚至可能直接删除表。

　　学会检查SQL注入式攻击

　　保障Web站点和应用程序的安全，免受SQL注入攻击涉及到三部分内容：

　　1.通过彻底审核Web站点和Web应用程序的SQL注入式攻击和其它形式的攻击漏洞来分析目前的安全状态。

　　2.确保你使用最佳的编码方法，来保证WEB应用程序和IT架构所有其它部分的安全性。

　　3.在你向Web组件添加了内容以及做出改变后，能够定期地执行Web安全的审核。

　　此外，在检查SQL 注入式攻击和其它攻击技术时，你需要牢记在心的基本原则是这样的:“WEB站点的哪一部分可以被我们认为是安全的，而实际上却向攻击者敞开了大门?”，以及“我们可以向一个应用程序提交哪些数据可以使其执行一些它不应当进行的操作?”

　　检查SQL注入攻击漏洞涉及到审核你的We站点和Web应用程序。手动进行漏洞审核复杂而且耗时。它还要求具备较高水平的专业技术和跟踪大量代码和黑客的最新伎俩的能力。

　　检查你的web站点和应用程序是否易于受到SQL注入式攻击的最佳方法是通过运用一个自动化的和启发式的Web漏洞扫描程序。

　　一个自动化的Web漏洞扫描程序可以进入你的整个Web站点并且可以自动地检查SQL注入式攻击。它会指示出哪些URL及脚本易于受到SQL注入式攻击，从而便于你立即修正其相关代码。除了可以扫描SQL注入式漏洞，一个Web应用程序扫描工具还应当检查跨站脚本攻击和其它的Web漏洞。

　　防范SQL注入式攻击

　　防止ASP.NET应用被SQL注入式攻击闯入其实并不算是一件特别难的事情，只要在利用表单输入的内容构造SQL命令之前，把所有输入内容过滤一番就可以了。过滤输入内容可以按多种方式进行。

　　1.对于动态构造SQL查询的场合，可以使用下面的技术：

　　(1)替换单引号，即把所有单独出现的单引号改成两个单引号，防止攻击者修改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'"不同的结果。

　　(2)删除用户输入内容中的所有连字符，防止攻击者构造出类如"SELECT * from Users WHERE login = 'mas' -- AND password =''"之类的查询，因为这类查询的后半部分已经被注释掉，不再有效，攻击者只要知道一个合法的用户登录名称，根本不需要知道用户的密码就可以顺利获得访问权限。

　　(3)对于用来执行查询的数据库帐户，限制其权限。用不同的用户帐户执行查询、插入、更新、删除操作。由于隔离了不同帐户可执行的操作，因而也就防止了原本用于执行SELECT命令的地方却被用于执行INSERT、UPDATE或DELETE命令。

　　2.用存储过程来执行所有的查询。SQL参数的传递方式将防止攻击者利用单引号和连字符实施攻击。此外，它还使得数据库权限可以限制到只允许特定的存储过程执行，所有的用户输入必须遵从被调用的存储过程的安全上下文，这样就很难再发生注入式攻击了。

　　3.限制表单或查询字符串输入的长度。如果用户的登录名字最多只有10个字符，那么不要认可表单中输入的10个以上的字符，这将大大增加攻击者在SQL命令中插入有害代码的难度。

　　4.检查用户输入的合法性，确信输入的内容只包含合法的数据。数据检查应当在客户端和服务器端都执行——之所以要执行服务器端验证，是为了弥补客户端验证机制脆弱的安全性。

　　在客户端，攻击者完全有可能获得网页的源代码，修改验证合法性的脚本(或者直接删除脚本)，然后将非法内容通过修改后的表单提交给服务器。因此，要保证验证操作确实已经执行，唯一的办法就是在服务器端也执行验证。你可以使用许多内建的验证对象，例如 RegularExpressionValidator，它们能够自动生成验证用的客户端脚本，当然你也可以插入服务器端的方法调用。如果找不到现成的验证对象，你可以通过CustomValidator自己创建一个。

　　5.将用户登录名称、密码等数据加密保存。加密用户输入的数据，然后再将它与数据库中保存的数据比较，这相当于对用户输入的数据进行了"消毒"处理，用户输入的数据不再对数据库有任何特殊的意义，从而也就防止了攻击者注入SQL命令。 System.Web.Security.FormsAuthentication类有一个 HashPasswordForStoringInConfigFile，非常适合于对输入数据进行消毒处理。

　　6.检查提取数据的查询所返回的记录数量。如果程序只要求返回一个记录，但实际返回的记录却超过一行，那就当作出错处理。

　　SQL注入式攻击的危害可以根据系统环境的不同而有所不同，但终究还是会有所危害，如果我们可以对其进行防范，那么就可以避免其攻击我们的数据库，对数据流里的各种资料的安全也有一定的保护。本文就讲到这里，希望大家阅读愉快，也请继续支持我们课课家教育，谢谢!