网站内容管理系统(CMS) 自诞生之日起，便是网站建设的一个重要领域。CMS 以其丰富多样的功能和简单易用的操作，有效地解决了用户网站建设与信息发布中常见的问题和需求，一直深受众多使用者的青睐。
正因如此，利用 CMS 对网站进行渗入，也就成为危害网站的常用手段之一。无需太多复杂的技术手段，只需登录网站 CMS，便可方便快捷地植入暗链和上传 WebShell。然而，大部分网站的安全防护策略会将 CMS 的各项功能列入白名单，或者说，来自 CMS 的操作其恶意与否通常难以辨别。
同时，部分网站的管理者贪图方便，经常将 CMS 入口直接暴露于网站首页。
有明目张胆型的：
▲后台入口常见位置
也有下面这种此地无银三百两型的：
User-agent: *
Disallow: /d/
Disallow: /e/class/
Disallow: /e/config/
Disallow: /e/data/
Disallow: /e/enews/
Disallow: /e/update/
▲某CMS系统默认的robots.txt文件
当然，也少不了这种欲盖弥彰型的：
▲换个名字我就不知道你是后台了吗？
于对手而言，暴露的后台入口如同黑夜中的灯塔，为侵入网络指明了方向。只需一组管理员（或仅为高权限编辑者）的账号密码，网站服务器便轻而易举被拿下。若 CMS 同时存在 SQL 注入漏洞，用户使用弱口令甚至明文保存用户名密码，抑或验证方式过于简易等诸如此类的问题，只能让对手仰天长啸：
天呐 !
简直瞬间拥有武林两大绝学
一阳指 + 狮吼功
即视感 !
不要以为这只是坊间笑谈的故事，来看一个真实的事故——
案例网站的首页醒目标明“后台入口在此，速来”，甚至还有注册功能（尝试后发现并未开放注册）。敌方的尝试方向已相对明确——寻获可登录的账号密码一组。
随即点开一篇新闻内页，发布者看起来长得很像用户名。
尝试登录后，查看错误提示：这个用户使用的是弱口令，直接登录成功了！
从 CMS 来看，管理成员的权限划分也十分粗糙，其他高权限用户的信息发布情况一览无余。更可怕的是，高权限用户也使用了同一弱口令。
以此案例可见，暴露的 CMS 入口、显而易见的用户账号、弱口令，带来的后果不堪设想，简直是为心怀恶意者敞开了自家大门。
然而，灾难远未就此终结……
我们可以从网站的 whois 信息、首页的版权信息、友情链接以及搜索引擎里顺藤摸瓜，找出使用相同 CMS 的网站。相同的 CMS 往往意味着相似的安全隐患，比如下面这个：
从新闻内页来看，管理者使用了昵称字段，看似避免了后台用户名的泄漏，可是网站偏偏画蛇添足，多出了个用户信息展示的功能，后台用户名还是暴露在外。
利用这个不知为何存在的功能，可以遍历出后台所有的用户名。再加上 CMS 简单的登录验证，后台爆破变得异常容易，剩下的只是时间问题。
从用户 [==aaaaaa==] 是一位超级管理员这一点，就足以令人相信，这个 CMS 后台还存在更多更严重的问题，网站服务器恐怕早已千疮百孔。
一个暴露的 CMS 不仅要抵御各种注入，还要抗住各种暴力破解，更有社会工程学防不胜防。在现今的互联网环境下，很难判定网站的访问者是否怀有恶意。作为网站的管理平台，CMS 使用者主要是网站的管理人员，如果仅为了方便，便将其暴露于互联网之中，将会极大地增加网站的信息安全风险，实非明智之举。在 《国务院办公厅关于印发政府网站发展指引的通知（国发办〔2017〕47号）》 中，就明确要求“前台发布页面和后台管理系统应分别部署在不同的主机环境中，并设置严格的访问控制策略，防止后台管理系统暴露在互联网中”。
倘若我们的网站已如文中案例，由于各种原因很难再分离 CMS 了，还有解决办法吗？答案是肯定的。不过，我得先去向老师们汇报网站安全问题了。
欲知后续，且听下回再叙。（张旭 | 天存信息）
