此文已由作者王婷英授权网易云社区发布。
欢迎访问，了解更多网易技术产品运营经验。
在平时的测试中，一般情况下，我们都是比较关注功能业务测试，以及对应的接口测试，很少去关注对应的业务设计上存在的安全漏洞测试分析。随着行业对安全的要求越来越高，同时我们电商是经常在网络上发生交易操作的网站，更是要关注安全测试相关的测试场景的考虑。
之所以来编写这篇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 简单的分为几个层次：
浏览器：浏览器即客户端，提供客户端和服务器端的数据信息交互。
http：客户端与web服务器进行交互时就存在web请求，这种请求都基于统一的应用层协议——HTTP协议来交互数据。http属于轻量级协议，无需连接，提供了对通信错误的容错性（常见的3次握手）。
中间件：中间件是位于平台（硬件和操作系统）和应用之间的通用服务
Server容器：Server容器负责解析用户请求和脚本语言，类似的有Tomcat，JBoss等。我们访问网页看到是web容器处理后的内容。
数据库：动态页面可提供交互式的信息查询服务，主要依赖于web数据库的实现，对外提供包含表单的Web页面作为访问接口，查询结果也以包含数据列表的Web页面形式返回给用户。
那么针对上面的一些问题，我们应该怎么去避免呢？如上面的越权的信息，实际上是没有对当前的cookie进行验证，以致可以通过修改URL上的参数就能操作别人的订单信息。
对敏感数据存在的接口和页面做cookie，ssid，token或者其它验证，如下图所示：
结束语：
这些安全的漏洞的根本的来源是开发设计逻辑存在缺陷，于是给我们的黑客存在可利用的空间。在平常的业务测试中，我们不可能要求开发设计逻辑能面面俱到，也不可能发现所有的逻辑缺陷，这些缺陷给我们带来的伤害其实是巨大的。如用户的验证码被爆破、会员手机号被遍历、抽奖次数本地被修改、跳过手机短信验证修改他人密码、登陆等接口返回用户密码等信息、签到逻辑不严，导致薅羊毛等等问题，都会给我们的产品打上一个不好的标签。因此，功能QA不仅子在乎开发的需求是否满足交互稿的同时，而且也要考虑下各种安全的场景测试，在一定程度上规避安全漏洞被不法用户使用，造成不堪后果的损失。
网易云，0成本体验20+款云产品！
更多网易技术、产品、运营经验分享请。
相关文章：
【推荐】