新手问题 如何安全地提交敏感数据?

cassiuschen · 2014年04月12日 · 最后由 hooopo 回复于 2014年04月15日 · 2446 次阅读

程序中有各种需要提交数据的地方。举例说明如 DoorKeeper 这个流行的 Oauth2 Provider 在请求用户授权的界面使用了 hidden_tag 隐性表单提交 current_user 的信息到数据库,可这在浏览器端很容易就可以吧表单信息修改掉,从而取得别的用户的授权… 如果调用另一个方法来 post 数据,那么为了在 controller 里获得 current_user 的信息一般选择在 session 中存储,但 session 也是有办法修改的………有什么办法能阻止这样的情况发生么?

HTTP 可不就这样…………有啥想法?。。。

对称加密

"可这在浏览器端很容易就可以吧表单信息修改掉,从而取得别的用户的授权" -- 除非截获 http 请求或者直接拿到其他用户的 cookie,否则你能很容易就改成其他用户?

要真是用户的请求被截获或 cookie 泄漏,这也不是网站能够解决的问题。

#2 楼 @CN_Boris 就是说在服务端加一步验证或者在提交数据时加密然后在服务端解密?

#3 楼 @billy 比如 rails 的 form_tag 生成的表单信息,如果有一个隐藏表单填入的是用户 id,在浏览器上把它改成别的提交也是可以的啊…

@cassiuschen 在表单里填 current_user id 是错误的做法。正确的做法是不要 user.id, 而直接在 controller 里面取 current_user

#8 楼 @billy 但比如 deise 这种靠幽灵方法绑定的在做 api 程序的时候一直有问题…

@cassiuschen 你做 web app 的 api 时没有任何问题啊,还是可以用 cookie。做 mobile app 我不太熟,但应该可以用 token 或者也可以用 cookie,还是不需要直接的 id。

如果实在避免不了在表单里用 user_id,你也可以在 controller 里面验证的。if params[:user_id] == current_user.id 不过这种代码就难看一点。

#10 楼 @billy 嗯…不失为一种方法…

作为 doorkeeper 排名前十的贡献者,我想说...这 gem 太烂了...唯一的解决办法就是,彻底重写 - -

@jasl 这么烂你还贡献。我想说...你真能忍啊。

#13 楼 @billy 我就是看不下去了才贡献代码呀,本身我们也在用,但是首先,那个项目的现在维护者能力一般,那厮当初拒绝接受 orm 的兼容 pr,号称自己可以搞抽象层解耦 orm,事实上也有人提交了方案,但因为年代久远不好 merge 自己鼓捣几个月又没鼓捣出来。。。。复杂的重构他也不会接受,其次,这个 gem 的主要开发者是波兰团队,据说那边的开发风格就是以狂野著称,代码里有这样的注释# this is so wrong 但还是上了,恰好工作而已,甚至有硬编码的部分... 我是想接手这个 gem,但可以 KnewOne 实在是缺人手,所以没有精力做这些,你看我 ruby-china 都是潜水姿态了....

#14 楼 @jasl 膜拜一下…………以后有机会自己搞一个呗~

#15 楼 @cassiuschen 解协议很无聊....

#16 楼 @jasl 但……木有办法啊…………几年前有个国外的不是用 devise 手写了 oauth2 的整套流程,但是他所依赖的 devise 的某个认证功能在后续版本里删了……

#17 楼 @cassiuschen token_authencatable 么...devise 3.x 已经移除掉了 4.1 的那个内置 hmac 能解决一些问题了

对了 专业回答得 @hooopo

防修改,加签名呗。

需要 登录 后方可回复, 如果你还没有账号请 注册新账号