昨天王先生分享给我一个案例，刚刚发生过，新鲜热乎。某电商大佬举行了一个活动，只有会员才能1999元购买飞天茅台酒，非会员不行。（买了之后往外一转手就是2800或者2500，记不清了 ==！）。问题就出在接口端没对会员身份做校验，所以被别有用心之人通过接口钻了空子，提交了无数单。给运营同学带来了很大麻烦。
还有几年前的一个案例，提现接口没对提现值做校验，输入负值也能提现，结果越提越多。这个锅前端MM是肯定不背的，人家界面上妥妥的都做了校验。
恰好，我厂A项目最近也暴出类似问题。 1： 取消订单接口没做校验，可以多次取消，导致礼品卡金额被重复退还。 2： 提交订单接口，下单时数量未校验，为负值也能提交（未造成经济损失，但被投诉）
A项目比较特殊，出问题有一定历史原因。从外包手里接过来的，而最初接手时又有新需求压过来，因此无瑕对其进行详细的接口测试，只针对功能和业务做了一轮测试。
那么聊一聊攻击者图啥呗。我觉得无外乎两点：其一，占平台便宜，贪钱；其二，恶心恶心你，尤其是竞争对手，你都这么惨了，他们不得开心一礼拜呀。
啥叫API渗透性测试呢？
就是站在攻击者的角度，站在占平台便宜，给平台造成经济或名誉损失的角度进行测试。看接口是否有必要的校验。
怎么测呢？
工具不限，抓包像fiddler charles都没问题，接口测试postman jmeter都可以。那么，其实最重要的就是思维。举个例子：
从单品页提交订单接口，入参如下：
store_id=10
spec_key=530_1186
shipping_code=shunfeng
concent_type=1？
invoice_title=1
goods_price=0.05
gift_id=
goods_id=138
token=a6a98a31-7955-4d60-af44-e49b66db171e
addressId=26
goods_num=1
invoice_type=1
shipping_name=%E9%A1%BA%E4%B8%B0%E7%89%A9%E6%B5%81
可以设计测试场景如：
商品个数改成空、0、负数、大于库存
篡改店铺或商品id或spec_key
将商品价格改低
优惠券跨商品、跨店铺、跨用户、跨时间使用时是否有校验（比如500的优惠券只能在1万元以上的商品使用，而将商品id改成一个501元的商品，结果也能下单成功，造成1元钱购买了501元的商品）
同理，
礼品卡id改成其他用户的/无效的/已使用的/已过期的/已冻结的/未到使用时间的
至此，才算是对这个接口设计完了用例（未考虑业务层面的用例）。当然，每个人的思维都有疏漏之处。负责A项目的测试同学在设计完购物流的渗透性测试点后，我和自动化测试同学都进行了补充。然而，在给其他测试小伙伴们分享时，又得到了很多的补充。可见，人多力量大呀。一定要充分抓住身边的资源，互相帮助！给我的小伙伴点赞。
A项目的两次事故也算是件好事。给我们带来了新的测试思路，也引起了大家的重视。A项目的测试同学又测出了若干漏洞。比如，可以越权确认收货、越权删除订单、越权评价订单、越权查看发票或物流等等。 你说，攻击者做这些事能得到啥实质性的好处吗？很显然不能。也就图个乐呵吧。
罗里吧嗦说了不少，总结一下子。
如果想做好接口测试，仅仅测业务是不够的。应该从攻击者的角度考虑到尽可能多的场景，避免给平台带来经济和名誉上的损失。这也是QA团队的天职！！
最近呀，听云层讲课说了一个观点。“一线互联网公司都在研究去QA，为啥呢？我招一个测试也不少花钱，而且还不能从根源上解决问题，毕竟代码不是他编写的。那我为什么不直接把招QA的钱给平均到两个开发身上呢，一人涨5000块钱怎么样？ 然后测试谁来做？用户啊。我灰度上线，先开放给一部分用户，让他们进行测试，我将问题修改好迭代几次没有问题了再开放给所有用户，这样不香吗？”
恩。QA团队，且行且珍惜吧。
点赞文章的，都变美了，变帅了，升职了，加薪了
