• 对呢,我不是说这个问题是 SQL 注入,我只是想表达如果限制了长度就不会出现这种 “数据过度暴露” 的安全问题~

  • 之前遇见过的一些安全问题,虽然问题是不太大,但确实是一个安全隐患。接口要求传参数,zbdw(int),zbdh(int)。后传入参数 zbdw=njdhs>'',zbdh='1',发送请求后,接口返回的数据把对应的实例、表,字段都暴露

  • 其实我是基于安全方面进行考虑的,当时我在写接口用例,然后我就想如果前端/后端都按数据库设计来进行的话是不是很大一个程度提高了系统的安全性(如:SQL 注入,只要对每个传参类型和长度进行校验,就能很大的把 SQL 注入难度提升一个级别。)所以我当时的理解就是所有的接口都必须做长度和类型的校验,最好和数据库设计的字段保持一致。

    但是开发人员说用另外的一种方式也能有效的解决 SQL 注入的问题,不需要在接口上对每个传参做校验。经过产品、开发和测试人员的会议沟通后我们达成了一点意见,就是重要的功能或者有必要的字段就必须做长度校验,类型校验的话在接口实现时候定义变量和数据库设计保持一致。但是问题又来了,那些接口需要我们就比较难定义,或者说什么样的接口是一定要做长度校验的呢?(既然开发人员也说有另外的方法对安全问题进行拦截,我觉得我当时考虑的问题就已经解决了)

    第二点,我们采用也是 springboot 架构。也和你说的一样,当时开发人员人为写死的话不够灵活,如果数据库字段改变后需要修改写死的地方~

    看了楼上的一位同学的说法~,我也在考虑我这样的用例设计是不是真的是过度设计了~。纠结…

  • 你的意思是,这些长度、类型我都要进行测试,但是如果程序上不出大问题就允以放行是吗

  • 哈哈,是一种工作方式。但是我是想搞懂这些东西有没有必要做,不搞懂可能对以后的工作效率有一定的影响。

  • 嗯嗯,应该和产品、开发人员进行会议讨论,但是团队还是有一些模糊的理解。比如我们都约定好,只对一些有业务修改的接口做长度的校验限制,但是那些接口需要我们就比较难定义,或者说什么样的接口是一定要做长度校验的呢?(因为我之前的认为都是所有接口都是必须做长度校验)

  • 当然在前端/客户端做校验是必须的,但我这边是考虑到接口安全性的问题,担心如果不接后端的验证会后比较多的安全问题。

  • en~,我先来解析一下第三点,这里并不是要求开发人员写代码去到数据库找到对应的字段来进行校验,其实在做数据库设计的时候设计人员就把对应的数据字段对应的长度和类型设计好,所以我的意思是要求开发人员实现接口的时候,对应的数据类型和长度要和数据库设计的保持一致。

    第二点的话,我和开发人员沟通后,他们也说是采用 validator 做简单的校验,但是如果做长度校验的话很多地方都会写死。这个他们当时也是认为太不灵活,如果用此方法,后面修改对应的字段长度的话会涉及很多地方的修改。

  • 这样的吗,因为我觉得做这两类校验对接口的安全方面有较大的保障~

  • 但我觉得接口层面做了这两个校验会把很大一部分的安全问题都拦截了啊,所以我觉得是有必要的,当然从功能层面上考虑确实是增加了开发人员的工作量~

  • 这句话太偏太大了,给到任何角色这句话都是适用的。我还是认为测试人员做好自己的本职工作,像楼主提到的无所谓黑测白测,能保证上线阶段不出现问题就是好测试,至于如何提高系统的测试质量,应该是由测试人员的质量占大部分因素。系统的质量可以说是测试人员细心和测试技术决定。

  • 受益良好

  • 你是用 GUI 模式进行并发监控的吗,有没可能是 GUI 模式在大并发的情况下会出现描绘聚合和汇总图时候出现的异常。可以采用非 GUI 模式进行压测,压出报错后再把结果验证一下,聚合图和 TPS 图是否能对得上

  • 昨天做了一次测试,绕过了 NGINX 只对一台应用服务器进行压测,持续进行了 2 小时候后还是有 404 和 500 的一个报错。监控相关资源,应用服务器的资源在 cpu40% 左右,io 2%,mem20%,数据库 cpu60% 左右,io 0%,mem5%

  • ip 访问限制是指什么吗?压力机只有一台,应用服务器有 2 台(其中一台应用和 nginx 放一起),数据库一台。应用服务都正常运行,应用服务日志是没有报错的(tomcat 日志),所以我就一直怀疑是不是服务器的问题,但不好定位是资源问题还是像 3 楼、4 楼同学所说的网关还是 ip 出现问题,我该如何排查是否是这两个问题导致的呢

  • 网关配置?请问一下怎么定位是不是这个问题呢

  • 并发的时候也会出现 500 报错,怎么一步一步排查多是服务器的问题还是应用的问题呢

  • 谢谢你的建议,我在进行并发的时候是使用命令进行,只是调试脚本的时候加个监听器比较方便排查问题。

  • 好的,我也查了一下资料,确实是采集点。后面那段也可能是采集不到导致的,后面进行几次测试都重现出来。谢谢的回复

  • 好的,谢谢你的建议。

  • 1、你说的第一点,“线程数已经没有变化了”(这里我不太明白,因为 jmeter 是在开始的时候就要设置指定的线程数吗,这里设置了 30 个并发线程那肯定只能看到 30 的线程数)
    2、至于样本数的 failture,就是报的 connection time out
    3、脚本没有设置特殊的集合点,就基本配置

    4、还有应用的 jvm 参数已经改过,相应增大到 2048m 没什么不一样,还是会出现这样 “暂停” 情况。所以当时就排除是应用 JVM 的问题。
    5、后面做了测试,如果不使用域名进行压测的话,是不会出现样本数 “暂停” 的情况。直接对 IP 进行压测,不走 nginx 域名,直接压 ip,没什么问题。所以定位到 nginx 相关的一些配置问题,但修改 nginx 的性能配置还是没生效。目前还在调试排查中...

  • 16 天,一个回复都没有...