我这不是为了说明对于客户端来说,jwt 跟 session 是等价的么
突然意识到了一个问题,可能因为我在墙外呆久了,跟墙内讲的安全不是一种概念。
一边用着老版本 ie 甚至 xp,flash 还在大行其道,然后谈安全……我们客户如果问为啥不支持 ie11 之前的版本,只要一句微软已经不出安全补丁了就怼回去了。上上周 chrome 好像修了个 0day 漏洞,我们不是技术出身的总经理群发了一封邮件提醒升级 chrome。
这个月初给一个斐济客户的大概能有7、8年的老系统加个 js 限制,因为我们后台有个 bug,某种类型的东西同时添加多个,只能保证一个能生成正确的记录。已经不给老系统做功能上的维护了,这个只是为了避免客户误操作,大家都开心。因为不了解前端用了哪些东西,我打算用 vanilla js 写,然后就想看看用户有多大比例用 ie。因为没上统计库,没办法看了另外一个产品在斐济的客户数,月平均1、2个 ie 访问,于是我就放心大胆的写了。
上周还有个客户报 bug,说是小键盘的“.”在货币的文本框里不能用。客服一问果然用的是 ie11,然后就劝,除了 ie 以外的都没问题,于是客户就换了。因为我用的是 mac 不想开虚拟机了,于是随手在 codepen.io 写了几句发给同事让看一下 event.key 是什么。结果同事打开链接,人家默认不支持 ie,虽然给了个视频链接似乎可以在“old browser”上面用。虽然这个 bug 现在还是要修的,但等再过个两年 ie11 的生命周期结束,我们就可以宣布不支持 ie 了。
另外,类似 github 说不支持就不支持 ie,所以墙外的世不支持 ie 也无所谓的,更别说都多年没碰到过要开 flash 的了。
客户的安全需求也是千奇百怪,有 openid 的,有 ldap 的,有的是公司内网,我们得用他们给的 token gen 远程桌面登录的。不知道 oracle 密码自动3个月过期的功能有没有给生产环境关掉,反正在开发环境上我是吃过亏,折腾了好一阵才给关掉。我们这责任很明确的,如果问题的原因在我们,那没问题免费给技术支持。但是如果是 auth token 泄露这种问题,明显责任不在我们,想让我们擦屁股,没问题商量个价钱吧。而且按照我们的客服条款,保证正常客户流程没法满足这种安全需求,而且我们是工作时间客服,不提供24小时客服的。你想要快速反应,24小时服务,肯定不如多养一个人做好公司的安全问题划算。
cookie 设 http only 有它的好处,当然缺点是失去灵活性了。但是按照目前主流浏览器的实现,是可以保障 js 没法读到 cookie,这在安全方面是非常有意义的,尤其是在使用外部 cdn 的情况下。
另外像 csrf 纯粹就是个保护色,抓到网页看到有 csrf 就知道不用动这方面脑筋了。莫非低版本 ie 还能跨域名 post form,所以还在纠结这种早就失去意义的安全问题?
一边用着不安全的工具,一边要把一个 token 签个三年或者天长地久,然后还一边喊安全,我觉得挺有喜感的……
【 在 beep (菜M.喵星耗子) 的大作中提到: 】
: jwt一般也不放cookie吧,我见过的项目一般都是走http header,这样的方案在native app端和web端通用,后端不需要分两种情况处理。web前端持久化大多数也是放localstorage。cookie这种远古浏览器黑盒子,黑魔法太多,应用层不能主动控制细节,不同浏览器行为也有细微区别
--
FROM 122.60.88.*