一、邮箱总体安全性说明

为了满足用户各种需求而开发邮箱功能时，我们会把邮箱的安全性放在第一位。如果一个功能存在严重的安全性时，我们会舍弃此功能。特别在网页管理后台，网页邮箱收发平台（Webmail），邮箱收发平台等这些直接与客户产生交互的系统功能上则更为关注。web上的安全防护单独一章说明，具体可见本文最后的第五点。

二、总体安全架构设计

1.基于前端代理安全架构

在架构设计时，我们为了保障核心服务器（比如网页服务器，邮件存储服务器，邮件发送和接收服务器）的安全，将这些核心服务器置于后端，后端的这些服务器不能被外界直接访问。外界先通过访问前端服务器（部署有安全策略），通过前端服务器转发请求的方式到达后端核心服务器。由于后端核心服务器禁止直接对外访问，所以在架构层面上避免了很多直接被恶意攻击可能。在最差的情况下，前端服务器遭受外部攻击，在很大程度上避免波及后端核心服务器。此外，攻击者只知道前端服务器信息，无法获取到后端核心服务器的ip等服务器信息，具体如下图：

2.服务器故障应对

在前端代理出现被攻击、故障等导致不能正常运行时，我们的监控系统能够第一时间得知，从而将这台前端代理服务器自动下架。在我们邮局系统中，前端服务器部署在全世界各地多台，一台服务器故障不会导致客户使用问题。此外，核心服务器也是多台共同运行，比如后端网页服务器有多台，一台损坏情况下，系统会动态把请求切到其他台上保持可用性和安全性。

3.暴力破解的防护

邮箱安全性的又一大挑战是暴力破解。邮箱在客户端还是网页端登录需要输入邮箱名和密码，特别是客户端没有验证码等其他安全手段，如下图的foxmail验证邮箱名和密码：

这样就会导致攻击者大量暴力破解密码的产生。我们就2020-05-13这一天的暴力破解次数是7389604次。为了应对暴力破解，我们系统实施了两个手段解决。

底层防火墙层面：

当监控程序发送某些ip短期内出现大量的密码错误，我们的守护程序会自动将这些ip放入防火墙的黑名单中，这些ip在一段时间内根本不能发送数据包到我们的服务器。在web端，大量404返回码（大量暴力扫描网站资源）的ip会被防火墙阻断，恶意提交的含有SQL注入、XSS注入、恶意路径等会第一时间以报警邮件的方式通知给运维人员，并且同样将来源ip阻断。

逻辑验证层面：

当验证邮箱帐号和密码时，发现一个ip在一段时间内错误登录的邮箱去重数很大，则恶意破解的可能性很高，我们会在逻辑层面禁止此ip再次验证。此外，一个邮箱有多个ip在大量验证，我们会发送警告邮件给此邮箱地址用户，希望这个邮箱地址用户能够将登录密码修改的更复杂些。

三、功能层面上

1.SSL多域名证书支持

我们系统可以让客户上传SSL域名证书，证书上传后，客户就可以用使用自己域名的HTTPS的方式访问邮箱网页。同样，通过客户端工具收发邮件时，也就可以填写自己的域名，然后勾选SSL方式。这样您的电脑与我们的服务器之间是通过SSL方式加密传输的，能保证数据在网络上不被泄漏和篡改。下图是SSL上传证书页面：

2.授权ip登录

如果客户企业的服务器支持员工拨类似vpn之类集中管理服务器，则您可以将集中管理的服务器ip加入我们的授权ip登录名单中。这样只有在授权ip登录列表中的ip才能正常登录邮箱系统。

授权ip可以是单个ip，也可以是支持子网掩码的一个个网段的ip。

3.异地登录提醒

在一个短暂的时间段内，一个邮箱地址在多个省或多个国家同时有正常登录记录，则这个邮箱可能被盗，我们系统会发送一封警告邮件给这个邮件帐号，希望这个邮件帐号的客户引起重视。

4.密码修改策略

为了防止密码遗失泄漏，邮箱管理员可以设置密码修改策略，可见下图：

上图中，设置了密码修改后12天内如果密码没有再度修改，则无法使用客户端接收和发送邮件、无法使用web实现邮箱登录。这样就能强制邮箱用户隔一段时间内更换密码。

5.邮箱加密传输

在上图中，发送邮件内容可以勾选设置项的“邮箱加密”选项，然后设置加密密码，这样发送的邮件将会以密文方式传输。收件方需要知道密码才能够解密。

四、业务层面上

五、web页面防护

邮箱系统以web方式与用户交互主要有邮箱收发页面（Webmail）和后台管理页面。在防护上有很多细节点需要注意，下面是这两个系统主要遵守的规定：

1.服务端每个功能必须要对用户提交上来的参数进行安全性检查。

服务器端的逻辑处理的第一步是对用户提交的所有参数进行安全性检查，比如提交上来的应该是数字方式，但最终提交上来的含有其他非数字字符则直接报错；提交上来的应该是邮箱地址，必须要对邮箱地址进行正则检查，不符合邮箱地址的同样直接返回报错；提交上来的值在一个范围内，但如果实际提交的值超出这个范围，则直接报错等。

2.页面显示转义输出

为了避免XSS注入（将客户可执行代码比如JS在浏览器中运行），将需要显示在页面上的代码在服务端转义后输出在浏览器中。通过转义可以原样输出数据，同时避免将可执行代码在浏览器中被触发。

3.XSS和SQL注入探测

对提交上的所有数据，系统会去探测是否含有恶意代码（比如恶意JS或SQL语句），如果是恶意代码，系统会发送报警邮件及时通知后台运维人员，同时将访问ip放入防火墙拦截名单中。

4.数据库权限分离

从（读）数据库只有读取权限，禁止设置其他权限比如（写权限，提权权限）。不同数据库用户只能访问固定数据库。

5.恶意扫描网站和登录防护

大量产生404资源不存在，或者访问一些关键目录时，系统会记录访问的来源ip。比如访问来源ip存在大量404资源不存在时，则系统会将来源ip放入防火墙拦截名单中。

邮箱收发（Webmail）和后台管理系统登录页面，除了增加验证码（避免机器人大量暴力破解）外，也会对登录失败的来源ip和邮箱地址进行记录，如果登录失败数满足我们的算法条件，则来源ip或者登录邮件地址将会在一段时间内被锁死。

6.JS和CSS压缩输出

为了避免Js对外逻辑可读（尽量防止被恶意用户分析），同时也能降低用户对网页打开等待时间，我们对所有JS和CSS代码文件压缩输出。

7.Cookie的防护

我们对所有关键的cookie（比如记录sessionid的cookie）统一设置成HTTPONLY属性，这样就能避免被JS直接获取。防止XSS注入中通过JS获取关键cookie值。如下图：

8.必须设置内容安全策略（CSP）

所有服务端必须设置Content-Security-Policy，在这个策略中设置可以被访问的资源地址（一般都是此系统所属的安全地址）。这样不在策略中存在的其他地址中的资源无法被浏览器加载。比如系统存在XSS注入，这样注入执行的JS代码将无法加载外部未授权的资源。

9.邮箱后台管理系统填写验证码后操作

邮箱后台管理用户域下所有邮箱地址，所以后台管理操作需要特别注意安全。我们目前对邮箱的添加、密码修改和子管理员的添加、提权以及其他所有功能的删除操作都增加了输入验证码功能。用户管理员在做上述操作前必须要填写正确验证码，然后系统才能执行后续操作。这样既能够避免用户误操作，同时也能很大程度上保证系统安全性。

10.CSRF攻击防护

邮箱收发系统页面（Webmail）和后台管理系统都有对CSRF攻击防护。通过如下两个方式：

1.这两个系统都会对http请求的Referer进行判断，如果Referer是来自外部系统路径，则直接返回报错。

2.这两个系统都有token机制，每个用户服务端和客户端都保留一份token，每次访问时服务端检测token是否正确。后台管理系统每次请求后token都会实时变化，更加保证对CSRF的攻击保护。

11. 用户之间操作隔离

邮箱收发系统页面（Webmail）和后台管理系统用户之间操作隔离。比如后台管理系统，A用户管理员不能修改B用户下的邮箱数据；Webmail系统中A邮箱用户不能操作B邮箱下的数据和动作（比如发送邮件）。服务端程序必须考虑恶意用户故意提交其他存在用户身份参数值的情况。