WordPress建站心得(三)Web安全与隐私

2017年4月21日更新:因StartCom和WoSign接连曝出证书签发丑闻,Mozilla, Apple和Google已经决定撤销对这两家CA厂商的信任。Alex Sky网站也于2016年8月31日全部改为Let’s Encrypt CA。使用StartSSL的站长应该尽快转用其他CA。

在上两篇文章中,我们谈到了如何通过网页设计和服务器设置降低页面呈现时间,提高网站整体性能和提高用户体验。这一篇文章将涉足一个新的领域——安全。在我说的网站的四个重要价值——“功能”、“交互”、“性能”、“安全”中,“安全”恐怕是最少提到的话题之一了,对于WordPress更是如此。不过在当下,网站安全的话题却屡屡被提及,从前些年的CSDN用户密码泄露,到最近才发生的adobe账户泄露,再到逐渐发酵的凌镜门事件,网络攻击似乎并没有随着科技的进步而减少,反而愈演愈烈,并逐步替代木马和病毒,成为信息安全中的主要威胁。

作为用户,我们小心谨慎,注意密码安全关闭浏览器的密码自动填充更改路由器密码。不过这些远远不够抵御目前的诸多网络攻击。比如前几天我发现新浪微博和人人网仍然无法避免会话劫持(Session Hijacking)的攻击。我认为作为站长,对于此类攻击有不可推卸的责任。

提到网站的安全,我们首先会想到服务器的安全,比如SSH的密码安全,防火墙,SQL注入防护等。这些都非常重要,而且也是建立一个网站必要的措施。不过我今天谈到的一些安全措施,则更加针对当前的网络攻击,尤其是直接针对终端用户的攻击。这类安全措施目前较少受到重视,但却是必不可少的。我将以当前的攻击为主线,来讲讲如何通过合理配置服务器来防护。

Information Scan

在所有网络攻击前,黑客最有可能的操作就是扫描目标网站,找寻漏洞。比如发现SQL注入点,发现未关闭的端口,但更为简单的是读取服务器和PHP的版本号,因为某些版本有现成公开的漏洞可以利用。比如,BlogCN的返回标头中写了Server:nginx/0.7.67,而BlogBus的返回标头中写了X-Powered-By:PHP/5.2.13。这种版本号对于页面显示没有任何用处,反而会给黑客攻击带来重要的参考。所以最简单的方法就是关掉显示。

在php.ini中

expose_php = 0

在apache2.conf中

ServerSignature Off
ServerTokens Prod

这样一来,黑客并不知道你使用的软件版本是什么,也就只能采用其他扫描的手段,攻击的门槛也相应提高了。

XSS攻击

XSS攻击是当前最常见的攻击手段之一。XSS全称叫跨站脚本(Cross-Site Scripting),是指一个网站引入了存储在另一个网站的脚本,因为浏览器对于脚本一视同仁,所以都会执行,从而造成威胁。我们拿新浪微博作为例子讲。

新浪微博weibo.com是一个正常的网站。黑客网站hack.com是黑客用来存放脚本的网站。以下是可能的攻击过程。

  1. 黑客在weibo.com上找到一个程序漏洞,这个漏洞让他能将任意脚本注入到页面里,让其他人访问
  2. 黑客通过发布精心撰写的帖子,将脚本语句注入到页面
  3. 黑客的关注者看到了这个帖子,触发了该脚本
  4. 该脚本将weibo.com页面上的姓名等个人信息发送至hack.com
  5. 该脚本逐个读取这个访客自己的关注者,并将他们的个人信息发送到hack.com
  6. 该脚本指示浏览器在weibo.com发送帖子,从而将该脚本继续转发到该访客的关注者的页面上,扩散开来
  7. 该脚本伪造隐性的登陆密码框,获取开启了密码自动填充的浏览器保存的密码,并发送至hack.com
  8. 对于没有开启自动填充的浏览器,该脚本伪造一个可见的密码登录框,诱使用户输入密码,再将该密码发送至hack.com
  9. 该脚本自动删除访客页面上的该帖子,销声匿迹

以上的9个步骤,最短可以在2-3秒内完成,而访客完全无法察觉。如果你觉得这不可能,那我告诉你,2011年,类似的攻击已经在新浪微博出现。而现代浏览器对于此类攻击的防护是0,就算装了再强悍的杀毒软件也没有用。

XSS发生的根源是浏览器对于用户访问的页面有绝对的操控权,而它对于这个页面传递的所有信息都是默认信任的。

那么有没有办法防范呢?当然有,作为用户我们可以安装NoScript等插件,但是对于普通用户,这类插件非常难驾驭,因此站长应该肩负起防御XSS的责任。幸运的是,现代浏览器已经开始重视这一问题,并且实施了一系列XSS保护措施,为了防止用户关掉XSS保护,网站可以发送一个标头来强制执行XSS保护。

X-XSS-Protection:1; mode=block

这样就告诉浏览器一定开启XSS保护。不过,浏览器自带的XSS防护是针对所有网站的,为了兼容性有所保守。比如,浏览器可能会阻止跨站的请求,比如上述步骤中的4、5、7、8,但对于在网站内的行为浏览器大多不会阻止。这时就需要更严格的规范了。而这个规范就是“内容安全策略”(Content Security Policy)。

CSP是对XSS和其他安全威胁的一种有力的防范,由Mozilla于2009年推出,经过这些年不断完善,已经于去年成为W3C的candidate recommendation,已经被大多数浏览器所支持。CSP规定了一系列资源请求限制,从而约束浏览器不下载执行信任区外的脚本和资源。

内容安全策略通过Content-Security-Policy这个标头通知浏览器,每一条规则由分号分开。下面以Alex Sky的CSP规则为例,逐一介绍具体的规则用法。

default-src 'self'

这条规则是CSP的默认规则,即其他规则如没有限制则参照这条规则。这条规则限定了页面能载入的所有资源仅限当前的域名。这些资源包括脚本、图片、样式表、字体等等。如果需要更宽松的限制,则在之后的具体规则中排除。

script-src 'self' 'unsafe-inline' 'unsafe-eval' hm.baidu.com

这条规则定义了页面能载入的脚本的来源。在这里页面能载入的脚本来自于当前的域名、hm.baidu.com(百度统计)、页面当中的脚本和动态脚本。如果黑客实现注入,除非修改服务器设置,否则浏览器也不会载入存放在hack.com的恶意脚本。这条规则从根本上杜绝了XSS。

style-src 'self' 'unsafe-inline'

这条规则定义了页面能载入的样式表的来源。在这里页面仅能载入当前域名的样式表和内嵌在页面中的样式。这防止了黑客通过载入其他样式表篡改网页的呈现形式。

img-src 'self' data: http://bcs.duapp.com http://bcs.duapp.com/alexsky/ hm.baidu.com

这条规则定义了页面能载入的图像的来源。在这里页面仅能载入当前域名的图片和来自bcs.duapp.com(百度云存储)以及hm.baidu.com(百度统计)的图片。注意bcs.duapp.com前面加上了http://,这是因为CSP默认仅载入相同协议的资源,比如如果访问SSL的Alex Sky,则无法载入未加密的http://hm.baidu.com的内容,但因为百度云存储不支持SSL,所以加上例外。至于后面的alexsky路径,则是为了限制页面不要载入其他人创建的云存储的内容,但这种基于路径的规则在CSP1.0中暂不支持,所以目前的FireFox不支持这条语法,不过Chrome可以支持。

object-src 'none'

这条规则定义了页面能载入的插件的来源。因为Alex Sky仅使用HTML5播放音频视频,所以不需要引入额外的flash,所以在这里页面不允许任何插件加载,这样可以防止黑客调用用户浏览器中有漏洞的插件实现进一步入侵。

frame-src akismet.com

这条规则定义了页面能够载入的框架的来源。在这里页面仅能载入akismet.com的框架内容,这是为了方便查看垃圾评论的统计数据。禁止框架载入,能够防止黑客利用框架载入hack.com的各种资源,入侵用户电脑。

media-src 'self' http://bcs.duapp.com http://bcs.duapp.com/alexsky/

这条规则定义了页面能够载入的媒体的来源。媒体包括<audio>,<video>,<source>和<track>标签。在这里页面仅能载入当前域名以及http://bcs.duapp.com/alexsky/(自有百度云存储)的视频和音频内容。当前有些人利用audio和video标签来载入恶意脚本或者进行CSRF攻击(后文会提到),在这条规则下面就无法进行了。

connect-src 'self' hm.baidu.com

这条规则定义了页面能够连接的地址。这里主要针对的是XMLHttpRequest,WebSocket和EventSource。在这里页面仅能向当前域名和hm.baidu.com(百度统计)发送请求,其他域名的请求一概阻止,从而彻底阻止信息泄露。

form-action 'self'

这条规则定义了表单提交的地址。表单提交的规则并不能集成默认规则,所以需要单独制订。这里页面仅能向当前域名提交表单,从而防止黑客伪造表单,进行钓鱼攻击。

plugin-types 'none'

这条规则定义了允许的插件类型。与之前的object-src不同的是,这条规则不是针对插件来源,而是插件类型。在这里页面不允许载入任何插件。这样即使你的网站本身带有flash插件文件,黑客也不能调用该插件来进行入侵。这条规则还防止了“挂羊头卖狗肉”的入侵方法。

reflected-xss block

这条规则同上面的X-XSS-Protection一样,用于激活浏览器自身的XSS防护功能。只不过X-XSS-Protection是IE专有的标头,而这条规则是W3C规范。

综上,我们将规则写成一个标头的形式如下。

Header set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' hm.baidu.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: http://bcs.duapp.com http://bcs.duapp.com/alexsky/ hm.baidu.com; object-src 'none'; frame-src akismet.com; media-src 'self' http://bcs.duapp.com http://bcs.duapp.com/alexsky; connect-src 'self' hm.baidu.com; form-action 'self'; plugin-types 'none'; reflected-xss block"

这样一来,浏览器就会根据以上的规则来处理页面中的所有请求,从根本上杜绝XSS在该网站的使用。关于Content Security Policy的更详细说明,请参照W3C官方文档

CSRF攻击

CSRF攻击近年来也十分流行。CSRF全称是“Cross-Site Request Forgery”,即“跨站请求伪造”。同上文提到的XSS不同,CSRF利用了浏览器对于一个站点的历史信任,这种信任往往通过cookie的方式建立。攻击的方法既可以通过XSS在正常网站实现,也可以通过诱导用户访问黑客网站来实现。

  1. 用户访问有问题的网页hack.com,这个网页里面有一个img,video,audio等标签,来源是一个用户曾经访问过的网站weibo.com
  2. 浏览器为了读取图片,访问了weibo.com,可是这条URL并不指向一个图片地址,而是weibo.com/delete.php?post=allpost(假想网址),而这条地址的作用就是删除所有已发帖子
  3. weibo.com收到这条请求,因为浏览器发送请求的时候自动携带了weibo.com的cookie,所以验证通过,weibo.com删除了该用户的所有帖子

当然,这一切都在用户毫不知情的情况下发生。可以看到,相比于XSS,CSRF攻击更加简明,一条恰当的请求,就能完成这次攻击。

防御CSRF,从用户角度需要安装NoScript等插件,并阻止跨站的POST请求。不过更有效的方法是在服务器端。目前比较流行的防御方法有三种。

  1. 验证Referer标头,因为目前的主流浏览器都不允许任何人修改Referer标头,所以验证Referer标头能够确保请求来自于信任的页面。不过有一些老式浏览器如IE6可以修改Referer,这就需要我们网站管理员避免使用IE6等老式浏览器登陆任何网站。
  2. URL token,通过设置URL token来唯一确定用户。但如果黑客知道了token的算法,则该方法无效。
  3. 自定义Header token,只适用于XMLHttpRequest,实施难度大,局限性较大。

这三种方法中,第一种实施最简单,而且幸运的是WordPress已经帮我们实现,所以不需要做额外防护。上文提到的CSP中的connect-src规则,可以防御黑客通过XSS操纵我们的终端用户访问其他网站。而站长只要注意不要使用过时的浏览器登陆自己的WordPress,就能防御CSRF。关于CSRF攻击与防御的更多细节,可以参考这篇文章这篇文章

点击劫持

点击劫持(Clickjacking)是2008年开始的一种新型的Web攻击方式。黑客诱导用户点击某一个按钮,但在该按钮处内嵌了目标网站的一个框架。当用户点击该按钮时,其实点击的是目标网站的目标按钮。具体攻击方法如下。

  1. 黑客在其控制的网站hack.com上制作一个小游戏,有一个按钮是开始按钮
  2. 黑客在hack.com页面上用框架形式载入正常网站weibo.com
  3. 黑客通过调整CSS让weibo.com中的发布按钮与hack.com上的开始按钮在完全相同的位置上
  4. 黑客调整CSS让该框架完全透明,并处于最上层
  5. 用户点击开始按钮,实际点击的是weibo.com中的发布按钮

以上例子中只是诱使用户发布一条帖子,在真实的攻击中,黑客曾劫持用户通过Flash开启了摄像头,而用户完全不知晓。

为了防御点击劫持,浏览器会在网站的指示下,禁止载入特定的网站。而这个指示是通过一个返回标头实现的。

X-Frame-Options: DENY

这个标头告诉浏览器不要将该网页在frame或iframe框架中载入,从而避免了黑客进一步劫持用户点击按钮。如果不是DENY而是SAMEORIGIN,则允许网页在当前域名的页面中以框架形式载入。

关于Clickjacking的更多内容和防御,可以参考这篇文章这篇文章以及这篇文章

会话劫持

会话劫持(Session Hijacking)是一种古老但近年来流行的攻击手段。黑客在目标用户所处的同一网络进行侦听,记录用户和网站的明文通信,截取cookie,并用该cookie直接登陆目标用户使用的网站。

会话劫持影响的范围非常广泛,所有使用80端口(http://)的网站都是潜在目标,而适用的网络包括有线和无线网。2010年Firesheep的发布,让会话劫持的门槛大大降低,风险大增。公开的WIFI,WEP,WPA/WPA2-PSK,对于会话劫持没有防护。唯一不会被攻破的WPA/WPA2-Enterprise适用范围小。而据我实测,新浪微博和人人网对会话劫持没有任何防护。换句话说,在公众场所浏览这些网站,等于将自己的隐私公开告诉附近的人。

从用户的角度,几乎没有好的防范方法,除非不在公共场所上网或使用VPN。但作为站长,我们应该为用户的隐私安全负责。从技术层面,防范会话劫持最根本和最简单的方法就是使用SSL/TLS加密通讯。对于WordPress来说,我们主要需要保护的就是我们自己,也就是说我们登陆和管理自己的网站,需要加密通讯。

SSL/TLS需要花钱?不需要,对于我们个人站长来说,开启这种安全不需要花费任何钱。以下是步骤。

  1. 申请一个证书,极力推荐Let’s Encrypt,免费而且可以认证。申请方法见这篇文章
  2. 配置Apache或者Nginx,对于Apache可以将自己的site configuration文件拷贝一份,命名为yoursite.ssl.conf,然后打开修改。将端口从80改成443,然后在VirtualHost中加上如下的设置。
SSLEngine on
SSLProtocol ALL -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM
SSLCertificateFile /etc/apache2/ssl/ssl.crt
SSLCertificateKeyFile /etc/apache2/ssl/private.key
SSLCertificateChainFile /etc/apache2/ssl/sub.class1.server.ca.pem
  1. 最后别忘了开启SSL模块,然后重启Apache
sudo a2enmod ssl
sudo service apache2 restart

这样我们就为网站开启了SSL/TLS。不过,默认状态下,如果在浏览器地址栏中输入网址,浏览器默认会先连接HTTP,这样登陆仍然无法做到通讯加密。因此第二步需要启用WordPress安全管理。启用方法很简单,在wp-config.php里面加上一句。

define('FORCE_SSL_ADMIN', true);

如果按照我上篇文章的方法设置了Varnish缓存,还需要加上一句。

if ($_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https')
       $_SERVER['HTTPS']='on';

这样WordPress就会将Admin区域保护起来,建立secure cookie,只有当确定SSL/TLS连接建立时才会发送secure cookie。

如果连普通的cookie都不想泄露,实现完整地加密通讯,可以发送HSTS指令让浏览器今后自动切换成SSL/TLS访问你的网站。方法是在站点配置中加入以下内容。

Header set Strict-Transport-Security "max-age=31536000; includeSubDomains"

这样一来,在接下来很长时间内,浏览器将仅允许SSL/TLS通讯。该项设置适用于Chrome和FireFox。通过设置SSL/TLS,我们就能较好地防护会话劫持。不过近年来,道高一尺魔高一丈,各种针对SSL/TLS协议本身的攻击开始出现。

BEAST攻击

BEAST攻击,全称“Browser Exploit Against SSL/TLS”,是一种针对SSL3.0/TLS1.0使用的Block Cipher的暴力破解,由Thai Duong与Juliano Rizzo于2011年发布。该攻击通过XSS注入脚本启动Java Applet,然后通过不断尝试新的请求来最终破解加密。抵御BEAST的方法是采用TLS1.1和TLS1.2,不过这两种协议目前的支持范围还不多,另一种方法是禁用Block Cipher而采用Stream Cipher比如RC4。不过RC4在后来的攻击中也被证明有漏洞。幸运的是,目前的主流浏览器已经能够免疫BEAST攻击,所以不用太担心这个攻击

CRIME攻击

CRIME攻击,全称“Compression Ratio Info-leak Made Easy”,是一种针对SSL/TLS传输压缩的暴力破解,同样由Thai Duong与Juliano Rizzo于2012年发布。该攻击通过尝试向服务器发送不同的请求,并嗅探返回内容的大小从而判断cookie的内容。抵御方法是禁用SSL/TLS压缩。幸运的是,目前的主流浏览器已经能够免疫CRIME攻击,所以也不用太担心。

BREACH攻击

BREACH攻击,全称“Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext”,于2013年推出,是CRIME攻击的升级版,攻击方法和CRIME相同,不同的是BREACH利用的不是SSL/TLS压缩,而是HTTP压缩。所以要抵御BREACH攻击必须禁用HTTP压缩。而这在当下看来是弊大于利,因为HTTP压缩是性能优化的重要手段。所以到目前为止,我们还没有什么能够防范BREACH攻击的有效方法。还好BREACH的前提是XSS注入,而这一点可以用之前提到的CSP来抵御。

除了以上几个比较著名的针对SSL/TLS的攻击外,还有一些其他攻击,不过我们没有太多好担心的,因为这些攻击目前只是在理论阶段,要实施起来需要其他攻击手段,如XSS何CSRF的配合,而这类传统攻击手段我们目前都能有效防御。

不过,最近NSA的监控门闹得沸沸扬扬,我们担心如果有类似NSA这样的机构监视了所有加密的通讯,如果在未来某一天他们破解了密匙,就能顺利读取之前的加密信息。因此安全人员提出了Perfect Forward Secrecy(PFS)的概念。

PFS是指采用特殊的cipher suite,保护session key,即使long-term key被截获,也无法推导出session key,从而彻底保护之前的通讯记录。目前只有两种Cipher Suite实现了PFS加密——DHE(Diffie–Hellman Exchange)以及升级版的ECDHE(Elliptic curve Diffie–Hellman Exchange)。具体的细节可以参考这篇文章。目前版本的Chrome和Firefox已经支持ECDHE,而大多数主流浏览器已经支持DHE。不过DHE对于SSL性能的影响比较大,所以应尽量升级到ECDHE。实现ECDHE需要OpenSSH 1.0以上,Nginx,或者Apache2.4。Apache2.2只能支持DHE。

可以通过指定Cipher Suite的顺序来实现PFS,在Apache的站点设置里添加如下内容。

SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 \
EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 \
EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS"

更新:Nginx的Cipher Suites设置如下:

ssl_ciphers "ECDH+aRSA+AESGCM ECDH+aRSA+SHA384 ECDH+aRSA+AES256+SHA ECDH+aRSA+AES128+SHA DH+aRSA+AES256+SHA";

Nginx的配置文件中,我取消了对Windows XP平台IE6和IE8的支持,因为随着微软取消对Windows XP的支持,这个平台会变得越来越不安全。此外Java6也是不支持的。

因为WinXP下的IE6-IE8不支持PFS,所以只能退回RSA_RC4的方法。参考这篇文章

想知道自己网站的SSL/TLS设置是否安全,可以通过SSLLab的网站进行测试。测试地址为:https://www.ssllabs.com/ssltest/。Alex Sky的测试结果见此处,可供参考。以下为结果截图:

ssl_rating

到此为止,我已经介绍了许多方法防范目前主流的网络攻击威胁。通过这些方法我们可以让网站更加安全,同时更加保障用户的安全和隐私。这篇文章由于篇幅限制,无法包括所有的攻击种类,也还未涉及到WordPress本身的安全性。关于WordPress本身的安全性,可以参考官方提供的文章《Hardening WordPress》,这是我觉得最完整和权威的WordPress安全指南。安全是永无止尽的追求,欢迎大家提供想法,让我们一起打造安全的网络环境。

Leave a Reply

Your email address will not be published. Required fields are marked *