|
锁定老帖子 主题：淘宝如何跨域获取Cookie分析
精华帖 (13) :: 良好帖 (16) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-04-18
Referer过滤应该是个白名单
|
| 返回顶楼 | |
|
发表时间：2011-04-19
clue 写道 这算不算一个安全隐患呢？任意的站点都可以访问此数据，从而它们都可以取得淘宝的登录信息。
至少，它应该做下限制，只有Referer为自己分站时才返回数据 我也是这么想的！ |
| 返回顶楼 | |
|
发表时间：2011-04-19
其实用cas单点登录就可以做到呀
|
| 返回顶楼 | |
|
发表时间：2011-04-19
最后修改：2011-04-19
xushaomin1122 写道 其实用cas单点登录就可以做到呀
cas 的单点登录好象跟这里所说的cookie跨域没多大关系吧，cas是基于一个域名下统一存储cookie的，从而去避免了sso 中 cookie跨域的问题。 这一点与淘宝的处理类似，将cookie统一存储在taobao.com域名下，然后提供获取cookie接口。 与之不同的是CAS对于其它子应用系统来说也是不需要与cookie打交道，甚至于不需要知道cookie的存在，而cas 的cookie中也只存储了TGT. 如果cas-client希望能够获取用户名那么必须要通过在统一认证中心验证并由服务器生成 TGT 加入到cookie中，接着cas再根据TGT生成ST以参数的形式传递给子应用系统，这时候子应用系统再通过 ST 调用 serviceValidate 或 smalValidate 从而来获取用户登录名。 |
| 返回顶楼 | |
|
发表时间：2011-04-19
前几天我加上了refer检查,当然refer很容易伪造,木钱也没有什么好的解决方案,希望大家在研究的同时能够提供一些建议.
木钱是通过白名单来控制的,而且这个接口只有通过我这里同意后才能使用,否则更改的时候产生问题概不负责的 谢谢大家对我们方案的关注 |
| 返回顶楼 | |
|
发表时间：2011-04-19
至于跨域名,其实使用SSO就可以实现了.
不需要在前台传递过多的信息. 但是必须要具有一个标识串,这个可以通过多种方式实现.但是串需要无规则或加密. get和post的方式. 然后session采用一个session集群存储的方式来保存. 后台对应成功后会写入cookie信息. |
| 返回顶楼 | |
|
发表时间：2011-04-19
最后修改：2011-04-19
yhx0000 写道 至于跨域名,其实使用SSO就可以实现了.
不需要在前台传递过多的信息. 但是必须要具有一个标识串,这个可以通过多种方式实现.但是串需要无规则或加密. get和post的方式. 然后session采用一个session集群存储的方式来保存. 后台对应成功后会写入cookie信息. 你说的就是 cas 的大概方案，实现上比你说的更复杂。 |
| 返回顶楼 | |
|
发表时间：2011-04-27
我觉得使用Referer解决不了根本的问题,顶多就是防止一些钓鱼网站直接使用JS取信息,
其实可以参考SSO实现,使用JS是取得一个Token,然后再从当前服务在后台跟内部认证服务器认证取得真实的用户名, 这样是不是更可靠些? JE帐号 写道 JE帐号 写道 mylove4 写道 现在确实不行了。http://www.taobao.com/go/app/tmall/login-api.php?0.6783450077710154 返回的是：
啊哦,不好意思,该接口不对外部人员开放! 我用httpclient模拟了一下,现在应该是加上Referer检查了. 如果不加Rederer,就会返回"啊哦,不好意思,该接口不对外部人员开放!"; 如果加上"get.addHeader("Referer", "http://www.tmall.com");" (经测试http://www.alimama.com也行)还是可以正确返回的登录信息的. 测试方法是先使用firebug 在浏览器里面把"http://www.taobao.com/go/app/tmall/login-api.php?xxx"这个请求的的内容抓取,然后在代码里在提交get前在head里加上抓取来的Cookie即可. 从我测试来看,现在是在服务端对Referer进行检查.假如是类似方式的话,我想进一步问一下,如果有淘宝的同学或者其他有经验的哥们帮忙回答一下: 针对这个过滤Referer的需求,该怎么管理?就像我测试的,除了tmall,alimama也是可以的,那么假如明天淘宝又多个业务入口比如abc,而这个abc完全由另外一个部门维护,那么有什么内部机制可以在abc上线前驱动这段"过滤Referer"的代码进行修改? 我想到的方式: 1.这个过滤原本就是公用的模块,不需要各部门额外维护,增加abc后,在公用模块添加一下即可.但是这个需要非常强大和很细节的前期设计能力. 2.内部存在一个部门负责这种总体的协调,但是这就意味了,这个部门给知道很多分项目的实现细节,并且能在新加入abc的时候立刻意识到还有这样一段"过滤Referer""的代码需要修改. 3.abc先开发,测试出问题,找出问题后,通知其他部门修改这段代码. 在这个问题上,这种方式确实可以奏效,因为这是个一测就会出明显问题的情况.但是是否存在那种很不明显隐藏很深的情况?这对测试用例的覆盖就是硬性的要求了.而且,这也意味了无论设计还是架构都出现了无能为力,无法完全覆盖控制风险的情况. |
| 返回顶楼 | |
|
发表时间：2011-05-09
最后修改：2011-05-09
DT1 写道 我觉得使用Referer解决不了根本的问题,顶多就是防止一些钓鱼网站直接使用JS取信息,
其实可以参考SSO实现,使用JS是取得一个Token,然后再从当前服务在后台跟内部认证服务器认证取得真实的用户名, 这样是不是更可靠些? 是的，我测试了，我通过 flex/HTTPService 同样还是可以 伪造 Refere ，同样可以获取到用户名。 |
| 返回顶楼 | |
|
发表时间：2011-05-10
denger 写道 DT1 写道 我觉得使用Referer解决不了根本的问题,顶多就是防止一些钓鱼网站直接使用JS取信息,
其实可以参考SSO实现,使用JS是取得一个Token,然后再从当前服务在后台跟内部认证服务器认证取得真实的用户名, 这样是不是更可靠些? 是的，我测试了，我通过 flex/HTTPService 同样还是可以 伪造 Refere ，同样可以获取到用户名。 自己能访问到并不是安全隐患，这个消息也并不是针对你自己也敏感的网站内部数据，它只是将你在其域名下的cookie输出而已 但如果你写的flash可以在别人访问时不知道的情况下伪造Referrer，并将它收集起来，那才是有问题。 就像你把你自己的电脑系统的远程端口打开了，人人都能访问它，但这并不代表别人用这个系统也不安全， 你始终只是访问到“你可以访问”的数据而已。 |
| 返回顶楼 | |
