**网站内容管理系统(CMS)** 自诞生之日起，便是网站建设的一个重要领域。CMS 以其丰富多样的功能和简单易用的操作，有效地解决了用户网站建设与信息发布中常见的问题和需求，一直深受众多使用者的青睐。 　 正因如此，利用 CMS 对网站进行渗入，也就成为危害网站的常用手段之一。无需太多复杂的技术手段，只需登录网站 CMS，便可方便快捷地植入暗链和上传 WebShell。然而，大部分网站的安全防护策略会将 CMS 的各项功能列入白名单，或者说，来自 CMS 的操作其恶意与否通常难以辨别。 　 同时，部分网站的管理者贪图方便，经常将 CMS 入口直接暴露于网站首页。 　 有**明目张胆**型的： 　   ▲后台入口常见位置 　 也有下面这种**此地无银三百两**型的： 　 ```css 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 了，还有解决办法吗？答案是肯定的。不过，我得先去向老师们汇报网站安全问题了。 　 欲知后续，且听下回再叙。（张旭 | 天存信息）