我是HullQin,公众号线下聚会游戏的作者(欢迎关注公众号,发送加微信,交个朋友),转发本文前需获得作者HullQin授权。我独立开发了《联机桌游合集》,是个网页,可以很方便的跟朋友联机玩斗地主、五子棋等游戏,不收费没广告。还开发了《Dice Crush》参加Game Jam 2022。喜欢可以关注我 HullQin 噢~我有空了会分享做游戏的相关技术。
众所周知,掘金里有「专栏」,比如我有这些专栏:HullQin的专栏 - 掘金。大家点开这个链接,展示了我所有的专栏:
你可以点击「+ 关注」按钮,看看会发生什么?
没错,点击后,如果你已登陆掘金,那么按钮就变成了「已关注」,表明你关注了我的专栏,我要对你说一声:“听我说,谢谢你,因为有你……”。
作者打开自己的专栏列表和专栏详情,没有「+ 关注」按钮。不信?你自己创建一个专栏试试。
比如我打开我的专栏列表,「+ 关注」按钮的位置变成了菜单「…」按钮,并不能关注我自己的专栏,展示如图:
掘金的前端交互,体现了掘金的产品诉求:作者不能关注自己的专栏。
我突发奇想,前端只是没有把「关注专栏」这个入口给作者展现出来,后端是否有做这个校验逻辑(作者不能关注自己的专栏)呢?
验证方法也很简单。使用我们之前文章讲过的类似「重放攻击」的做法:《遇到表格,手动翻页太麻烦?我教你写脚本,一页展示所有数据》,我在文中提到:
Chrome最方便的一点是,可以直接
Copy as fetch
,点击后,就可以复制这个请求的fetch版本,做「重放攻击」也太方便啦,Chrome的贴心功能真是太刑啦!
我们还是打开这个网页HullQin的专栏 - 掘金,关注一下任意专栏,通过浏览器的开发者工具Network(网络)面板,找到对应的「关注专栏」的请求,复制一下,得到:
fetch("https://api.juejin.cn/interact_api/v1/follow/do?aid=改成你的aid&uuid=改成你的uuid", {
"headers": { "content-type": "application/json" },
"referrer": "https://juejin.cn/",
"referrerPolicy": "strict-origin-when-cross-origin",
"body": "{\"id\":\"7087844977169924109\",\"type\":24}",
"method": "POST",
"mode": "cors",
"credentials": "include"
});
然后,把body
参数里的id
改成自己的专栏id。
自己专栏id怎么看?在这里:juejin.cn/column/7106457452832358407,专栏的详情页,网址中的拿那串数字就是专栏ID。
改好参数,按照上述文章教的,在Console中,执行这个fetch
函数,会发现:服务器返回success,没有报错!再点开专栏详情,发现粉丝中增加了自己!
也就是说,掘金的前端开发者确实按照产品诉求实现了该功能:作者不能关注自己的专栏。但是后端开发者针对「关注专栏」这个API并没有做校验。
通过调用API,作者还是可以关注自己的专栏,从而给自己的专栏增加1个粉丝!
(如果产品确认逻辑是:作者不可关注自己的专栏,)后续有至少3件事情要做:
(如果产品确认逻辑是:允许作者通过API关注自己的专栏,不允许通过界面操作关注,)后续就什么都不用做啦,这不是什么严重的bug。(毕竟作者也是可以给自己的文章点赞的,关注下自己专栏没什么毛病)
这是一个典型的系统漏洞:产品功能只在前端做校验、而没有在后端做校验。这是我们在做产品的时候需要避免的。如何避免呢?多方人员需要共同努力:
我是HullQin,公众号线下聚会游戏的作者(欢迎关注公众号,发送加微信,交个朋友),转发本文前需获得作者HullQin授权。我独立开发了《联机桌游合集》,是个网页,可以很方便的跟朋友联机玩斗地主、五子棋等游戏,不收费没广告。还开发了《Dice Crush》参加Game Jam 2022。喜欢可以关注我 HullQin 噢~我有空了会分享做游戏的相关技术。