一、 环境准备
测试通常给的是PDF文档,动辄几百页,看起来很费劲,看文档的时间可能比解决问题的时间还长。。。所以作为需要解决问题的我们来说,最好安装AppScan,请测试人员提供类型为AppScan Scan File的文件。(图片模糊掉了URL,不影响问题分析)
二、如何分析AppScan扫描出的安全性问题
AppScan扫描出的问题会一般按照严重程度分高,危,参三种类型,高危属于必须要解决的问题;低危一般属于config配置,或IIS配置问题;低的问题,一般也可能是高,低的衍生问题,高危问题造成的衍生问题特别多,故解决问题时,建议从高至低看,并且先易后难,最常见的就是SQL盲注,以SQL盲注为例分析:
当收到测试的测试文件后,双击打开,以疫苗资审为例:
打开之后,分析和定位问题的话,就是看红框框出的几个地方,SQL盲注这个问题就是AppScan向测试网址发送了一个地址:
/Admin/Agent/PackInfo.aspx?id=61+having+1%3D1--+,此时是将id的值由61改成了61+having+1%3D1--+,就是注入了+having+1%3D1--+,程式只要能在这个地址请求的时候,提示User,并终止当前的操作,AppScan即视为这个这个问题解决,下次扫描的时候就扫描不到了。
三、高危常见问题解决方案
1.SQL盲注:
主要就是通过注入SQL的关键字,来破坏原有的查询,导致页面报错
a.看看几种常见的盲注方式:
b.解决方案
思路:过滤关键字,在global.asax文件中的Application_BeginRequest方法中校验敏感字符/字母组合,具体参考网址http://www.jb51.net/article/34671.htm,
具体文件在链接地址的SqlChecker.cs中,项目具有共性,也有特性,所以,SqlChecker.cs中的StrKeyWord,StrRegex视实际情况而定。
实际解决:从上面的几种注入分析看,都含有+字符,最简单最暴力的方法就是过滤掉+字符,如果这样与代码冲突的话,可以按照攻击的方式过滤:如过滤掉+and+,+or+,’+and+’ 等等。。。
2.SQL注入
a.看看几种常用的SQL注入方式
b.解决方案
思路:SQL注入与SQL盲注实际的攻入方式不同,但是解决思路都是通过过滤特殊字符,只是过滤的字符稍有差异。
实际解决:从以上几种注入可以看出都含有%27%3B,开始解析%27%3B是什么字符,发现注入sql的是 这个字符,在vs里面过滤掉 这个字符即可。
备注:SQL注入的方式很多,这只是其中的一种,还有其它的种类,比如下图,要具体问题具体分析:
3.基于跨站点的编制
思路与1,2相同,解决方法也是根据测试的结果过滤掉特殊字符。
4.已解密的登录请求
解决方案:安装SSL协议,或其它安全加密协议。
5.ASP.NET表单认证旁路
思路:这个问题看起来很高大上,高大上到上网查都没查到解决方案,看着这个报错也是想了很久。。。。现在我们看下这个问题的相关信息
a.首先是问题信息:原始响应与测试响应对比,测试响应的Cookie中少了ASP.NET_SessionId,就是测试响应除去了cookie”ASP.NET_SessionId”(变体标识675),故猜测可能禁止修改客户端修改此cookie就可以了,在global文件中加了句代码,开始测试。
b.a的方法测试结果是问题仍然存在,于是看了下修订建议,判断此建议并不可行,因为四川九个系统都部署在一个服务器上,如果是环境问题造成的漏洞,那应该是九个报告都有。。。但是,这个问题仅仅出现在两份报告里面。
c.最后看”请求/响应”页(第一幅图),将GET 后面的地址放到浏览器中测试,地址如下:
这个地址路径在项目中并不存在,所以理论上应该报404的错误,但是打开F12查看,发现实际的状态是200,这说明有可能是StatusCode错误造成的问题,如果是这个问题的话,只需要在跳转的界面中将状态修改成404即可。基于这样的写法,我们开始找跳转的地方,发现是在Application_Error方法中(第二幅图),于是去设定跳转界面的StatusCode:HttpContext.Current.Response.StatusCode = 404;(第三幅图),再次测试,问题解决。
实际解决:在跳转的最终页面设定StatusCode。