怎么攻击数据库_如何攻击服务器的数据库

hacker|
140

盘点信息安全常见的Web漏洞

一、SQL注入漏洞

SQL 注入攻击( SQL Injection ),简称注入攻击、SQL注入,被广泛用于非法获取网站控制权,是发生在应用程序的数据库层上的安全漏洞。在设计程序,忽略了对输入字符串中夹带的SQL指令的检查,被数据库误认为是正常的SQL指令而运行,从而使数据库受到攻击,可能导致数据被窃取、更改、删除,以及进一步导致网站被嵌入恶意代码、被植入后门程序等危害。

通常情况下, SQL 注入的位置包括:

(1)表单提交,主要是POST 请求,也包括GET 请求;

(2)URL 参数提交,主要为GET 请求参数;

(3)Cookie 参数提交;

(4)HTTP 请求头部的一些可修改的值,比如Referer 、User_Agent 等;

(5)一些边缘的输入点,比如.mp3 文件的一些文件信息等。

SQL注入的危害不仅体现在数据库层面上, 还有可能危及承载数据库的操作系统;如果SQL 注入被用来挂马,还可能用来传播恶意软件等,这些危害包括但不局限于:

(1)数据库信息泄漏:数据库中存放的用户的隐私信息的泄露。作为数据的存储中心,数据库里往往保存着各类的隐私信息, SQL 注入攻击能导致这些隐私信息透明于攻击者。

(2)网页篡改:通过操作数据库对特定网页进行篡改。

(3)网站被挂马,传播恶意软件:修改数据库一些字段的值,嵌入网马链接,进行挂马攻击。

(4)数据库被恶意操作:数据库服务器被攻击,数据库的系统管理员帐户被篡改。

(5)服务器被远程控制,被安装后门。经由数据库服务器提供的操作系统支持,让黑客得以修改或控制操作系统。

(6)破坏硬盘数据,瘫痪全系统。

二、跨站脚本漏洞

跨站脚本攻击(Cross-site scripting,通常简称为XSS)发生在客户端,可被用于进行窃取隐私、钓鱼欺骗、窃取密码、传播恶意代码等攻击。

XSS攻击使用到的技术主要为HTML和Javascript,也包括VBScript和ActionScript等。XSS攻击对WEB服务器虽无直接危害,但是它借助网站进行传播,使网站的使用用户受到攻击,导致网站用户帐号被窃取,从而对网站也产生了较严重的危害。

XSS类型包括:

(1)非持久型跨站:即反射型跨站脚本漏洞,是目前最普遍的跨站类型。跨站代码一般存在于链接中,请求这样的链接时,跨站代码经过服务端反射回来,这类跨站的代码不存储到服务端(比如数据库中)。上面章节所举的例子就是这类情况。 (2)持久型跨站:这是危害最直接的跨站类型,跨站代码存储于服务端(比如数据库中)。常见情况是某用户在论坛发贴,如果论坛没有过滤用户输入的Javascript代码数据,就会导致其他浏览此贴的用户的浏览器会执行发贴人所嵌入的Javascript代码。 (3)DOM跨站(DOM XSS):是一种发生在客户端DOM(Document Object Model文档对象模型)中的跨站漏洞,很大原因是因为客户端脚本处理逻辑导致的安全问题。

三、弱口令漏洞

弱口令(weak password) 没有严格和准确的定义,通常认为容易被别人(他们有可能对你很了解)猜测到或被破解工具破解的口令均为弱口令。设置密码通常遵循以下原则:

(1)不使用空口令或系统缺省的口令,这些口令众所周知,为典型的弱口令。

(2)口令长度不小于8个字符。

(3)口令不应该为连续的某个字符(例如:AAAAAAAA)或重复某些字符的组合(例如:tzf.tzf.)。

(4)口令应该为以下四类字符的组合,大写字母(A-Z)、小写字母(a-z)、数字(0-9)和特殊字符。每类字符至少包含一个。如果某类字符只包含一个,那么该字符不应为首字符或尾字符。

(5)口令中不应包含本人、父母、子女和配偶的姓名和出生日期、纪念日期、登录名、E-mail地址等等与本人有关的信息,以及字典中的单词。

(6)口令不应该为用数字或符号代替某些字母的单词。

(7)口令应该易记且可以快速输入,防止他人从你身后很容易看到你的输入。

(8)至少90天内更换一次口令,防止未被发现的入侵者继续使用该口令。

四、HTTP报头追踪漏洞

HTTP/1.1(RFC2616)规范定义了HTTP TRACE方法,主要是用于客户端通过向Web服务器提交TRACE请求来进行测试或获得诊断信息。当Web服务器启用TRACE时,提交的请求头会在服务器响应的内容(Body)中完整的返回,其中HTTP头很可能包括Session Token、Cookies或其它认证信息。

攻击者可以利用此漏洞来欺骗合法用户并得到他们的私人信息。该漏洞往往与其它方式配合来进行有效攻击,由于HTTP TRACE请求可以通过客户浏览器脚本发起(如XMLHttpRequest),并可以通过DOM接口来访问,因此很容易被攻击者利用。

五、Struts2远程命令执行漏洞

ApacheStruts是一款建立Java web应用程序的开放源代码架构。Apache Struts存在一个输入过滤错误,如果遇到转换错误可被利用注入和执行任意Java代码。 网站存在远程代码执行漏洞的大部分原因是由于网站采用了Apache Struts Xwork作为网站应用框架,由于该软件存在远程代码执高危漏洞,导致网站面临安全风险。

六、文件上传漏洞

文件上传漏洞通常由于网页代码中的文件上传路径变量过滤不严造成的,如果文件上传功能实现代码没有严格限制用户上传的文件后缀以及文件类型,攻击者可通过Web访问的目录上传任意文件,包括网站后门文件( webshell ),进而远程控制网站服务器。因此,在开发网站及应用程序过程中,需严格限制和校验上传的文件,禁止上传恶意代码的文件。同时限制相关目录的执行权限,防范webshell攻击。

七、私有IP地址泄露漏洞

IP地址是网络用户的重要标示,是攻击者进行攻击前需要了解的。获取的方法较多,攻击者也会因不同的网络情况采取不同的方法,如:在局域网内使用Ping指令, Ping对方在网络中的名称而获得IP;在Internet上使用IP版的QQ直接显示。最有效的办法是截获并分析对方的网络数据包。攻击者可以找到并直接通过软件解析截获后的数据包的IP 包头信息,再根据这些信息了解具体的IP。

针对最有效的“数据包分析方法”而言,就可以安装能够自动去掉发送数据包包头IP信息的一些软件。不过使用这些软件有些缺点, 譬如:耗费资源严重,降低计算机性能;访问一些论坛或者网站时会受影响;不适合网吧用户使用等等。

现在的个人用户采用最普及隐藏IP 的方法应该是使用代理,由于使用代理服务器后,“转址服务”会对发送出去的数据包有所修改,致使“数据包分析”的方法失效。一些容易泄漏用户IP 的网络软件(QQ 、MSN 、IE 等)都支持使用代理方式连接Internet ,特别是QQ 使用“ ezProxy ”等代理软件连接后, IP版的QQ都无法显示该IP地址。虽然代理可以有效地隐藏用户IP,但攻击者亦可以绕过代理, 查找到对方的真实IP地址,用户在何种情况下使用何种方法隐藏IP,也要因情况而论。

八、未加密登录请求

由于Web 配置不安全, 登陆请求把诸如用户名和密码等敏感字段未加密进行传输,攻击者可以窃听网络以劫获这些敏感信息。

九、敏感信息泄露漏洞

SQL 注入、XSS、目录遍历、弱口令等均可导致敏感信息泄露,攻击者可以通过漏洞获得敏感信息。

Web应用漏洞原理

Web应用攻击是攻击者通过浏览器或攻击工具,在URL或者其它输入区域(如表单等),向Web服务器发送特殊请求,从中发现Web应用程序存在的漏洞,从而进一步操纵和控制网站,查看、修改未授权的信息。

数据库总是被攻击,怎样解决?

目前,针对应用及其后台数据库的应用级入侵已经变得越来越猖獗,如SQL注入、跨站点脚本攻击和未经授权的用户访问等。所有这些入侵都有可能绕过前台安全系统并对数据来源发起攻击。

为了对付这类威胁,新一级别的安全脱颖而出,这就是应用安全。这种安全技术将传统的网络和操作系统级入侵探测系统(IDS)概念应用于数据库(即应用)。与通常的网络或操作系统解决方案不同的是,应用IDS提供主动的、针对SQL的保护和监视,可以保护数以千计的预先包装或自行开发的Web应用。例如,应用IDS可以监视和防护关键的数据,使那些针对数据库的攻击,如缓冲区溢出和Web应用攻击等无法对数据库造成真正的损害,而且应用IDS还可以对这些事件进行审查。

应用安全与网络和主机安全之间存在很大的区别。应用是千差万别的,但攻击的目标总是相同的,也就是入侵数据库。由于应用使用SQL与数据库进行通信,因此好的应用IDS应当能够解析SQL,并且提供一种能够理解流量的内容,且又能与应用划清界线的客观保护层。

多数应用IDS都有三个组件。第一个是基于网络或主机的传感器。网络传感器连接到交换机上的一个端口上,该端口的配置决定它可以查看到数据库内的所有流量。相比之下,主机传感器直接驻留在应用上。传感器可以收集SQL交易并对其进行解析,然后决定是否应当针对该流量发出警报。如果有必要发出警告,警告会被传递给下一个组件,即控制台服务器。这台服务器存储事件信息,并且是策略配置和升级等传感器维护活动的中心点。应用IDS中的第三个组件是Web浏览器,管理员可以利用它来修改IDS设置、实时监视事件并生成报告。

以SQL注入攻击为例,攻击者会试图绕过Web服务器定义的SQL语句,目的就是要注入自己的语句。假设要输入的用户名为Bob,口令为Hardtoguess。

当看到这些输入的内容后,数据库就会找到WebUsers 行中与之匹配的内容,然后该应用会对用户进行验证。为了入侵数据库,SQL注入攻击会欺骗应用,并使之相信自己已经提交了正确的证书。例如,攻击使用的口令是‘blah’或‘A’=‘A’,因此攻击时创建的SQL语句可能会是:SELECT * FROM WebUsers WHERE Username=‘Bob’ AND Password=‘blah’ OR‘A’=‘A’。 

从逻辑上来分析‘A’=‘A’永远都是TRUE,而WHERE子句也可以匹配所有的行,就这样,攻击者在根本没有正确用户名或口令的情况下也能蒙混过关,得到验证。应用服务器会接受输入的信息并且允许攻击者通过。接下来,应用服务器会通过SQL命令从数据库中请求数据。 

如果有了应用IDS,传感器会收集SQL命令并对其进行解密,然后查看这些命令到底要访问数据库中的哪些表和列。利用这种方法,传感器就可以判断出到底是正常情况还是一次攻击行为。如果发现的行为是IDS策略不允许的,传感器会判断攻击的威胁水平并采取适当的措施,通常是向管理员的控制台和/或通过电子邮件发出警告。

这只是应用层攻击的一个简单例子,而且今天的许多公司都在面临这样的威胁。通过实施应用级IDS,企业就可以有效地保护易受攻击的数据,并且将最新的攻击和威胁拒之门外。

求教谁给讲讲SQL注入攻击的步骤

第一步:SQL注入点探测。探测SQL注入点是关键的第一步,通过适当的分析应用程序,可以判断什么地方存在SQL注入点。通常只要带有输入提交的动态网页,并且动态网页访问数据库,就可能存在SQL注入漏洞。如果程序员信息安全意识不强,采用动态构造SQL语句访问数据库,并且对用户输入未进行有效验证,则存在SQL注入漏洞的可能性很大。一般通过页面的报错信息来确定是否存在SQL注入漏洞。

第二步:收集后台数据库信息。不同数据库的注入方法、函数都不尽相同,因此在注入之前,我们先要判断一下数据库的类型。判断数据库类型的方法有很多,可以输入特殊字符,如单引号,让程序返回错误信息,我们根据错误信息提示进行判断,还可以使用特定函数来判断。

第三步:猜解用户名和密码。数据库中的表和字段命名一般都是有规律的,通过构造特殊的SQL语句在数据库中依次猜解出表名、字段名、字段数、用户名和密码。

第四步:查找Web后台管理入口。Web后台管理通常不对普通用户开放,要找到后台管理的登录网址,可以利用Web目录扫描工具快速搜索到可能的登录地址,然后逐一尝试,便可以找到后台管理平台的登录网址。

第五步:入侵和破坏。一般后台管理具有较高权限和较多的功能,使用前面已破译的用户名、密码成功登录后台管理平台后,就可以任意进行破坏,比如上传木马、篡改网页、修改和窃取信息等,还可以进一步提权,入侵Web服务器和数据库服务器。

可以被数据完整性机制防止的攻击方式是什么

可以被数据完整性机制防止的攻击方式是数据在途中被攻击者篡改或破坏。数据攻击是通过向某个活动中的服务发送数据,以产生非预期结果来进行的攻击。非预期结果这一说法因人而异。从攻击者看来结果是所希望的,因为它们给出了访问目标系统的许可权。从编程人员看来,那是他们的程序收到了未曾料到的将导致非预期结果的输入数据。

ddos软件攻击数据库多数表现为,cpu到100%连接数比较多、同时服务器一般都是可以登入。黑客用傀儡肉鸡对数据库攻击的一种模式,大家可以通过软防,来防护这类攻击。

遭受数据攻击通常与管理员错误的配置有关,如一个用户被误授予超过其实际需要的访问权限。另外,拥有一定访问权限的用户可以轻松地从一个应用程序跳转到数据库,即使他并没有这个数据库的相关访问权限。黑客只需要得到少量特权的用户口令,就可以进入了数据库系统,然后访问读取数据库内的任何表,包括信用卡信息、个人信息。

关于SQL注入。

SQL注入原理深度解析作者:admin 文章来源:转载 点击数:699 更新时间:2008-8-29 -------------------------------------------------------------------------------- 对于Web应用来说,注射式攻击由来已久,攻击方式也五花八门,常见的攻击方式有SQL注射、命令注射以及新近才出现的XPath注射等等。本文将以SQL注射为例,在源码级对其攻击原理进行深入的讲解。 一、注射式攻击的原理 注射式攻击的根源在于,程序命令和用户数据(即用户输入)之间没有做到泾渭分明。这使得攻击者有机会将程序命令当作用户输入的数据提交给We程序,以发号施令,为所欲为。 为了发动注射攻击,攻击者需要在常规输入中混入将被解释为命令的“数据”,要想成功,必须要做三件事情: 1.确定Web应用程序所使用的技术 注射式攻击对程序设计语言或者硬件关系密切,但是这些可以通过适当的踩点或者索性将所有常见的注射式攻击都搬出来逐个试一下就知道了。为了确定所采用的技术,攻击者可以考察Web页面的页脚,查看错误页面,检查页面源代码,或者使用诸如Nessus等工具来进行刺探。 2.确定所有可能的输入方式 Web应用的用户输入方式比较多,其中一些用户输入方式是很明显的,如HTML表单;另外,攻击者可以通过隐藏的HTML表单输入、HTTP头部、cookies、甚至对用户不可见的后端AJAX请求来跟Web应用进行交互。一般来说,所有HTTP的GET和POST都应当作用户输入。为了找出一个Web应用所有可能的用户输入,我们可以求助于Web代理,如Burp等。 3.查找可以用于注射的用户输入 在找出所有用户输入方式后,就要对这些输入方式进行筛选,找出其中可以注入命令的那些输入方式。这个任务好像有点难,但是这里有一个小窍门,那就是多多留意Web应用的错误页面,很多时候您能从这里得到意想不到的收获。 二、SQL注射原理 上面对注射攻击做了一般性的解释,下面我们以SQL注射为例进行讲解,以使读者对注射攻击有一个感性的认识,至于其他攻击,原理是一致的。 SQL注射能使攻击者绕过认证机制,完全控制远程服务器上的数据库。SQL是结构化查询语言的简称,它是访问数据库的事实标准。目前,大多数Web应用都使用SQL数据库来存放应用程序的数据。几乎所有的Web应用在后台都使用某种SQL数据库。跟大多数语言一样,SQL语法允许数据库命令和用户数据混杂在一起的。如果开发人员不细心的话,用户数据就有可能被解释成命令,这样的话,远程用户就不仅能向Web应用输入数据,而且还可以在数据库上执行任意命令了。 三、绕过用户认证 我们这里以一个需要用户身份认证的简单的Web应用程序为例进行讲解。假定这个应用程序提供一个登录页面,要求用户输入用户名和口令。用户通过HTTP请求发送他们的用户名和口令,之后,Web应用程序检查用户传递来用户名和口令跟数据库中的用户名和口令是否匹配。这种情况下,会要求在SQL数据库中使用一个数据库表。开发人员可以通过以下SQL语句来创建表: CREATETABLEuser_table( idINTEGERPRIMARYKEY, usernameVARCHAR(32), passwordVARCHAR(41) ); 上面的SQL代码将建立一个表,该表由三栏组成。第一栏存放的是用户ID,如果某人经过认证,则用此标识该用户。第二栏存放的是用户名,该用户名最多由32字符组成。第三栏存放的是口令,它由用户的口令的hash值组成,因为以明文的形式来存放用户的口令实在太危险,所以通常取口令的散列值进行存放。我们将使用SQL函数PASSWORD()来获得口令的hash值,在MySQL中,函数PASSWORD()的输出由41字符组成。 对一个用户进行认证,实际上就是将用户的输入即用户名和口令跟表中的各行进行比较,如果跟某行中的用户名和口令跟用户的输入完全匹配,那么该用户就会通过认证,并得到该行中的ID。假如用户提供的用户名和口令分别为lonelynerd15和mypassword,那么检查用户ID过程如下所示: SELECTidFROMuser_tableWHEREusername='lonelynerd15'ANDpassword=PASSWORD('mypassword') 如果该用户位于数据库的表中,这个SQL命令将返回该用户相应的ID,这就意味着该用户通过了认证;否则,这个SQL命令的返回为空,这意味着该用户没有通过认证。 下面是用来实现自动登录的Java代码,它从用户那里接收用户名和口令,然后通过一个SQL查询对用户进行认证: Stringusername=req.getParameter("username"); Stringpassword=req.getParameter("password"); Stringquery="SELECTidFROMuser_tableWHERE"+ "username='"+username+"'AND"+ "password=PASSWORD('"+password+"')"; ResultSetrs=stmt.executeQuery(query); intid=-1;//-1impliesthattheuserisunauthenticated. while(rs.next()){ id=rs.getInt("id"); } 开头两行代码从HTTP请求中取得用户输入,然后在下一行开始构造一个SQL查询。执行查询,然后在while()循环中得到结果,如果一个用户名和口令对匹配,就会返回正确的ID。否则,id的值仍然为-1,这意味着用户没有通过认证。表面上看,如果用户名和口令对匹配,那么该用户通过认证;否则,该用户不会通过认证——但是,事实果真如此吗?非也!读者也许已经注意到了,这里并没有对SQL命令进行设防,所以攻击者完全能够在用户名或者口令字段中注入SQL语句,从而改变SQL查询。为此,我们仔细研究一下上面的SQL查询字符串: Stringquery="SELECTidFROMuser_tableWHERE"+ "username='"+username+"'AND"+ "password=PASSWORD('"+password+"')"; 上述代码认为字符串username和password都是数据,不过,攻击者却可以随心所欲地输入任何字符。如果一位攻击者输入的用户名为 ’OR1=1— 而口令为 x 那么查询字符串将变成下面的样子: SELECTidFROMuser_tableWHEREusername=''OR1=1--'ANDpassword =PASSWORD('x') 该双划符号--告诉SQL解析器,右边的东西全部是注释,所以不必理会。这样,查询字符串相当于: SELECTidFROMuser_tableWHEREusername=''OR1=1 如今的SELECT语句跟以前的已经大相径庭了,因为现在只要用户名为长度为零的字符串''或1=1这两个条件中一个为真,就返回用户标识符ID——我们知道,1=1是恒为真的。所以这个语句将返回user_table中的所有ID。在此种情况下,攻击者在username字段放入的是SQL指令'OR1=1--而非数据。 四、构造SQL注射代码 为了成功地注入SQL命令,攻击者必须将开发人员的现有SQL命令转换成一个合法的SQL语句,当然,要盲注是有些难度的,但一般都是这样: 'OR1=1– 或者 ')OR1=1-- 此外,许多Web应用提供了带来错误报告和调试信息,例如,利用'OR1=1--对Web应用进行盲注时,经常看到如下所示的错误信息: Errorexecutingquery:YouhaveanerrorinyourSQLsyntax;checkthemanualthatcorrespondstoyourMySQLserverversionfortherightsyntaxtousenear'SELECT(title,body)FROMblog_tableWHEREcat='OR1=1'atline1 该错误信息详细地为我们展示了完整的SQL语句,在此种情况下,SQL数据库所期待的好象是一个整数,而非字符串,所以可以注入字符串OR1=1--,把单引号去掉就应该能成功注入了。对于大多数SQL数据库,攻击者可以在一行中放入多个SQL语句,只要各个语句的语法没有错误就行。在下面的代码中,我们展示了如何将username设为'OR1=1并把password设为x来返回最后的用户ID: Stringquery="SELECTidFROMuser_tableWHERE"+ "username='"+username+"'AND"+ "password=PASSWORD('"+password+"')"; 当然,攻击者可以注入其它的查询,例如,把username设为: 'OR1=1;DROPTABLEuser_table;-- 而这个查询将变成: SELECTidFROMuser_tableWHEREusername=''OR1=1;DROPTABLEuser_table;--'ANDpassword=PASSWORD('x'); 它相当于: SELECTidFROMuser_tableWHEREusername=''OR1=1;DROPTABLEuser_table; 这个语句将执行句法上完全正确的SELECT语句,并利用SQLDROP命令清空user_table。 注射式攻击不必非要进行盲式攻击,因为许多Web应用是利用开放源代码工具开发的,为了提高注射式攻击的成功率,我们可以下载免费的或者产品的试用版,然后在自己的系统上搭建测试系统。如果在测试系统上发现了错误,那么很可能同样的问题也会存在于所有使用该工具的Web应用身上。 五、小结 我们在本文中向读者介绍了注射攻击的根本原因,即没有对数据和命令进行严格区分。然后通过一些程序源码对SQL的攻击进行了细致的分析,使我们对SQL注射机理有了一个深入的认识。如果您是一名web应用开发人员,那么您就当心了,一定不要盲目相信用户端的输入,而要对用户输入的数据进行严格的“消毒”处理,否则的话,SQL注射将会不期而至。 【51CTO.COM 独家特稿,转载请注明出处及作者!】 本篇文章来源于 新世纪网安基地 () 原文出处: 详细吧。。 求给分额!

如何防范SQL注入漏洞及检测

以下是OMG我为大家收集整理的文章,希望对大家有所帮助。

SQL注入(SQLInjection)漏洞攻击是目前网上最流行最热门的黑客脚本攻击方法之一,那什么是SQL注入漏洞攻击呢?它是指黑客利用一些Web应用程序(如:网站、论坛、留言本、文章发布系统等)中某些存在不安全代码或SQL语句不缜密的页面,精心构造SQL语句,把非法的SQL语句指令转译到系统实际SQL语句中并执行它,以获取用户名、口令等敏感信息,从而达到控制主机服务器的攻击方法。

1. SQL注入漏洞攻击原理

1. 1 SQL注入漏洞攻击实现原理

SQL(Structured Query Language)是一种用来和数据库交互的语言文本。SQL注入的攻击原理就是攻击者通过Web应用程序利用SQL语句或字符串将非法的数据插入到服务器端数据库中,获取数据库的管理用户权限,然后将数据库管理用户权限提升至操作系统管理用户权限,控制服务器操作系统,获取重要信息及机密文件。

SQL注入漏洞攻击主要是通过借助于HDSI、NBSI和Domain等SQL注入漏洞扫描工具扫描出Web页面中存在的SQL注入漏洞,从而定位SQL注入点,通过执行非法的SQL语句或字符串达到入侵者想要的操作。下面以一段身份验证的.NET代码为例,说明一下SQL 注入攻击的实现方法。

SqlConnectionnwConn = new SqlConnection((string)ConfigurationSettings.AppSettings["DBconnStrings"]); string queryStr = "SELECT userid,userpwd, username,type FROM users where userid='" + Txtusername.Text +"'";

DataSet userSet = new DataSet();

SqlDataAdapter userAdapter = newSqlDataAdapter(queryStr, nwConn);

userAdapter.Fill(userSet, "Users");

Session["UserID"] =Txtusername.Text.ToString();

Session["type"] =type.Text.ToString();

Response.Redirect("/Myweb/admin/login.aspx");

从上面的代码中可以看出,程序在与数据库建立连接得到用户数据之后,直接将username的值通过session传给login.aspx,没有进行任何的过滤和处理措施, 直接用来构造SQL 语句, 其危险系数是非常高的, 攻击者只要根据SQL 语句的编写规则就可以绕过身份验证,从而达到入侵的目的。

1. 2 SQL注入漏洞攻击分析

SQL注入可以说是一种漏洞,也可以说是一种攻击。当程序中的变量处理不当,没有对用户提交的数据类型进行校验,编写不安全的代码,构造非法的SQL语句或字符串,都可能产生这个漏洞。

例如Web系统有一个login页面,这个login页面控制着用户是否有权访问,要求用户输入一个用户名和口令,连接数据库的语句为:

“select * from users where username = 'username' andpassword = 'password'”

攻击者输入用户名为aa or 1=1口令为1234 or 1=1之类的内容。我们可以看出实际上攻击者并不知道真正的用户名、口令,该内容提交给服务器之后,服务器执行攻击者构造出的SQL命令,但由于攻击者输入的内容非常特殊,所以最后得到的SQL命令变成:

“select * from users where username = 'aa' or 1=1 andpassword = '1234' or 1=1”

服务器执行查询或存储过程,将用户输入的身份信息和数据库users表中真实的身份信息进行核对,由于SQL命令实际上已被修改,存在永远成立的1=1条件,因此已经不能真正验证用户身份,所以系统会错误地授权攻击者访问。

SQL 注入是通过目标服务器的80端口进行的,是正常的Web访问,防火墙不会对这种攻击发出警告或拦截。当Web服务器以普通用户的身份访问数据库时,利用SQL注入漏洞就可能进行创建、删除、修改数据库中所有数据的非法操作。而当数据库以管理用户权限的身份进行登录时,就可能控制整个数据库服务器。

SQL注入的方法很多,在以手动方式进行攻击时需要构造各种各样的SQL语句,所以一般攻击者需要丰富的经验和耐心,才能绕过检测和处理,提交语句,从而获得想要的有用信息。这个过程需要花费很多的时间,如果以这种手动方式进行SQL注入漏洞攻击,许多存在SQL注入漏洞的ASP、JSP、PHP、JAVA等网站就会安全很多了,不是漏洞不存在了,而是手动入侵者需要编程基础,但现在攻击者可以利用一些现成的黑客工具来辅助SQL注入漏洞攻击,加快入侵的速度,使SQL注入变得轻而易举。

由于SQL注入漏洞攻击利用的是通用的SQL语法,使得这种攻击具有广泛性。理论上说,对于所有基于SQL语言的数据库管理系统都是有效的,包括MSSQLServer、Oracle、DB2、Sybase和MySQL等。当然,各种系统自身的SQL扩展功能会有所不同,因此最终的攻击代码可能不尽相同。

1. 3 SQL注入漏洞攻击过程

(1)绕过身份验证

如一个login界面,需要输入用户名和口令,然后Post到另一个页面,进行身份验证,因此攻击者只需在用户名和口令的输入框中都输入aa or’1’=’1’的内容,那么攻击者就可以通过欺骗的验证方式而直接进入下一个页面,并拥有和正常登录用户一样的全部特权。原因是什么呢? 我们比较一下正常用户登录和攻击者登录时的两种SQL语句:

1)正常用户(如用户名为admin,口令为1234567) :

SQL= " selectfrom users where username = ’admin’and password= ’1234567’ ";

2)攻击者(用户名和口令都为aa or’1’=’1’) :

SQL= " select * from users where username='aa or’1’=’1’'and password = ' aa or’1’=’1’'";

可以看到由and连接的两个条件都被一个永远成立的1=1所代替,执行的结果为true,数据库会认为条件恒成立,会返回一个true,让攻击者以合法身份登录进入下一个页面。

(2)执行非法操作

如一个查询页面select1.asp? id=1,编程人员原本设计意图是显示id为1的查询信息,而攻击者利用程序中没有对id内容进行检查的机制,插入自己的代码。

从select1.asp中摘录一段关键代码:

SQL= " select *from photo where photoid= 'id'";

可以看到,id没有进行任何的处理,直接构成SQL语句并执行,而攻击者在知道该系统数据库中表名及字段名的情况下,利用SQL语句特性(分号是将两句SQL 语句分开的符号),直接向数据库Tuser表中添加记录:

select1.asp? id= 1;Insertinto Tuser (username,password,type) values ('hack','1234567','管理员'),然后攻击者就可以直接用hack进行登录了。通过这样的方法,攻击者还可以对系统做任何的事情,包括添加、删除、修改系统资源的操作。

(3)执行系统命令

如果Web主机使用MSSQL数据库管理系统,那么攻击者就可以用到xp_cmdshell这个扩展存储过程,xp_cmdshell是一个非常有用的扩展存储过程,用于执行系统命令,比如dir、net等,攻击者可以根据程序的不同,提交不同的语句:

execmaster.dbo.xp_cmdshell " dir "; exec master.dbo.xp_cmdshell" net user hack 1234567 /add ";

execmaster.dbo.xp_cmdshell " net localgroup administrators hack /add ";

这样就可以向Web主机系统中成功添加了一个管理员帐户。

2. SQL注入漏洞攻击的检测方式及方法

2. 1检测方式

SQL注入漏洞攻击检测分为入侵前的检测和入侵后的检测。入侵前的检测,可以通过手工方式,也可以使用SQL注入漏洞扫描工具软件。检测的目的是为预防SQL注入漏洞攻击,而对于SQL注入漏洞攻击后的检测,主要是针对审计日志的查看,SQL注入漏洞攻击成功后,会在Web Service和数据库的审计日志中留下“痕迹”。

2. 2检测方法

(1)动态SQL检查

动态的SQL语句是一个进行数据库查询的强大的工具,但把它和用户输入混合在一起就使SQL注入成为了可能。将动态的SQL语句替换成预编译的SQL或者存储过程对大多数应用程序是可行的。预编译的SQL或者存储过程可以将用户的输入作为参数而不是命令来执行,这样就限制了入侵者的行动。当然,它不适用于存储过程中利用用户输入来生成SQL命令的情况。在这种情况下,用户输入的SQL命令仍可能得到执行,数据库仍然存在SQL注入漏洞攻击的危险。

(2)有效性校验

如果一个输入框只可能包括数字,那么要通过验证确保用户输入的都是数字。如果可以接受字母,检查是不是存在不可接受的字符,那就需要设置字符串检查功能。确保应用程序要检查以下字符:分号、等号、破折号、括号以及SQL关键字。

(3)数据表检查

使用SQL注入漏洞攻击工具软件进行SQL注入漏洞攻击后,都会在数据库中生成一些临时表。通过查看数据库中最近新建的表的结构和内容,可以判断是否曾经发生过SQL注入漏洞攻击。

(4)审计日志检查

在Web服务器中如果启用了审计日志功能,则Web Service审计日志会记录访问者的IP地址、访问时间、访问文件等信息,SQL注入漏洞攻击往往会大量访问某一个页面文件(存在SQL注入点的动态网页),审计日志文件会急剧增加,通过查看审计日志文件的大小以及审计日志文件中的内容,可以判断是否发生过SQL注入漏洞攻击事件;另外还可以通过查看数据库审计日志,查询某个时间段是否有非法的插入、修改、删除操作。

(5)其他

SQL注入漏洞攻击成功后,入侵者往往会添加特权用户(如:administrator、root、sa等)、开放非法的远程服务以及安装木马后门程序等,可以通过查看用户帐户列表、远程服务开启情况、系统最近日期产生的一些文件等信息来判断是否发生过入侵。

3. SQL注入漏洞防范措施

SQL注入漏洞攻击的防范方法有很多种,现阶段总结起来有以下方法:

(1)数据有效性校验。如果一个输入框只可能包括数字,那么要通过校验确保用户输入的都是数字。如果可以接受字母,那就要检查是不是存在不可接受的字符,最好的方法是增加字符复杂度自动验证功能。确保应用程序要检查以下字符:分号、等号、破折号、括号以及SQL关键字。另外限制表单数据输入和查询字符串输入的长度也是一个好方法。如果用户的登录名最多只有10个字符,那么不要认可表单中输入10个以上的字符,这将大大增加攻击者在SQL命令中插入有害代码的难度。

(2)封装数据信息。对客户端提交的数据进行封装,不要将数据直接存入cookie中,方法就是在编程的代码中,插入session、if、try、else,这样可以有效地防止攻击者获取cookie中的重要信息。

(3)去除代码中的敏感信息。将在代码中存在的用户名、口令信息等敏感字段删除,替换成输入框。

SQL=" select from users where username = ’admin’and password= ’1234567’ "

如:这样显然会暴露管理员的用户名、口令信息。可以将其修改成:

SQL= " select * from users where username='" +Txtuser.Text + "' and userpwd='" + Textpwd.Text + "'"

这样就安全了很多,入侵者也是不会轻易的就获取到用户名、口令信息。

(4)替换或删除单引号。使用双引号替换掉所有用户输入的单引号,这个简单的预防措施将在很大程度上预防SQL注入漏洞攻击,单引号时常会无法约束插入数据的Value,可能给予输入者不必要的权限。用双引号替换掉单引号可以使大部分SQL注入漏洞攻击失败。 如:

“select* from users where username='" + admin + "' and userpwd='" + 1234567+ "'”

显然会得到与

“select * from users where username='admin' and password= '1234567'”

相同的结果。

(5)指定错误返回页面。攻击者有时从客户端尝试提交有害代码和攻击字符串,根据Web Service给出的错误提示信息来收集程序及服务器的信息,从而获取想得到的资料。应在Web Service中指定一个不包含任何信息的错误提示页面。

(6)限制SQL字符串连接的配置文件。使用SQL变量,因为变量不是可以执行的脚本,即在Web页面中将连接数据库的SQL字符串替换成指定的Value,然后将Web.config文件进行加密,拒绝访问。

(7)设置Web目录的访问权限。将虚拟站点的文件目录禁止游客用户(如:Guest用户等)访问,将User用户权限修改成只读权限,切勿将管理权限的用户添加到访问列表。

(8)最小服务原则。Web服务器应以最小权限进行配置,只提供Web服务,这样可以有效地阻止系统的危险命令,如ftp、cmd、vbscript等。

(9)鉴别信息加密存储。将保存在数据库users表中的用户名、口令信息以密文形式保存,也可以对users表进行加密处理,这样可以大大增加对鉴别信息访问的安全级别。

(10)用户权限分离。应尽可能的禁止或删除数据库中sa权限用户的访问,对不同的数据库划分不同的用户权限,这样不同的用户只能对授权给自己的数据库执行查询、插入、更新、删除操作,就可以防止不同用户对非授权的数据库进行访问。

4. 结束语

SQL注入漏洞攻击在网上非常普遍,许多ASP、PHP论坛和文章管理系统、下载系统以及新闻系统都存在这个漏洞。造成SQL注入漏洞攻击的主要原因是开发人员在系统开发的过程中编程不规范,没有形成良好的编程习惯,问题的解决只有依赖于规范编程。此外,也可以使用现有的SQL注入漏洞扫描器对整个网站中的关键代码进行扫描,查找网站页面中存在的SQL注入点。对于有问题的页面,可以及时删除或更新。本文通过对SQL注入漏洞攻击的方法、原理以及攻击实施过程进行了阐述和总结,并给出了一些常见的SQL注入漏洞攻击防范的方法。

0条大神的评论

发表评论