首页 | 邮件资讯 | 技术教程 | 解决方案 | 产品评测 | 邮件人才 | 邮件博客 | 邮件系统论坛 | 软件下载 | 邮件周刊 | 热点专题 | 工具
网络技术 | 操作系统 | 邮件系统 | 客户端 | 电子邮箱 | 反垃圾邮件 | 邮件安全 | 邮件营销 | 移动电邮 | 邮件软件下载 | 电子书下载

新闻资讯

邮件服务器 | 行业法规 | 网站公告 | 邮件趣闻 | 邮件人物 | 行业数据 | 反垃圾邮件 | 移动电邮 | IT业界 | 邮件客户端 | 电子邮箱 | 邮件安全 |
首页 > 新闻资讯 > 邮件行业法规与制度 > “电邮泄密”案技术关键:专家如是说 > 正文

“电邮泄密”案技术关键:专家如是说

出处:CNET中国·PChome.net 作者:CNET中国·PChome.net 时间:2007-12-16 22:52:28

国内的首件“电邮泄密”案日前开庭,随着网络安全问题的日益凸显,因此也得到了众多媒体的广泛关注,以下是记者找到的著名反垃圾邮件专家陈勇先生在其博客中撰写的一篇文章,详细分析了其中的技术因素,在此引用:

事情应该是比较清楚了,金道律师事务所发给别人的邮件,别人(以下称为该用户)使用的是万网企业邮箱,在万网企业邮箱中,使用的是随机的、会超时的长URL来访问邮件的附件,而该URL地址被该用户计算机上的某个软件(应该是百度搜霸一类的百度的搜索引擎辅助客户端工具)发送给百度的搜索服务器,该搜索服务器在上述URL超时前就去访问了该URL地址的网页,即邮件附件的访问网页,并作了快照,因此别人就可以通过百度快照访问该邮件附件了。

目前网页访问控制使用的控制方法主要就是两个,一个是随机的、会超时的长URL,另一个是Cookie。虽然Cookie比长URL的方法后出现,但个人认为这两种方法的安全度是一样的,当时Cookie出现后也曾有过安全性的争议,Cookie实际上可以理解为把那个长URL的部分内容放到了Cookie文件中,使URL更简短,而安全性上应该是一样的。

我们日常使用的用户名、口令方式保护,用户名应该在10个字符左右,口令也不会太长,总长也就是20个字符左右。长URL中的相关乱码肯定是超过这个长度的,应该在几十位到上百位,是不可能被猜到的,至少比原来的用户名口令要安全,基于水桶原理,最短板不在长URL,因此长URL本身是安全的。这个长URL如同打开一道门需要使用一把钥匙,钥匙上的突起凹陷无法在短时间内被猜出,因此无法打开这道门。当猜到这把钥匙的所有突起凹陷时,这把锁早已失效(超时了),这时就算复制了钥匙,也无法打开这道门,需要对新锁的钥匙重新猜试。

能不能说使用长URL而不使用Cookie的方式不够安全呢?我认为不能,因为这只是解决访问控制的两种方法,而不是Cookie比长URL更安全。目前除了万网在发现这个问题后又加上Cookie控制,我没有见到哪个网站同时使用两个方法保护。万网原先相当于用了1把锁,而现在相当于用了2把锁,但没有本质区别,安全性只在这个具体案例中才有区别。

从邮件系统本身来说,万网保证了邮件送达用户端这个过程中的基本安全,本案例的信息泄露是在用户看到邮件之后,因此很难说万网应该对邮件已经安全送达收件人之后的安全继续提供保障,这部分的安全性应该是本地安全的问题,个人认为要求邮件提供商保证用户计算机本地安全是不现实的,要求太高了。

如果这个长URL不被泄露出去,用户的邮件信息是不会泄露的,这就如同上述这道门的钥匙,用户没有给别人或让别人复制,别人是无法进入这道门的。而用户无论是主动地把这个长URL交给别人,还是无意地被本机安装的软件送了出去,都相当于用户把钥匙给了别人,这样这道锁就失效了,但不能说这道锁不安全。

再说百度。最早的搜索引擎都是靠搜索爬虫自己爬出来的,比如先访问新浪首页,根据首页中的链接再爬这些链接页面,再爬链接页面的链接页面。这种由客户端上报用户所访问的网页然后搜索服务去搜的方法是后来出现的,不少搜索引擎都这么做,是一个惯例,但这个惯例大家没有关注它的安全性,也有值得探讨的地方。

搜索客户端按照大部分人的认为,不会透露用户隐私内容,但这要看大家对隐私怎么理解。搜索客户端提交了用户所访问的URL,当然可以提高搜索引擎的搜索效果(大家关注的网页被重点处理),还可以分析用户的网络访问习惯,这应该算一个不太重要的隐私。如果不是这个案例,甚至连我都没有注意这样会存在大的问题。但我除了测试不会安装这样的软件,我觉得这只对百度有好处,对我有什么好处?让百度知道我的访问习惯、知道我访问了哪些网站。

有人会问如果当初万网就用Cookie不就没这个问题了吗?我觉得这只是凑巧,因为搜索客户端软件只上报URL而没有上报Cookie,搜索客户端开发方也许知道Cookie有保护网络信息的作用,而忽视了随机的、会超时的、长URL也有保护网络信息的作用,因此搜索客户端没有上报Cookie,理论上完全可以做,而且两者的效果是一致的。这好比万网有2把锁可用,如果没有搜索客户端,长URL锁是安全的,百度说:你这个长URL锁的钥匙我要拿走,进去看看有什么东西,如果不让,你得用Cookie锁,Cookie钥匙我没拿。哈哈,是不是有点荒唐?目前长URL的问题只在用户计算机安装了自动发送URL的软件,具体说就是搜索客户端发现,要求这些网站因此换用Cookie没问题,但要求他们对此负责好像没道理。

照理,长URL方案比较早,如果要求万网和百度想到这种情况下有个安全漏洞,应该是百度想到,但是这个要求对百度来说,似乎有点高,不出事预知这个问题有些难度。。。反正我在这个案子之前也没注意到。

所以单独就万网来说,信息泄露是在万网的职权范围之外(信息已达用户计算机、非万网软件从用户计算机把长URL送了出去),因此万网应该无责。

单独就百度来说,虽然把用户所访问的URL送给百度的做法值得探讨,但确实是业界的一个常用方法,并且百度在软件安装前,曾提示了会上报用户访问的URL,用户同意后才会被安装,只是用户不知道会带来什么后果,甚至根本没看上述提示,就同意了安装。因此百度也很难说应该对此事负责。

而从用户角度说,他不是专家,他不知道安装这个软件居然会产生这样的后果。要求用户对提示想到全部后果,也不太现实。但这个软件确实是用户同意后才安装的,恰巧出现了这样的问题。所以虽然这样说可能会受到用户的抨击,但我还是觉得用户自己的责任最大。

如果把万网和百度作为一个整体来看,也许还能说这个整体应该对此事的发生负责,但他们是两个独立的公司,万网没有义务测试跟百度的兼容性问题,百度也没有义务测试跟万网的兼容性问题。

另外还有个细节:如果一个网站不希望搜索引擎搜索它,有个惯例,是在网站根目录放置一个robot.txt文件来“谢绝”搜索引擎等自动机的访问,之所以说是“谢绝”,因为它不是一个屏蔽方案,只是搜索引擎应该对根目录有robot.txt的网站不去搜索,如果不管robot.txt,搜索引擎想搜是可以搜的。万网是否放置了robot.txt,百度是否忽略了robot.txt,我对当时的情况不得而知,但可以从旁证来取得,比如:如果有人使用万网邮箱并安装了google客户端,照理如果万网放置了robot.txt,google如果先验证robot.txt,则应该没有搜索结果,否则google上也应该能搜到。万网用户、百度客户端、google客户端的安装量都很大,应该这样的组合都存在。

所以,从法律责任来说,万网应该是无责的;百度也很难说应该负责。但从维护互联网安全的社会责任来说,万网和百度应该加强合作,发现各自系统互动中可能出现的新问题,这一点我相信无论这个案子最后怎么判,万网和百度都会去做的。

最后我想说的是:用户的安全意识是最重要的,无论什么软件都敢装,无论什么网站都敢访问,作为安全厂商来说,当然会推出越来越新、越来越好的软件来保护用户的安全,比如360safe已经帮助用户做了很多,但很难做到绝对安全。用户的安全意识会很大程度上保障自己的安全,不知道的软件不要装,不知道的网站不要去。百度和google等搜索引擎的客户端还算善意软件,恶意软件就更不好说了,把URL送出去是小事,恶意软件完全可以把你的内容直接送出去、机密直接送出去。

相关文章 热门文章
  • 新型Twitter式电邮限制信件长度不超500字母
  • 新浪企业邮箱推出全新的Push Mail无线电邮服务
  • 报告称2014年全球无线电邮用户将达10亿人
  • 电邮服务商Xobni推出黑莓电子邮件应用
  • 消息称VMware将12日宣布收购雅虎开源电邮部门
  • 香港成全球垃圾电邮之都 专家称难堵截滥发源头
  • 雅虎电邮发布新软件 用户可发送100MB附件
  • 小心!电邮会泄密
  • 垃圾邮件殃及企业邮件 知名CEO判电邮死刑
  • 无线电邮:3G引领突破在即
  • Myspace推出Web电邮服务 存储容量无限制
  • 盖茨使用3台显示器每天收逾百封员工电邮
  • 企业监视员工电子邮件合法吗?
  • 《电子邮件服务管理规定》即将出台
  • 中国互联网协会反垃圾邮件规范
  • 互联网协会公共电子邮件服务规范发布
  • 《中国互联网协会互联网公共电邮服务规范》
  • 中国移动手机邮箱黑莓业务争夺高端用户
  • 美国:监视他人电子邮件内容不违法
  • 电子邮件(E-mail)证据若干问题研究
  • 电子合同中电子邮件应用的法律问题研究
  • IP地址与证据
  • 电子邮件能否作证引发争论
  • 美100%企业雇员认为E-mail应该被监控
  • 自由广告区
     
    最新软件下载
  • SharePoint Server 2010 部署文档
  • Exchange 2010 RTM升级至SP1 教程
  • Exchange 2010 OWA下RBAC实现的组功能...
  • Lync Server 2010 Standard Edition 标..
  • Lync Server 2010 Enterprise Edition...
  • Forefront Endpoint Protection 2010 ...
  • Lync Server 2010 Edge 服务器部署文档
  • 《Exchange 2003专家指南》
  • Mastering Hyper-V Deployment
  • Windows Server 2008 R2 Hyper-V
  • Microsoft Lync Server 2010 Unleashed
  • Windows Server 2008 R2 Unleashed
  • 今日邮件技术文章
  • 腾讯,在创新中演绎互联网“进化论”
  • 华科人 张小龙 (中国第二代程序员 QQ...
  • 微软推出新功能 提高Hotmail密码安全性
  • 快压技巧分享:秒传邮件超大附件
  • 不容忽视的邮件营销数据分析过程中的算..
  • 国内手机邮箱的现状与未来发展——访尚..
  • 易观数据:2011Q2中国手机邮箱市场收入..
  • 穿越时空的爱恋 QQ邮箱音视频及贺卡邮件
  • Hotmail新功能:“我的朋友可能被黑了”
  • 入侵邻居网络发骚扰邮件 美国男子被重..
  • 网易邮箱莫子睿:《非你莫属》招聘多过..
  • 中国电信推广189邮箱绿色账单
  • 最新专题
  • 鸟哥的Linux私房菜之Mail服务器
  • Exchange Server 2010技术专题
  • Windows 7 技术专题
  • Sendmail 邮件系统配置
  • 组建Exchange 2003邮件系统
  • Windows Server 2008 专题
  • ORF 反垃圾邮件系统
  • Exchange Server 2007 专题
  • ISA Server 2006 教程专题
  • Windows Vista 技术专题
  • “黑莓”(BlackBerry)专题
  • Apache James 专题
  • 分类导航
    邮件新闻资讯:
    IT业界 | 邮件服务器 | 邮件趣闻 | 移动电邮
    电子邮箱 | 反垃圾邮件|邮件客户端|网络安全
    行业数据 | 邮件人物 | 网站公告 | 行业法规
    网络技术:
    邮件原理 | 网络协议 | 网络管理 | 传输介质
    线路接入 | 路由接口 | 邮件存储 | 华为3Com
    CISCO技术 | 网络与服务器硬件
    操作系统:
    Windows 9X | Linux&Uinx | Windows NT
    Windows Vista | FreeBSD | 其它操作系统
    邮件服务器:
    程序与开发 | Exchange | Qmail | Postfix
    Sendmail | MDaemon | Domino | Foxmail
    KerioMail | JavaMail | Winwebmail |James
    Merak&VisNetic | CMailServer | WinMail
    金笛邮件系统 | 其它 |
    反垃圾邮件:
    综述| 客户端反垃圾邮件|服务器端反垃圾邮件
    邮件客户端软件:
    Outlook | Foxmail | DreamMail| KooMail
    The bat | 雷鸟 | Eudora |Becky! |Pegasus
    IncrediMail |其它
    电子邮箱: 个人邮箱 | 企业邮箱 |Gmail
    移动电子邮件:服务器 | 客户端 | 技术前沿
    邮件网络安全:
    软件漏洞 | 安全知识 | 病毒公告 |防火墙
    攻防技术 | 病毒查杀| ISA | 数字签名
    邮件营销:
    Email营销 | 网络营销 | 营销技巧 |营销案例
    邮件人才:招聘 | 职场 | 培训 | 指南 | 职场
    解决方案:
    邮件系统|反垃圾邮件 |安全 |移动电邮 |招标
    产品评测:
    邮件系统 |反垃圾邮件 |邮箱 |安全 |客户端
    广告联系 | 合作联系 | 关于我们 | 联系我们 | 繁體中文
    版权所有:邮件技术资讯网©2003-2010 www.5dmail.net, All Rights Reserved
    www.5Dmail.net Web Team   粤ICP备05009143号