个人在使用WordPress时往往没有企业那么规范系统的安全措施, 往往是wget下来解压以后一扔就开始运行了. 个人能够利用的资源有限, 虚拟主机甚至VPS上放个驱动级的东西在那轮询文件和数据库在今天看来即使可为, 也是不现实的. 对于个人来说, 被拿个shell其实没什么大不了的, 只能从另一个方面证明你的价值, 但如果你没有bt到每种在线服务都使用不同的密码, 那么密码的丢失就显得不那么好玩了; 对于生产环境, 两者都很不好玩. 表面上, WP是很安全的, 但在某些方面, 还是不那么让人放心. 这里主要从WordPress的设计上, 简单总结一下加固自用WordPress的几点基本想法. 不妨认为和WP有关的安全隐患主要在三方面:
- webshell问题
- 文章数据的安全
- 个人信息的安全
三方面的确有一定的相关, 但又各有特点. 这里不做细分, 仅仅从几个具体的防御角度展开.
不被拿webshell, 基本上仰仗于WordPress自身的安全性, 但作为个人用户, 从源代码上彻底审计和加固整个WP是几乎不可能的事情, 估计只能做到勤升级了. 这年头0day也是需要产生经济利益的, 所以如果你没有很高的商业价值, 那么应该不会怎么为未公开的漏洞所扰. 由于翻译问题, WP中文版的发布总是有一定延时, 所以最好使用英文版. 其次, 将后台有利于写入webshell的功能彻底移除, 例如在线上传/在线安装插件的功能, 在线修改主题文件的功能, 都为直接写入webshell提供了可能. 第三, 尽量少装插件——虽然对于WP来说插件意味着几乎一切. 最小的服务等于最大的安全, 这话很实在. 即使用插件, 也尽量不要用冷门的, 更新频率、rating很低的插件. 对于已经安装的插件和主题, 尽量审计所有代码.
写到这里, 不得不吐槽WordPress一个十分坑爹的地方, 那就是wp-admin这个目录的名字很难修改. 程序里硬编码的地方实在太多 ... 即使你以暴制暴, 强制涂改掉所有wp-admin字样, 一升级还得重新改, 官方还不提供增量升级得自己diff, 真是ooxx. 所以要做定制, 这个地方是无法绕开的, 这个设计的改进也大有可为.
如果你绕开了这个问题, 更深入的想法还是有的. 比如桂林老兵以前实践过的的一个思路, 那就是设计一个C-S的登录方式, 如果我没记错的话, server端的登录接口似乎是隐藏在flash里, 没有client, 第三方根本不知道怎么进后台 ... 虽然这个思路比较极端, 不过还不算惊世骇俗, 完全可以实现. 不过这年头, Zend都被攻破, 隐藏这件事大概也没什么十分靠谱的选择.
如果出现注入一类的漏洞, 也许可以得到用户的的密码散列, 这对个人是一个不容小觑的威胁. 什么, 你还不知道CMD5? 以下一段为zz:
WordPress用户密码产生的过程是, 当需要生成用户密码的时候, 随机产生一个salt, 然后将salt和password相加, 再进行count次md5, 最后和encode64的hash数值累加, 就得到了一个以$P$开头的密码, 这个密码每次产生的结果都不一样.
虽说是这样, CMD5仍然提供了WordPress/phpbb3这种加密类型的数据, 简单试了一下, 成功率还是不低的. 根源就在于这个算法是公开的, 谁都可以就此生成一个彩虹表. 我们不妨另辟蹊径, 定制一个独有的MD5算法. MD5算法中间有一些默认参数, 也就是所谓的Chaining Variable部分, 简单的修改这些参数就可以得到和原始算法不同的加密结果了. 这时即使数据库中的MD5散列被获取, 用字典也是无法查到这个散列的, 从而也就保证了个人信息的安全. 当然, 在数学上, 这种修改可能导致更容易出现不同的密码在MD5后结果相同的情况, 不过作为自用, 还是完全可以接受的. 不多说了.
以上述idea为核心继续拓展, 不难做成一个WP安全定制版.
引一段《Inception》作结:
What's the most resilient parasite? Bacteria? A virus? An intestinal worm?
—— An idea. Resilient, highly contagious.
A single idea from the human mind can build cities.
An idea can transform the world and rewrite all the rules.
