DOMINO服务器的攻击与防范

以下内容并不是教你怎么攻击服务器，而是教你怎么防范自己的Domino系统。所有因为本文而造成的损失与作者无关。
    首先，我们知道Domino在可以运行在多个平台下，例如LINUX、UNIX、WINDOWS等，很多情况下在服务器的操作系统中存在着多个用户，而恰好如果某个用户可以访问并能修改在操作系统下的数据库的话，那么Domino自身的校验机制将没有任何作用，这一点实际上很容易理解，就如同我们在本地修改数据库的ACL。所以首先第一点、确保你的Domino所在的目录只有相关人员可以进行访问。Domino系统的安全的大前提是服务器的操作系统的安全。
    其次，我们在使用Domino的时候，经常会修改一些模版，如DOMCFG.NSF，Mail50.NTF等，这些数据库、模版的缺省DEFAULT的权限就是编辑者的，也就是说：我们可以达到修改模版的目的来修改数据库！说到这里，各位应该心里有数了吧？也就是说，Domino自己的用户，即使不是管理员，也可以修改数据库的。
    第三、我们来看看NAMES.NSF这个系统配置库。只要你有一个用户名，你会发现，你可以看到服务器的配置信息。也就是说，为什么网上的那些提供 测试用户的数据库安全性很低的原因了。至于具体方法，我就不在这里多说了。解决办法，所有的关系的配置的视图，用缺省的页面来显示，假设是people这 个视图,我们建一个页面 $$ViewTemplate for (people)来显示视图，在这个页面的ONLOAD事件里面用JS直接关闭就可以了，这样用户将不可以通过WEB来访问视图，也不可以从视图上把用户 的ID拆离下来了。
    第四、文档删除的权限控制，各位可以检查一下自己的系统，用一个没有删除权限的用户点开文档，在地址栏里通过？deletedocument参数来试试看能不能删除文档
    我第一次破掉人家的服务器
    ……
    直接打开domcfg发现，居然得到了视图。找到表单映射文档使用urlcommand编辑、保存。发现居然ok 。
    想到这个服务器肯定配置不专业，开一些系统数据库，names要登陆，admpassword，没有通过，再猜没有通过。
    再开其它数据库发现domlog不要登陆，很好。看到很多账号的使用情况。得到很多用户名，终于有一个用户名的password被猜到。
    登陆成功，东翻翻西翻翻，留一条记录玩玩。
    发现有个表单可以修改密码，有趣。发现这个表单不用输入旧密码。又发现用户在names中个人文档的管理员是adm。看来改密码的后台代理不是以当前用户，而是以管理员的。
    可以想象程序的过程：在表单(note级别)上设置字段记录用户名和密码，后台代理找到该用户文档，再用@password(新密码)重设，保存。
    很好，看来只要能向后台代理发送伪装的请求即可。也就是把用户名伪装，就ok。查找页面（html级别）源文件发现没有用户名的字段。看来用户名的字段是在notes中隐藏或者计算的。
    ok，根据webpage前台优先，只要在改密码表单（html级别）用js新建一个field（怎么建？），能让其名字和记录用户名的notes字段相同，就能骗过后台代理，让它认前台的用户名。这个想法被我自己的程序验证。
    介绍怎么在用js改密码表单的（html页面级别不是notes设计级别）。
    用桢结构集index，一个桢head放自己的页面page1，另个桢main放该表单pagepsw。page1用js访问psw发现没有权限。原因可能是两个页面不在一个站点。
    发现该站点有一个数据库可以上载附件，很好。把我的page1上载。再修改index。发现page1可以用js访问pagepsw。
    写创建字段的js代码。
    var newInputName=document.forms[0].T1.value
    var newInput =parent.frames[1].document.createElement("input")newInput.name =newInputName
    newInput.type="text"
    newInput.value="adm"
    parent.frames[1].document.forms[0].appendChild(newElem)
    呵呵，用我的T1再慢慢试用户名的字段名，无非是use、name、username、curname、Remote_User……什么的。反正试成了会有确认信息
    哈哈，终于猜到。于是adm密码就由我设了。至此，破解过程结束。总结下来主要是服务器配置不太专业，才有所得逞。