本文主要是介绍【转载】肉山的red5研究日记（七）：SharedObject的安全问题，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
文章来之：http://blog.zol.com.cn/790/article_789021.html
so的工作原理是，任何地方修改了so，都会马上同步到所有共享（share）此对象（object)的节点，不管是客户端还是服务器。这就带来了两个问题，第一，大家都知道用户的提交是不可信的，未经验证的东西同步到所有共享此对象的节点，其危险性不言而喻；第二，flash是由访问者下载到本地运行的，而且半编译半解释的脚本语言属性令其破解相对别的客户端而言容易了许多，所以不排除会有些人破解客户端然后用hack的客户端达成某种不可告人的目的。
另外一个危险的地方体现在隐私保护上。如果用so实现私聊的话，或者每次都建立一个so，或者在so里面增加toid的标记，但后者有一个问题就是聊天内容始终是向所有连接到此so的用户广播的，因此如果有人怀着不良动机hack了客户端，那么是有可能监听到别人的聊天内容，这也是无法容忍的。
于是有人提出不要使用so，老老实实用客户端调用服务器方法，服务器端再回调目标客户端。不过我觉得这种做法未免太消极，毕竟在多客户端的时候，so无论从时间上海市空间上都要好于方法直通——不然干嘛要做这个东西出来——因此完全可以想其他的方法来保全。
然后稍微写下我的想法。首先，用调用服务器端方法来发言，同时将so设为只读，只能在服务器端修改。调用方法有很严格的变量类型限制，可以用作规范；而在服务器端修改so，又能很方便的同步到其它机器上，问题就解决了。
第二，在页面当中插入聊天flash时增加类似验证码的操作，同时利用跨域策略文件限制，降低其他人使用恶意hack修改过的客户端的可能性。
第三，依照测试的经验，N人以下的会话使用命令直连；N人以上的会话使用so同步，来平均服务器消耗。
就写到这儿吧，继续去调程序了~~~
这篇关于【转载】肉山的red5研究日记（七）：SharedObject的安全问题的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
