发布日期：2012-07-03
http://security.tencent.com/index.php/blog/msg/2 xti9er [TSRC]
前言
由于之前工作需要，笔者经常接触一些业界安全产品，对其性能、安全性等等的分析自然是关注的重点。好的地方自然要学习，如果有缺陷的地方则值得我们自省，看自己的系统和产品是否也会有这些问题呢？
鉴于商业产品的保密性，将隐去部分敏感内容。
产品分析
产品简介
某安全产品
产品架构
程序： W eb 管理界面 + 后台服务。
网络：可串联或并联于网络中，管理通过 web 接口或自定义的 console
探测分析
通过简单的扫描分析，其 web 前端采用的是 Apache+php+DB 架构。
安全性测试
帐户安全
虽然此产品我们能见到的只是一个‘铁盒子’，但通常能猜测到，它其实就是一个 linux 系统加自研的安全产品的形式。
它提供了 console 模式的管理， web 管理用户和 console 账户是同一个，我们发现如果添加的账户名为 root 会失败，基本上能证明他是 linux 系统。
除 root 之外的普通用户登陆后，出现的是一个自定义的 console 界面，不是 bash 。
在这里给大家提个醒：类似的铁盒子 ( 安全产品 ) ， root 账户和密码是没有提供给用户的，也就是说开发商知道你的产品的 root 密码 ，如果将其架设在一个外部用户能访问的地方，可能会导致开发商有机会登陆你的系统。就算开发商很有良知，员工不会违反职业道德，也不排除它同类产品 root 密码可能一致，此商家的其他用户获知此密码用于尝试您的系统的可能性。 所以此产品或管理端口，必须设置为外网不能访问，且内部员工仅有有限的访问权限 。
web 安全
此产品提供 web 管理界面， web 类安全问题常见的是 2 种： 1 、注入； 2 、 xss 跨站。
S ql 注入 自不必说，可修改 DB 数据。一个依赖 DB 数据进行运转的系统来说， sql 注入的危害已经是非常大了。
命令注入 是指某些需要将用户输入的数据作为命令的一部分时，未对数据的合法性作校验，导致恶意用户可以随意构造命令执行。
X ss 跨站 问题，大家觉得在一个后台维护类系统上问题不大。其实不然，如 果一个低端用户 ( 来宾访问、厂商例行查验 ) 利用 XSS 的 ajax 方式，可将自身的权限提升至受害者用户一样的权限。
通过简单的测试，发现一处很明显的 sqlinject 漏洞 ：
GET /server/ip_edit.php?id=1;select version();
从架构缺陷到 系统 权限
如果仅停留在 web 漏洞上，大家显然觉得不过瘾。下一步我们来看如何得到整个系统的权限。显然用 linux 系统 exploit 不太可能，厂商的补丁齐全，且无 gcc 环境。只能改由其他途径。
对于架构的思考 ： 一个 web 系统，通过添加 web 账户，能使其账户也添加到系统账户中去，他是如何做到的呢？
我们暂且作 2 个假设，然后做相应的尝试和探索，或许能绕过安全防范获得 root 权限：
a) webserver 是 root 权限
b) 通过 db 数据或其他媒介，让一个具有 root 权限的后台程序来自动完成添加操作。
前面的 sql 注入漏洞，使我们已经能访问其文件系统和执行系统命令。通过读取此产品的后台系统代码。发现了确实是上述的第二个猜想。
我们在后台系统代码中发现命令注入漏洞，而后台进程是 root 权限启动的，通过 sql 注入漏洞结合某来至 db 的参数的命令注入漏洞，继承了后台进程的 root 权限。
S o ，一切都结束了。
总结与思考
对于以上产品的分析，我们总结一下它的问题。
利用 sql 注入漏洞，攻击者获得继承了 webserver 权限
利用后台系统命令注入漏洞，攻击者获得继承了后台系统的 root 权限
由此可看出，要想 建设 一个安全的产品和系统，权限的隔离是关键 。但如何能做到权限隔离呢，从以下几个方面：
网络隔离。 再 NB 的系统他都或多或少有些毛病，更何况是一些运维类高敏感系统。做好隔离，可以最大限度的将可能存在的风险降低到最小。
严格校验数据输入。 严格校验数据输入应该是开发人员的常识，对任意一条数据来源都要假设他是‘不可靠’的， 即使它来至内部系统 。
最小权限原则 。 最小权限原则也是一种隔离的思想，假设你的系统也不是完美了，可能会出现瑕疵和漏洞。如果它运行在较低权限，就算出现任何安全问题，也不会导致系统最高权限被入侵者拿到。
相信从网络、主机、代码三个层面的纵深防御，您的系统将更加安全可靠
查看更多关于从对一个安全产品的测试看产品架构安全 - 网站的详细内容...