初识安全测试(一)

————————————————————————————————————————————————————————————————————————

百度知识:

一、概念:安全测试是在IT软件产品的生命周期中,特别是产品开发基本完成到发布阶段,对产品进行检验以验证产品符合安全需求定义和产品质量标准的过程 。

二、目的:

  1. 提升IT产品的安全质量;
  2. 尽量在发布前找到安全问题予以修补降低成本 ;
  3. 度量安全。
  4. 验证安装在系统内的保护机制能否在实际应用中对系统进行保护,使之不被非法入侵,不受各种因素的干扰。
三、方法: 
 1.模式匹配方法:将程序看作字符串
  2.状态机模型:将程序看作状态机
  3.黑盒模型:将程序看作黑盒子
  4.白盒模型:将程序看作路径的组合
四、困境:
  
  1.测试理论很难适用于安全领域;
  2.安全测试基础理论薄弱,当前测试方法缺少理论指导,也缺乏技术产品工具 。
 
五、相关区别:
  1. 与通常测试区别
  1)目标不同:测试以发现BUG为目标,安全测试以发现安全隐患为目标。
  2)假设条件不同:测试假设导致问题的数据是用户不小心造成的,接口一般只考虑用户界面。安全测试假设导致问题的数据是攻击者处心积虑构造的,需要考虑所有可能的攻击途径。
  3)思考域不同:测试以系统所具有的功能为思考域。安全测试的思考域不但包括系统的功能,还有系统的机制、外部环境、应用与数据自身安全风险与安全属性等。
  4)问题发现模式不同:测试以违反功能定义为判断依据。安全测试以违反权限与能力的约束为判断依据。
 
  2. 与渗透测试区别
  1)出发点差异:渗透测试是以成功入侵系统,证明系统存在安全问题为出发点;而安全测试则是以发现系统所有可能的安全隐患为出发点。
  2)视角差异:渗透测试是以攻击者的角度来看待和思考问题,安全测试则是站在防护者角度思考问题,尽量发现所有可能被攻击者利用的安全隐患,并指导其进行修复。
  3)覆盖性差异:渗透测试只选取几个点作为测试的目标,而安全测试是在分析系统架构并找出系统所有可能的攻击界面后进行的具有完备性的测试。
  4)成本差异:安全测试需要对系统的功能、系统所采用的技术以及系统的架构等进行分析,所以较渗透测试需要投入更多的时间和人力。
  5)解决方案差异:渗透测试无法提供有针对性的解决方案;而安全测试会站在开发者的角度分析问题的成因,提供更有效的解决方案。
————————————————————————————————————————————————————————————————————————

关于自动化web安全测试动态fuzz的思路与实践分析(图文)

很久之前就想写这么一篇文章,来谈谈我认为的的web2.0甚至是3.0时代,web应用安全测试遇到的几个问题,以及目前知道的解决办法。发出来供大家讨论学习,算是抛砖引玉吧。
 

什么叫自动化web安全测试?这其实是一个很大的概念,因为web安全包含很多方面,比如代码审计,比如黑盒测试,甚至还有灰盒测试。还有性能测试,压力测试等等。代码审计其实也不仅仅是审计安全问题,也有审计代码质量的。目前市场的代码审计软件,商业的好像都是有代码质量检查的。我们今天其实主要还是讲fuzz测试中web应用的安全问题,也就是我理解的黑盒测试web应用安全的问题。涵盖的主要是如何用工具发现类似SQL注入,xss,命令执行,文件包含,代码注入等等一系列的安全问题。
一直以来,我们检测一个WEB应用的安全漏洞,无非就是两种手段,一种是手动加参数比如 and 1=1或者对数字型的做一些运算,-1 -2看是否参数进行了传递并且在后端数据库里正确的执行了操作,根据页面的内容变化来判读。当然还有类似|| 1=1这种的。其实都是做的一个运算。只要符合SQL标准能够正确的执行就OK了。第二种是工具,这里指的工具,更多的含义还是指webinspect,appscan,awvs这类的基于爬虫类的扫描工具。先去抓取整个网站的目录结构,然后根据爬出来的链接,测试他的动态参数。无论是上述手段的哪一种,都会有一些缺陷。第一种不适合在大批量目标的攻击,因为显然手工测试的范围有限,第二种解决了第一个手段的缺陷,可以在一个比较大的应用中,快速发现应用程序的漏洞。但是目前来说,仍然存在很多的问题。比如,现在比较大型的应用,都是采用类似前端反向代理,后端动态解析的架构。这种架构的出现,大量的使用ajax的应用,交互式连接,json接口等等。这些东西用爬虫是识别不到的。因此用类似webinspect这样的工具,根本就扫不到什么问题。前阵子看到说awvs可以做web 2.0的扫描,可以识别到ajax请求,但是我用最新版的对比测试,发现还是不行。现在解决这类的问题,貌似有很多办法,国内的我看到aiscanner号称可以用web2.0的引擎或者js引擎解决这个问题,用javascript虚拟引擎加上沙盒技术。这个我查了一些资料,包括在developerworks上也是只看到寥寥的几个介绍。我猜是不是类似用node.js运行一些东西,模仿类似XHR的方式去获取一些交互式的,ajax的链接?希望有大牛能给我指点下。
0×02 基于代理拦截的WEB FUZZ工具
当然,随着技术的发展,很早的时候就出现过一些比较好的办法,比如用代理中转的方式来获取连接,工具类似有的fiddler和burpsuite之类的。fiddler目前官方有一个比较好的插件是Ammonite,运行后如下
\
在results里,可以看到发包和收包后的过程
\
首先说说这个插件,我目前测试的情况来说,准确率是比较差的。其实他准确率差和误报率高的一个原因,是因为检测漏洞类型和检测方法都比较的简单。打一个比方,这种类似中间代理的软件,大多数都是延续这种思路的,他们在检测SQL注入的时候,一般都是要不就是取网页内容里的SQL错误关键字,要不就是根据HTTP状态码来判断。这其实在现在来说,是比较老的检测方法,更多的,在做了相关的运算后,则需要取页面长度啊,是否跳转啊这些来判断的。这里先留一个坑,等会我说基于浏览器的自动化fuzz工具的时候,会说到。
除此之外,fiddler上其实还有很多类似的插件,比如这个日本人写的
\
 
这个插件比较类似burpsuite+fuzzdb的效果
\
先是拦截请求.
\
 
讲请求发送到攻击模块
\
在burpsuite里加载fuzzdb的数据进行进行测试
 
\
\
 
可以选择fuzz的模式
\
 
也可以自己加payloads,fuzz对比里也有
 
\
设置相关的测试参数
 
\
 
点击start attack开始攻击
 
 \
 
开始攻击,攻击后的结果.
 
 \
 
看来比fiddler复杂许多是吗?呵呵。其实这里有许多选项是可调的。这个自己研究下就可以了。设置好相关的参数后,测试起来也是相对要方便很多的。
  关于主动扫描和被动扫描这个,我还想在这里多说一句,无论是burpsuite还是fiddler,这种基于代理拦截的工具其中一个缺点就是主动扫描的功能太弱。当然,现在burpsuite有一些改进,可以做一些主动扫描的事,但还是太弱。
Burpsuite和fiddler其实都是一个原理,通过代理中转拦截所有http或者https的请求,然后重放请求来测试.fiddler稍微要强大一些是可以直接监听网卡等等,可以拦截所有的网络请求,burpsuite有些场景还是不行。详细的使用功能,还是有待大家自己去测试,挖掘,我就不详细说了

posted @ 2016-10-20 15:46  猪猪宝丫  阅读(583)  评论(0编辑  收藏  举报