WEB十大安全隐患
OWASP风险评估方法
A1-注入
注入往往是应用程序缺少对输入进行安全性检查所引起的,攻击者把一些包含指令的数据发送给解释器,解释器会把收到的数据转换成指令执行。常见的注入包括SQL注入,OS Shell,LDAP,Xpath,Hibernate等等,而其中SQL注入尤为常见。这种攻击所造成的后果往往很大,一般整个数据库的信息都能被读取或篡改,通过SQL注入,攻击者甚至能够获得更多的包括管理员的权限。
防范SQL注入——编程篇
SQL注入往往是在程序员编写包含用户输入的动态数据库查询时产生的,但其实防范SQL注入的方法非常简单。程序员只要a)不再写动态查询,或b)防止用户输入包含能够破坏查询逻辑的恶意SQL语句,就能够防范SQL注入。在这篇文章中,我们将会说明一些非常简单的防止SQL注入的方法。
在以上代码中,我们可以看到并未对变量customerName做验证,customerName的值可以直接附在query语句的后面传送到数据库执行,则攻击者可以将任意的sql语句注入。
防范方法1:参数化查询
参数化查询是所有开发人员在做数据库查询时首先需要学习的,参数化查询迫使所有开发者首先要定义好所有的SQL代码,然后再将每个参数逐个传入,这种编码风格就能够让数据库辨明代码和数据。
参数化查询能够确保攻击者无法改变查询的内容,在下面修正过的例子中,如果攻击者输入了UsrID是“’or ‘1 ‘=’1”,参数化查询会去查找一个完全满足名字为‘or ‘1 ‘=’ 1的用户。
对于不同编程语言,有一些不同的建议:
Java EE——使用带绑定变量的PreparedStatement();
.Net——使用带绑定变量的诸如SqlCommand()或OleDbCommand()的参数化查询;
PHP——使用带强类型的参数化查询PDO(使用bindParam());
Hibernate——使用带绑定变量的createQuery()。
防范方法二:存储过程
存储过程和参数化查询的作用是一样的,唯一的不同在于存储过程是预先定义并存放在数据库中,从而被应用程序调用的。
防范方法三:对所有用户输入进行转义
我们知道每个DBMS都有一个字符转义机制来告知DBMS输入的是数据而不是代码,如果我们将所有用户的输入都进行转义,那么DBMS就不会混淆数据和代码,也就不会出现SQL注入了。
当然,如果要采用这种方法,那么你就需要对所使用的数据库转义机制,也可以使用现存的诸如OWASP ESAPI的escaping routines。ESAPI目前是基于MySQL和Oracle的转义机制
除了上面所说的三种防范方法以外,我们还建议可以用以下两种附加的方法来防范SQL 注入:最小权限法、输入验证白名单法。
最小权限法:
为了避免注入攻击对数据库造成的损害,我们可以把每个数据库用户的权限尽可能缩小,不要把DBA或管理员的权限赋予你应用程序账户,在给用户权限时是基于用户需要什么样的权限,而不是用户不需要什么样的权限。当一个用户只需要读的权限时,我们就只给他读的权限,当用户只需要一张表的部分数据时,我们宁愿另建一个视图让他访问。
如果你的策略是都是用存储过程的话,那么仅允许应用程序的账户执行这些查询,而不给他们直接访问数据库表的权限。诸如此类的最小权限法能够在很大程度上保证我们数据库的安全。
输入验证白名单法:
输入验证能够在数据传递到SQL查询前就察觉到输入是否正确合法,采用白名单而不是黑名单则能在更大程度上保证数据的合法性。
防范SQL注入——测试篇
对于测试人员来说,如何测试SQL注入漏洞是否存在呢?
首先,我们将SQL注入攻击能分为以下三种类型:
Inband:数据经由SQL代码注入的通道取出,这是最直接的一种攻击,通过SQL注入获取的信息直接反映到应用程序的Web页面上;
Out-of-band:数据通过不同于SQL代码注入的方式获得(譬如通过邮件等)
推理:这种攻击是说并没有真正的数据传输,但攻击者可以通过发送特定的请求,重组返回的结果从而得到一些信息。
不论是哪种SQL注入,攻击者都需要构造一个语法正确的SQL查询,如果应用程序对一个不正确的查询返回了一个错误消息,那么就和容易重新构造初始的查询语句的逻辑,进而也就能更容易的进行注入;如果应用程序隐藏了错误信息,那么攻击者就必须对查询逻辑进行反向工程,即我们所谓的“盲SQL注入”
黑盒测试及示例:
这个测试的第一步是理解我们的应用程序在什么时候需要访问数据库,典型的需要访问数据库的时机是:
认证表单:输入用户名和密码以检查是否有权限
搜索引擎:提交字符串以从数据库中获取相应的记录
电子商务站点:获取某类商品的价格等信息
作为测试人员,我们需要列对所有输入域的值可能用于查询的字段做一个表单,包括那些POST请求的隐含字段,然后截取查询语句并产生错误信息。第一个测试往往是用一个单引号“‘”或是分号“;”,前者在SQL中是字符串终结符,如果应用程序没有过滤,则会产生一条错误信息;后者在SQL中是一条SQL语句的终结符,同样如果没有过滤,也会产生错误信息。在Microsoft SQL Server中,返回的错误信息一般是这样:
同样可用于测试的还有“--”以及SQL中的一些诸如“AND”的关键字,通常很常见的一种测试是在要求输入为数字的输入框中输入字符串,会返回如下的错误信息:
类似上面这样的出错返回信息能让我们知道很多数据库的信息,通常不会返回那么多信息,会返回诸如“500 Server Error”的信息,那就需要“盲SQL注入”了。注意,我们需要对所有可能存在SQL注入漏洞的输入域进行测试,并且在每个测试用例时只变化一个域的值,从而才能找到真正存在漏洞的输入域。
下面我们看一下标准的SQL注入测试是怎样的。
我们以下面的SQL查询为例:
如果我们在页面上输入以下的用户名和密码:
那么整个查询语句就变为:
假设参数值是通过GET方法传递到服务器的,且域名为https://www.doczj.com/doc/7415049313.html,,那么我们的访问请求就是:
对上面的SQL语句作简单分析后我们就知道由于该语句永远为真,所以肯定会返回一些数据,在这种情况下实际上并未验证用户名和密码,并且在某些系统中,用户表的第一行记录是管理员,那这样造成的后果则更为严重。
另外一个查询的例子如下:
在这个例子中,存在两个问题,一个是括号的用法,还有一个是MD5哈希函数的用法。对于第一个问题,我们可以很容易找到缺失的右括号解决,对于第二个问题,我们可以想办法使第二个条件失效。我们在查询语句的最后加上一个注释符以表示后面的都是注释,常见的注释起始符是/*(在Oracle中是--),也就是说,我们用如下的用户名和密码:
那么整条SQL语句就变为:
我们的URL请求就变为:
Union查询SQL注入测试
还有一种测试是利用Union的,利用Union可以连接查询,从而从其他表中得到信息,假设我们有如下的查询:
然后我们设置id的值为:
那么整体的查询就变为:
显然这样就能得到所有信用卡用户的信息。
盲SQL注入测试
在上面我们提到过盲SQL注入,即blind SQL injection,它意味着对于某个操作我们得不到任何信息,通常这是由于程序员已经编写了特定的出错返回页面,从而隐藏了数据库结构的信息。
利用推理方法,有时候我们能够恢复特定字段的值。这种方法通常采用一组对服务器的布尔查询,依据返回的结果来推断结果的含义。仍然延续上面的https://www.doczj.com/doc/7415049313.html,,有一个参数名为id,那么我们输入以下url请求:
显然由于语法错误,我们会得到一个预先定义好的出错页面,假设服务器上的查询语句为SELECT field1, field2, field3 FROM Users WHERE Id='$Id',假设我们想要得到用户名字段的值,那么通过一些函数,我们就可以逐字符的读取用户名的值。在这里我们使用以下的函数:
我们定义id为:
那么最终的SQL查询语句为:
那么,如果在数据库中有用户名的第一个字符的ASCII码为97的话,那么我们就能得到一个真值,那么我们就继续寻找该用户名的下一个字符;如果没有的话,那么我们就递增猜测第一个字符的ASCII码为98的用户名,这样反复下去就能判断出合法的用户名。
那么,什么时候我们可以结束推理呢,我们假设id的值为:
其中N是我们到目前为止已经分析的字符数目,那么整体的sql查询为:
这个查询的返回值如果是真,那我们就已经完成了推理并且我们已经得到了想要的数值,如果为假,则表示我们还要继续分析。
这种盲SQL注入会要求我们输入大量的sql尝试,有一些自动化的工具能够帮我们实现,SqlDumper就是这样的一种工具,对MySQL数据库进行GET访问请求。
存储过程注入
在上一篇《如何防范SQL注入—编程篇》中,我们提到使用存储过程是能够防范SQL 注入的,但同时也要注意,存储过程如果使用不得当,使用存储过程的动态查询事实上也会造成一定的SQL注入漏洞。
以下面的SQL存储过程为例:
用户的输入如下:
如果我们没有对输入进行验证,那么上面的语句就会返回数据库中的一条记录。
我们再看下面的一条:
如果用户输入是:
后面则显而易见,用户的所有密码都被更改且得到了报表信息。
A2-跨站脚本(XSS)
排在OWASP TOP10第2位的是Cross Site Scripting(XSS),翻译成中文即“跨站脚本攻击”。它指的是恶意攻击者往Web页面里插入恶意html代码,当用户浏览该页之时,嵌入其中Web里面的html代码会被执行,从而达到恶意用户的特殊目的。XSS属于被动式的攻击,因为其被动且不好利用,所以许多人常忽略其危害性。
以下内容转自百度空间的一篇关于OWASP的文章,个人觉得基本已经把跨站脚本攻击的内容阐述的比较清楚。
如何寻找XSS漏洞,XSS攻击分成两类,一类是来自内部的攻击,主要指的是利用程序自身的漏洞,构造跨站语句,如:dvbbs的showerror.asp存在的跨站漏洞。另一类则是来来自外部的攻击,主要指的自己构造XSS跨站漏洞网页或者寻找非目标机以外的有跨站漏洞的网页。如当我们要渗透一个站点,我们自己构造一个有跨站漏洞的网页,然后构造跨站语句,通过结合其它技术,如社会工程学等,欺骗目标服务器的管理员打开,然后利用下面的技术得到一个shell。
如何利用
传统的跨站利用方式一般都是攻击者先构造一个跨站网页,然后在另一空间里放一个收集cookie的页面,接着结合其它技术让用户打开跨站页面以盗取用户的cookie,以便进一步的攻击。这种方式太过于落后,对于弊端大家可能都知道,因为即便你收集到了cookie 你也未必能进一步渗透进去,多数的cookie里面的密码都是经过加密的,如果想要cookie 欺骗的话,同样也要受到其它的条件的限约。而另一种思路,则从一定程度上解决上述的问题。比较成熟的方法是通过跨站构造一个表单,表单的内容则为利用程序的备份功能或者加管理员等功能得到一个高权限。下面将详细的介绍这种技术。
寻找跨站漏洞
如果有代码的话比较好办,我们主要看代码里对用户输入的地方和变量有没有做长度和对”<”,”>”,”;”,”?”等字符是否做过滤。还有要注意的是对于标签的闭合,像测试QQ群跨站漏洞的时候,你在标题处输入,代码是不会被执行的,因为在源代码里,有其它的标签未闭合,如少了一个,这个时候,你只要闭合一个,代码就会执行,如:你在标题处输入,这样就可以弹出一个test的框。
如何利用
跨站脚本(Cross-site scripting,XSS)漏洞是Web应用程序中最常见的漏洞之一。如果您的站点没有预防XSS漏洞的固定方法,那么就存在XSS漏洞。这个利用XSS漏洞的病毒之所以具有重要意义是因为,通常难以看到XSS漏洞的威胁,而该病毒则将其发挥得淋漓尽致。
这个利用XSS漏洞的蠕虫病毒的特别之处在于它能够自我传播。https://www.doczj.com/doc/7415049313.html,上的一个用户希望自己能够在网站的友人列表上更“受欢迎”。但是该用户不是通过普通的方法来结交新朋友,而是在自己的个人信息中添加了一些代码,导致其他人在访问他的页面时,会不知不觉地利用XSS漏洞将他加为好友。更恶劣的是,它会修改这些人的个人信息,使其他人在访问这些被感染的个人信息时,也会被感染。由于这种呈指数传播的方式,这种病毒才很快就被发现。
很难预防站点中的XSS。因此一定要认真检查您的应用程序是否存在XSS漏洞。此外,WebLogic Server的encodeXSS()也可以有所帮助。可以试着针对所有牵涉到使用encodeXSS()或其他某个筛选方法的输出找出一种编码模式——找出对一种编码模式来说不正确的应用程序往往要比找出XSS漏洞要容易的多。更重要的是,不要认为,就因为XSS漏洞是一个常见问题,所以它危害不大。
之所以出现XSS漏洞有两个原因。首先,HTML没有明确区分代码和数据。无法确定指出“这个字符串表示的是数据”。您可以将其放入引号中,但是数据是否包含引号呢?……
其次,程序在将用户数据发送回浏览器时没有进行有效的转义。这导致包含有(例如说)引号的数据被放入页面中,从而引发了问题。而AJAX要提供的好处是,它包含一个专用渠道XML链接,其中全是数据而没有代码。这样,就有可能让客户端AJAX引擎负责对字符串进行转义、检测不正确的值,等等。说是这么说,直到AJAX更为成熟(可能也更为标准化)之前,它只会导致错误的编程和安全漏洞。
XSS漏洞可能造成的后果包括窃取用户会话,窃取敏感信息,重写Web页面,重定向用户到钓鱼网站等,尤为严重的是,XSS漏洞可能使得攻击者能够安装XSS代理,从而攻击者能够观察到该网站上所有用户的行为,并能操控用户访问其他的恶意网站。
对于XSS漏洞,我们有两种常见的措施,第一种就是消除漏洞,简而言之就是在输出页面上不提供任何用户的输入信息;另外一种就是想办法来抵御这种漏洞,可以采用对所有用户的输入编码后再输出(可以用OWASP的ESAPI),也可以对所有用户输入进行“白名单”验证,另外,OWASP还提供了AntiSamy对HTML页面做优化以消除这个漏洞。
防范XSS跨站脚本攻击——测试篇
XSS也是一种对浏览器的解释器的代码注入攻击,这些攻击能够通过HTML,JavaScript,VBScript,ActiveX,Flash等其他客户端语言执行,同时,这些攻击也可能造成用户信息泄露,配置更改,cookie窃取等造成危害,甚至能够用于对Web服务器进行DOS攻击。
与大部分攻击不同的是,大部分攻击往往只涉及2方(攻击者和网站,攻击者和受害者),而XSS则涉及3方,攻击者、客户端、网站,XSS的目的就是窃取客户端的cookie或是其他信息以冒充客户在网站上进行认证,进而在网站上操作任何想进行的操作。
下面我们看看到底有哪些类型的XSS攻击:
Stored XSS(存储式跨站脚本攻击)
这是最强大的一种XSS攻击,所谓存储跨站攻击是指用户提交给Web应用程序的数据首先就被永久的保存在服务器的数据库,文件系统或其他地方,后面且未做任何编码就能显示到Web页面,最典型的就是2005年在MySpace发现的XSS漏洞以及利用该漏洞的Samy MySpace Worm。
举例,假设我们的网站允许我们给其他用户留言,但事实上我们没有留言而是写入了一段代码:
那么服务器将会存储这些信息,当用户点击我们伪造的留言时,他的浏览器就会执行我们的脚本。
Reflected XSS(反射跨站脚本攻击)
这是最常见也是最知名的XSS攻击,当Web客户端提交数据后,服务器端立刻为这个
客户生成结果页面,如果结果页面中包含未验证的客户端输入数据,那么就会允许客户端的脚本直接注入到动态页面中。传统的例子是站点搜索引擎,如果我们搜索一个包含特殊HTML 字符的字符串时,通常在返回页面上仍然会有这个字符串来告知我们搜索的是什么,如果这些返回的字符串未被编码,那么,就会存在XSS漏洞了。
初看上去,由于用户只能在自己的页面上注入代码,所以似乎这个漏洞并不严重,但是,只需一点点社会工程的方法,攻击者就能诱使用户访问一个在结果页面中注入了代码的URL,这就给了攻击者整个页面的权限。由于这种攻击往往会需要一些社会工程方法,所以研发人员往往不会太过看重,但是我们看如下的例子,在服务器上有如下代码:
这就使得浏览器每3秒就刷新一次页面,而且是一个死循环的状态,这就形成了DOS 攻击,导致Web服务器挂掉。
DOM-Based XSS(基于DOM的XSS)
这个漏洞往往存在于客户端脚本,如果一个Javascript脚本访问需要参数的URL,且需要将该信息用于写入自己的页面,且信息未被编码,那么就有可能存在这个漏洞。
黑盒测试和示例:
比较简单的测试是否存在XSS漏洞的方法是验证Web应用是否会对一个包含了HTTP响应的简单脚本的访问请求,例如,Sambar服务器(5.3)包含一个众所周知的XSS漏洞,我们向服务器发送如下的请求,从服务器端能够产生一个响应从而在Web浏览器中执行
这个脚本会在客户浏览器端被执行。
我们再举个例子:
由于Javascript是区分大小写的,有些人会尝试将所有字符转换为大写字符来避免XSS 漏洞,在这时,我们最好还是使用VBScript,因为它是大小写不区分的:
如果我们已经过滤了”<”,或者是