Web框架下安全漏洞的测试反思

发表于:2019-3-07 13:04  作者:王婷英   来源:掘金

字体: | 上一篇 | 下一篇 |我要投稿 | 推荐标签: 安全测试

  在平时的测试中,一般情况下,我们都是比较关注功能业务测试,以及对应的接口测试,很少去关注对应的业务设计上存在的安全漏洞测试分析。随着行业对安全的要求越来越高,同时我们电商是经常在网络上发生交易操作的网站,更是要关注安全测试相关的测试场景的考虑。
  之所以来编写这篇web的里的安全测试的文章,主要是在平时的测试过程中,发现了我们的考拉网站上存在一些安全性的漏洞。一部分的安全漏洞不会公司带来资损,但是还有一部分的安全性漏洞会对公司造成一定的资损,这样子的安全性的漏洞更应该被重视,那么安全性的测试也更应该被重视起来。
  简单罗列目前发现的安全性问题:
  用户购买会员的金额可以通过修改请求里的金额,进行购买--------根本原因:后端的代码没有将拿到的用户的金额和实际的金额进行对比,再去发出下一步的支付流程。
  对订单进行评论的获取考拉豆的时候,可以通过变更URL上的orderID来进行变更,从而将别人的订单进行评价,而获取别人的考拉豆---根本原因:后端没有对订单的所属进行判断,只是核对该订单是否存在.
  下面详细的说明几种常见的漏洞:
  1、通过修改请求里的Response参数
  实名认证这里的请求:https://m.kaola.com/member/activity/valid/nameAuth.html,只需将请求里Response里的code修改为:unknown200,以及将success的值修改为true,然后将这个请求发出去之后,我们的刷子用户就可以成功的绕过这个围墙了,去购买参加我们的试用会员了,从而可以享受我们的7天的会员96折的价格
  2、修改URL上的参数,操作不属于自己的订单信息(越权)
  这个是通过修改URL上的订单参数,可以查看别人的订单信息,以及物流状况,以及对订单进行申请售后等操作。
  这个也是对订单进行变更,对别人的订单进行评价,来收获别人的订单的返考拉豆
  通过修改URL链接上的参数来进行一些非对应账号的信息的查看和操作,从安全的角度来看是没有进行隐私保护操作。甚至会带来一些客户投诉,更加严重的是,用户对我们的产品失去信任,不再使用。这些不应该是是开发人员去思考的,更应该是QA在平时的需求测试中进行关注的地方。
  有人说,修改订单号,怎么可能,别人怎么知道我们的订单号生成的规律。其实我们认真的分析我们的订单号,还是可以找到一定的规律
  如:gid=201712102237GORDER36432705---在GORDER前面的是我们的订单生成的年月日,后面是8位流水号,其实真的要去操作,还是在一定程度上可以修改URL的参数。
  3、本应该是post请求,硬是设计成get请求
  为加强QA对功能业务重视的情况下,同时也要在平时的业务测试的过程中重视安全性相关方面的测试,为了更好的在测试过程中养成敏锐的观察能力。首先web需要了解下,Web的相关节点,浏览器、http请求、中间件、数据库等之间的关系。
  在数据的传输中,我们可以把 web 简单的分为几个层次:
  1.浏览器:浏览器即客户端,提供客户端和服务器端的数据信息交互。
  2.http:客户端与web服务器进行交互时就存在web请求,这种请求都基于统一的应用层协议——HTTP协议来交互数据。http属于轻量级协议,无需连接,提供了对通信错误的容错性(常见的3次握手)。
  3.中间件:中间件是位于平台(硬件和操作系统)和应用之间的通用服务
  4.Server容器:Server容器负责解析用户请求和脚本语言,类似的有Tomcat,JBoss等。我们访问网页看到是web容器处理后的内容。
  5.数据库:动态页面可提供交互式的信息查询服务,主要依赖于web数据库的实现,对外提供包含表单的Web页面作为访问接口,查询结果也以包含数据列表的Web页面形式返回给用户。
  那么针对上面的一些问题,我们应该怎么去避免呢?如上面的越权的信息,实际上是没有对当前的cookie进行验证,以致可以通过修改URL上的参数就能操作别人的订单信息。
  对敏感数据存在的接口和页面做cookie,ssid,token或者其它验证,如下图所示:
  其实,还有很多安全方面的测试,如cookie里不应该暴露比较敏感的信息等等。
  结束语:
   这些安全的漏洞的根本的来源是开发设计逻辑存在缺陷,于是给我们的黑客存在可利用的空间。在平常的业务测试中,我们不可能要求开发设计逻辑能面面俱到,也不可能发现所有的逻辑缺陷,这些缺陷给我们带来的伤害其实是巨大的。如用户的验证码被爆破、会员手机号被遍历、抽奖次数本地被修改、跳过手机短信验证修改他人密码、登陆等接口返回用户密码等信息、签到逻辑不严,导致薅羊毛等等问题,都会给我们的产品打上一个不好的标签。因此,功能QA不仅子在乎开发的需求是否满足交互稿的同时,而且也要考虑下各种安全的场景测试,在一定程度上规避安全漏洞被不法用户使用,造成不堪后果的损失。

     上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理。

【大佬说】测试员跳槽时,如何高效地准备面试?

评 论

论坛新帖

顶部 底部


建议使用IE 6.0以上浏览器,800×600以上分辨率,法律顾问:上海瀛东律师事务所 张楠律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2019, 沪ICP备05003035号
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪公网安备 31010102002173号

51Testing官方微信

51Testing官方微博

扫一扫 测试知识全知道