V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  yamedie  ›  全部回复第 41 页 / 共 52 页
回复总数  1035
1 ... 37  38  39  40  41  42  43  44  45  46 ... 52  
2018-08-19 00:31:08 +08:00
回复了 yamedie 创建的主题 分享创造 写了一个聊天室,给任意网站加入尬聊功能
@batnss 在改名字, 重启了一下服务..
2018-08-18 23:35:03 +08:00
回复了 yamedie 创建的主题 分享创造 写了一个聊天室,给任意网站加入尬聊功能
@LongLights ^_^

@SukkaW 不要上 CSP, 一起造作呀 ^_^
2018-08-16 18:02:29 +08:00
回复了 adidala 创建的主题 分享创造 分享个人小站,查询电商历史价格,京东、天猫、淘宝等
@adidala 哈哈原来如此,那你也是 666,大大降低了查询操作的复杂度
2018-08-16 17:25:38 +08:00
回复了 adidala 创建的主题 分享创造 分享个人小站,查询电商历史价格,京东、天猫、淘宝等
@yamedie 我知道了.. 可能是爬友商的
2018-08-16 17:20:36 +08:00
回复了 adidala 创建的主题 分享创造 分享个人小站,查询电商历史价格,京东、天猫、淘宝等
牛!! 想知道海量的商品价格是怎么获取的? 一个个爬?
2018-08-15 14:21:42 +08:00
回复了 xitu 创建的主题 推广 [北京][9.16] 掘金开发者大会 · 微信小程序专场赠票啦~
行, 我败了, 我是前端小白, 我认同 83 楼的结论.
@binux 不是冒充 token, 而是没有进行 token 与入参的比对和鉴权(判断 token 的主人和入参的 userId 是不是同一个人), 这个问题我跟后端提过多次, 现在新接手的人愿意去改掉了.

我为了规避这个问题不捅娄子, 我还想方设法在 spa 里不暴露 userId, 至少让它在浏览器里不被篡改, 现在想想是很多余的, 这些越权的漏洞应该后端来解决, 无奈之前的 java 太懒不想改, 后台 leader 也不想管.
@xycool 不瞒你说我司真的是前端算 signature 的, 但同时所有请求也用了 OAuth 的 token, 两种鉴权方式一起用.
但我们的 java 没做到自己信息只有自己能查, 只要 token 和签名正确了, 也能冒充其他用户身份,只要篡改一下用户 id 就行了,所以我觉得我们的 java 不行,没做到 74 楼说的用户只能访问自己数据(可能接口安全他们只差一步而已).
所以我觉得,只要哪天微信 webapp 的浏览器限制被人破解了,我们这个破系统分分钟完蛋,因为后端虽然鉴权了,但根本没法防止用户在客户端篡改伪造身份.
@chinvo 我来解释为什么用 dev 版不好? 因为前端代码没经过任何混淆就暴露在外, model 层数据整理的明明白白供你调试, 比那些 jQuery 开发的项目还容易让人搞懂业务逻辑. 假设前端调 ajax 还经过了前后台共同约定的 seed 做了参数加密签名(sha1 那些非对称加密), 你的签名加密方式也暴露的明明白白, 别人掌握了伪造接口签名, 就能用个 postman 轻松修理你们后端
我搞不懂你们槽点在哪里, 我说过前端验证[取代后端]了吗? 我一直在强调做 2 次验证好吗?

腾讯云学生机 360 元那次 bug 营销, 你们这些毕业多年凡是买了的, 哪个不是把 select 框 value 改掉再提交的?
@gouflv 好的,我知道. 在公司除了前端还有部分产品设计工作, 我业余也在做全栈项目
"永远不要相信用户的输入" 大家把这里的不信用户等同于不信前端, 没关系, 没人否定后端的数据校验必不可少, 这是数据达到数据库的最后一道关口.
说前端校验是为了用户体验, 与安全无关的, 可以了解一下这本书 https://book.douban.com/subject/10546925/ 从第 2 到第 6 张全部是在讲客户端安全,客户端发起的攻击除了表单篡改, 还有跨站攻击,csrf 攻击.
@phpcxy 恕我也直言,前端才不管后端做不做数据校验,反正页面正常 ajax 传给后端的参数合理合法就行,出了事锅该是谁的就是谁的.
@bestkayle 可以这么说,也不止如此而已,打个不太合适的比方(可能会惹怒很多后端大佬): 民工都知道筛细沙要从粗到细过很多次筛子,为啥这里的高级码农不知道.

一直尝试在 web 安全的角度讨论前端该不该做一次表单验证,
但各位后端大佬给我的感觉是: 给你脸了?后端能做所有表单验证为什么轮到前端做?
如果真这么完美可能世界上就没那么多黑天鹅事件了, 墨菲定律恐怕也是胡说八道.
好了我不再回复了,各位后端大佬继续嗨吧打扰了
@kslr 不是,我发现这帖子几乎所有人论调都是:完全后端做表单验证数据校验(潜台词 前端小把戏,没必要管,随便改),难道不应该前后台做 2 次校验吗,这不应该是规范吗?我替前端感到不服。
@binux 拦住的会出新闻吗?
@falcon05 17 楼两个例子
@binux “数据检验不全靠后端,难道还有信前端的吗?”,不在前端做表单验证,你不信前端,你信用户是吧?我懂了
在讨论的不是后台有没有能力拦截所有非法请求,当然有能力,真的有后端把所有的 case 都照顾到了吗?这是分红和责任心的问题。
某外卖软件消费负 xxx 元,反向充值的新闻了解一下。某打车软件让人研发外挂,损失上百万报案抓人的新闻了解一下。
有人觉得前端改点什么都没影响,后端全能拦截,真的这样吗?
没有代码混淆,前端跟接口之间那点签名鉴权逻辑分分钟让人研究明白吧。
微信里的 webapp 如果不限制浏览器,隐藏地址栏隐藏控制台,还不让人改爆?多少公众号在用 localStorage 存关键数据,在 url 显式传参,又不是没见过……
1 ... 37  38  39  40  41  42  43  44  45  46 ... 52  
关于   ·   帮助文档   ·   自助推广系统   ·   博客   ·   API   ·   FAQ   ·   Solana   ·   4193 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 26ms · UTC 05:33 · PVG 13:33 · LAX 21:33 · JFK 00:33
♥ Do have faith in what you're doing.