产品描述

服务人工 漏洞检测项目所有 优势解决不掉 APP漏洞检测支持 服务地区全国

SINE安全对网站漏洞检测具有的安全技术人员,而且完全不依靠软件去扫描,所有漏洞检测服务都是由我们人工去检测,比如对代码进行审计,以及都每个网站或APP的功能进行单独的详细测试,如跨权限漏洞,支付漏洞绕过,订单价格被篡改,或订单支付状态之类的,或会员找回密码这里被强制找回等,还有一些逻辑漏洞,上传漏洞,垂直权限漏洞等等。
讨论回顾完上次整改的问题之后,理清了思路。然后我登录了网站查看一下原因,因为网站只有一个上传图片的地方,我进行抓包尝试,使用了repeater重放包之后,发现返回包确实没有返回文档上传路径,然后我又尝试了各种绕过,结果都不行。后苦思冥想得不到结果,然后去问一下这个云平台给他们提供的这个告警是什么原因。看了云平台反馈的结果里面查杀到有图片码,这个问题不大,上传文档没有执行权限,而且没有返回文档路径,还对文档名做了随机更改,但是为啥会有这个jsp上传成功了,这让我百思不得其解。
当我仔细云平台提供的发现webshel数据的时候,我细心的观察到了文档名使用了base编码,这个我很疑惑,都做了随机函数了还做编码干嘛,上次测试的时候是没有做编码的。我突然想到了问题关键,然后使用burpsuite的decoder模块,将文档名“1jsp”做了base编码成“MS5Kc1A=”,然后发送成功反馈状态码200,再不是这个上传失败反馈500状态码报错了。
所以,这个问题所在是,在整改过程中研发人员对这个文档名使用了base编码,导致文档名在存储过程中会使用base解析,而我上传文档的时候将这个后缀名.jsp也做了这个base编码,在存储过程中.jsp也被成功解析,研发没有对解析之后进行白名单限制。其实这种编码的更改是不必要的,毕竟原来已经做了随机数更改了文档名了,再做编码有点画蛇添足了,这就是为啥程序bug改一个引发更多的bug原因。
合肥网站漏洞检测服务
接下来还得检测网站的各项功能以及APP功能是否存在逻辑漏洞,越权漏洞,水平垂直等等,我们SINE安全技术详细的对每一个功能都测试很多遍,一次,两次,多次的反复进行,在用户重置密码功能这里发现有漏洞,正常功能代码设计是这样的流程,首先会判断用户的账号是否存在,以及下一步用户的是否与数据库里的一致,这里简单地做了一下安全校验,但是在获取验证码的时候并没有做安全校验,导致可以post数据包,将为任意来获取验证码,利用验证码来重置密码。
合肥网站漏洞检测服务
其实从开发的角度,如果要保证代码至少在逻辑方面没有明显的漏洞,还是有些繁琐的。举个简单的例子,如网站的数据检验功能,不允许前端提交不符合当前要求规范的数据(比如年龄文本框部分不能提交字母)。那么为了实现这个功能,首先开发者肯定要在前端实现该功能,直接在前端阻止用户提交不符规范的数据,否则用户体验会很差,且占用服务器端的资源。
但是没有安全意识或觉得麻烦的开发者就会仅仅在前端用Js进行校验,后端没有重复进行校验。这样就很容易给恶意用户机会:比如不通过前端页面,直接向后端接口发送数据:或者,前端代码编写不规范,用户可以直接在浏览器控制台中用自己写的Js代码覆盖原有的Js代码;或者,用户还可以直接在浏览器中禁用Js;等等。总之,前端的传过来的数据可信度基本上可以认为比较低,太容易被利用了。
而我的思路都是很简单的,就是关注比较重要的几个节点,看看有没有可乘之机。如登录、权限判定、数据加载等前后,对方是怎么做的,用了什么样的技术,有没有留下很明显的漏洞可以让我利用。像这两个网站,加载的Js文档都没有进行混淆,注释也都留着,还写得很详细。比较凑巧的是,这两个网站都用到了比较多的前端的技术,也都用到了sessionStorage。
合肥网站漏洞检测服务
应对措施:文档上传的绕过方法网上一搜有很多(比如upload-labs的各种方法、绕防火墙的各种方法(虽然很多已经过时),可能还有些没有公开的方法,总结一下:1.常规的绕过方法:文档后缀(大小写、文档别名等等)、文档名(文档名加分号、引号等等)、文档内容(比如图片马)、请求包结构等等。
2.结合服务器解析漏洞:IIS、apache、nginx的特定版本都有对应的解析漏洞。3.利用文档包含漏洞:如果有文档包含漏洞,可以结合文档包含漏洞,上传马。4.利用组件漏洞:如果知道组件版本和名称,可以网上找一下相应漏洞。注:手动一个一个去试各种方法,的确很麻烦,可以试试burpsuit的上传插件upload-scanner(但本人觉得并不好用)。
SINE安全网站漏洞检测时必须要人工去审计漏洞和查找漏洞找出问题所在并修复漏洞,对各项功能都进行了全面的安全检测。
http://www.qdshtddzkj.com

产品推荐