从接口测试来说,传入参数,预期删除,似乎也没有问题。。 文章源自玩技e族-https://www.playezu.com/180580.html
- 版权提示:本站仅供存储任何法律责任由作者承担▷诈骗举报◁▷新闻不符◁▷我要投稿◁
免责声明:内容来自用户上传发布或新闻客户端自媒体如有侵权请反馈站长处理 - 原创转载:阅读转载说明>>> https://www.playezu.com/180580.html
从接口测试来说,传入参数,预期删除,似乎也没有问题。。 文章源自玩技e族-https://www.playezu.com/180580.html
未知地区 1F
是 bug,既然前端都做了删除禁用,业务逻辑上当然是不能删除订单的,后端也要保持一致,只是后端没有去做这样的校验而已。健康的系统是必须前后端都做好校验的,可以反馈给开发,看他改不改,正常来说改一下也没有多大难度。如果是内部使用的工具,他也不想改,风险可控的话,可以抛出来让研发组长之类的人去做决定,看是否需要修复。有道理,不过风险确实小,像这种没做校验的接口还有很多。。几年下来都没因为这个出过问题,所以倍感纠结 安全无小事,订单就更严重了,这种必须要改,不然出了资损测试一样背锅~
当然最可悲的不是测试没发现问题而背锅,而是发现了开发不改而背的锅,到时候说你不坚持、没立场……是 bug,这个是业务规则漏洞。前后端应该要保持一致。
没出问题 != 没有问题,不知道你这里具体业务场景是啥,但既然不允许删除订单,那应该是业务规则是基于此时订单无法删除来设计的。那如果此时实际出现了订单删除,我理解你其它业务逻辑也可能会跟着一起出错,甚至连整个帐一起出错,到时候修起来就非常累了。
当然一步到位全部发现全部改好很难,可以按安全风险一批一批检查和修改,但这个风险要明确暴露出来,让项目团队明确知道,并进行评估决策。资损分析中的一点。这个就要看需求了。服务端逻辑和前端逻辑是应该保持一致的,这种也是安全问题,可以篡改安全漏洞:越权修改要看,比如你们接口都是 rsa 加密的,我觉得也没什么大问题