记一个线上成绩

乙醇 创建于 4 个月 之前

最后更新时间 2019-06-30

永久不要信赖用户的输入

正愁着这周的公众号写些甚么的时辰,线上就很应景的出现了成绩。

成绩很简单,我们的app上有告白位,告白位的落地链接是在后台设备的。明天我们测试同窗发明线上的某个告白位链接点击以后没法展示。

经过排查,我们发明本来运营人员在设备告白位链接时辰在链接后带上了一个肉眼弗成见的字符\t。

缘由找到以后处理起来就很轻易了,只需要运营人员去掉落前面的弗成见特别字符就好了。

这应当是大年夜家很罕见的一个特别字符的测试场景,在设计基于输入框用例的时辰根本上大年夜家都邑做类似的用例验证。不过大年夜家在验证的时辰大年夜部分把精力放在肉眼可见的特别字符上,最罕见的就是url encoding的时辰须要转义的一些特别字符,比如 ^%$@之类,根本上就是键盘数字键上方那一些字符串。不过如许是不完全的了,一些特别的转义字符,特别是肉眼发觉不到的转义字符也是须要推敲的。

其实用例验证是后验式的,假设在需求评审和开辟的时辰就留意到的话,那么就算是漏测,也是不会产生线上成绩的了。

针对这个场景,我们在跟开辟沟通设计的时辰,应当是可以如许做的。

起首前端在发送创建告白位请求的时辰就应当过滤掉落url首位的空字符和换行符,比如 \t\n 其次后端在耐久化url的时辰也要做一样的任务,去掉落有效的空字符 最后app端(android/ios/h5/rn)在跳转url的时辰也要过滤掉落首尾的空字符 总结一下

前端要做校验 后端要做校验 客户端有时辰不克不及自觉信赖办事端 最后大年夜家可以牢切记住一句话:永久不要信赖用户的输入

用户的输入永久的是弗成控的, 必定要对用户的输入做校验和过滤(前后端都要),不然出线上成绩或安然成绩是早晚的事。

我要留言

  • 用户操作也弗成控,用户应用谷歌自带的翻译功能,将英文翻译成中文,在网站停止付出时,向付出网关中传参时,信用卡到期日期会主动增长‘year’字符串,招致付出掉败

    Thresh 创建于 2019-10-15 17:21:16

  • 上周也试过如许的成绩,复制同事给的一条get的接口,粘贴到浏览器的地址框,成果发明一向得不到精确的成果,参数是精确的。成果发明是这条请求中有个/t然则浏览器是不显示的,折腾了半天

    karl 创建于 2019-07-04 14:16:31

  • 用户输入弗成控。 依附前真个JS限制一下输入内容格局是否是便可以包管前端没有成绩了?

    applepen 创建于 2019-07-01 15:35:39