jxTMS设计思想之安全

jxTMS是以低成本快速定制为核心诉求的、SaaS模式的二次开发平台，详见：jxTMS简介。本文是讲述jxTMS平台中安全防护是如何设计的，整个系列请访问：jxTMS设计思想

信息系统安全从来都是一个系统化的、人机协调的体系。所以作为一个以低成本快速定制为核心诉求的二次开发平台，jxTMS关注的是基本安全、开发者约束和安全成本、最大化业务支持能力之间的平衡，秉持以低成本来实现合理的安全。

在确保能力足够的前提下，所有设计都尽可能的简单。因为：简单才容易理解、简单才容易实现、简单才容易检查、简单才容易发现问题。

权限漏洞

jxTMS采取了最简单的角色模式来管理操作权限，配合前后两道检查点【依据权限显示入口、入口触发时核准后放行】，因此操作权限的安全问题是非常牢靠的、也是简单不容易出错的。

所以相关的安全措施其实主要是组织的管理方精心设计组织架构、职能划分、权责匹配，然后对实现后的操作权限认真核对。同时做好对业务逻辑的审核与测试。

但有一个难点就是流程。在流程中有两个问题涉及到权限漏洞：

1、为了降低开发者制作两个流程界面【一个用于操作、一个用于查看】的制作成本、维护成本，所以jxTMS采用了用遮罩遮挡的方式只需制作一个界面来降低制作和维护成本，但由于jxTMS的web界面是动态生成的，所以整个流程显示界面的过程是：

• 后端向前端发送界面的json描述，由前端根据此json描述来绘制出界面

• 后端异步的、稍微延迟一下，以等待前端绘制完该界面，然后触发该界面的prepareDisp事件，来给该界面中的各控件装定数据

• 由于加载数据后，各控件的大小由于所填充的数据量不同而可能会有变化，所以必须等待一段时间后，才能用遮罩来遮挡，否则会出现遮罩未能完全遮挡住的情况

这时，如果某个用户眼疾手快，就可能在遮罩未遮挡前就点击后继某个领导对应的审批子界面中的确认按钮！

针对这个情况，所有的按钮和工具条在刚绘制完毕后都默认不可操作，等这个遮挡时间段过后才会放行点击动作。

2、大家都知道，所有图形化界面中的控件都有个焦点的概念，即当前界面中是哪个控件处于输入状态。控件的焦点可以通过点击取得，也可以通过不断按下tab键顺序取得。

这就麻烦了，某个用户完全可以通过连续按tab键将焦点切换到被遮罩遮挡起来的某个领导的意见栏后输入：同意，支付一万；然后再按tab键将移动到【同意】按钮，再敲下回车键，就完成了一次权限漏洞的攻击！

由于jxTMS中各界面都是动态生成的，所以jxTMS最终采取了一个非常简单的解决办法：取消tab键移动焦点的能力。

因此，大家只能通过鼠标来切换焦点了，但好在高效的业务软件不会需要用户大量的键盘输入、尤其是频繁的在多个输入控件间切换焦点，而是通过鼠标点选来提供标准的、高效的输入。

web安全

web的安全是jxTMS安全体系的重点，首先面临的就是选择什么样的web服务？

jxTMS设计的目标，是要能以多种形态【包括安装包、docker、云服务器市场镜像、SaaS模式等】提供给所有有兴趣的开发者使用。那安装web服务、配置web服务，而这些web服务都还有着各种各样的bug需要不断的打补丁，这对开发者的要求较高，显然不利于低成本的维护。

所以思来想去，笔者最终在jxTMS平台中用java开发了自己的web服务，这除了可以大幅度降低开发者在web服务方面的成本外，还带来了一个额外的好处：作为自行开发的、封闭的、只针对jxTMS所需提供有限能力的专用web服务，天然免疫于外部对web服务的攻击。

jxTMS自行开发的web服务，是REST的，而除了注册、登录等极少数接口外，其它接口都需要登录用才能访问。接口基本都是json格式的数据交换，不存在安全问题，只有一个接口会根据入口参数来触发事件响应函数，但这些函数还要受到权限的控制。

所以通常的web攻击对jxTMS来说都是无效的，这是因为：

• jxTMS对这些web攻击来说是完全的黑盒

• 大部分接口需要登录

• 登录后的绝大部分接口都是数据交换

• 唯一一个可触发事件响应函数的接口其调用哪个函数还要受到权限的限制

所以web安全完全依赖于用户身份，而用户密码的保管则属于社会性控制范围。

随之而来的就是选用http协议还是https协议。从安全的角度考虑，当然是选择https协议了。笔者一开始也同时实现了这两者，但随后出现了几个问题：

• 首先是笔者发现在unix服务器上配置https证书非常复杂

• 其次是19年左右，各主流浏览器都取消了对私有证书的支持，这也就意味着开发者不但要购买证书、准确填写那些证书信息等高成本动作；还意味着笔者编写一个shell程序自动在服务器上完成https支持的所有努力全部白费了:(

• 各组织可能想用自己的域名，那当jxTMS以云计算的方式向多个组织提供服务时，支持https协议的成本就更高了

所以，笔者最终取消了对https协议的支持。

取消https那不就裸奔了吗？！但笔者思来想去，认为问题不大，因为有两个原因：

• 我们可以自己用RSA加密通信过程

• jxTMS的界面是动态生成的，除了开发者，没人知道web服务器返回的这一坨json串是干什么的，而如果是开发者的话，作为管理所有模块的上帝，其只要在入口上加个角色，什么都能看到！没必要这么low的去自己解析json串

注：对开发者，jxTMS是无条件信任的，对开发者的安全管控是依靠社会控制、依靠法律威慑、依靠人际约束

目前，考虑到性能、成本等方面的因素，jxTMS并未采用RSA全程加密。但有个东东却必须要用RSA加密，那就是登录，因为登录接口需要传递用户输入的明文密码！所以jxTMS特意针对登录过程，采用了RSA加密。

注：目前jxTMS不考虑整个通信过程全部启用RSA加密，但未来不排除全程用RSA加密

取消了对https的支持，就可能存在一个攻击：http劫持。即wifi路由器厂商等中间通道设备，通过对http协议的监视，在原本的页面中添加自己的广告弹窗。

但这个问题却在无意间被削弱了，起因是笔者的开发机是Ubuntu，而unxi系的系统要监听1024以下的端口需要root权限，所以在开发、测试的过程中，jxTMS的web服务端口都做成了可配置的，而且笔者一般都给配置到了一万号以上的用户端口区。

在上线测试过程中，由于发现了时刻有着对80端口的各种扫描、尝试性攻击，笔者反复思考后认为避开80端口而使用这样的用户端口也不错。反正作为业务系统，用户第一次打开网址都是通过点击用户手册之类说明中的链接的，而且以后也都会保存到常用的收藏夹中直接使用。所以换用一个其它端口问题不太大，而单是免除掉的各种扫描响应就可以给服务器降低很大的压力了。

同时，由于不采用80端口，也间接的避开了上述的http劫持。

注：jxTMS在web方面的发展应该逐步从现在的：http+RSA加密登录过程+用户自定义端口，先演进为：http+RSA加密全过程+用户自定义端口，最后是：https+80端口

组织间隔离

jxTMS是一个SaaS模式的二次开发平台，那就意味着在同一台服务器中可能会同时存在多个组织，那么非常现实的问题就来了：

• 组织之间的数据是否安全？

• 一个组织是否会受到同机另一个组织的干扰？

第一个问题就是组织间的隔离问题。针对这一问题，jxTMS提供了一个基础的部件：ORG。其中汇聚了所有本组织相关的数据：

• 组织结构相关的：人员、部门、角色等

• 业务逻辑相关的：模块、capa、数据源、数据类、capa、简易流程、业务规则表、兴趣点等

• 权限相关的：入口、入口-角色对应表、权限、授权等

• 私有数据库相关的：本组织所对应的私有数据库的相关信息

• 微信机器人相关的：本组织启动的微信机器人【对应企业微信中的机器人应用】、活跃的企业微信用户会话、已经注册的所有微信目录

由于ORG汇聚了本组织所有相关数据，也是访问本组织私有数据库的汇合点，我们限制了只能通过上下文来访问本组织的ORG对象，也就实现了组织间的隔离，即一个组织的开发者只能访问本组织的相关信息以及私有数据库。

个人开发者的能力限制

组织间隔离可以防止组织信息与数据的泄露，但由于多个组织运行在同一台服务器上，如果有开发者恶意攻击，虽然其无法威胁其它组织的数据安全，却可以通过破坏该服务器的正常工作导致其它组织也失去响应。

针对这一问题，jxTMS的思路是限制一般性开发者的能力，使得其失去相应的破坏能力。

就SaaS模式来说，jxTMS和开发者是共生的关系，所以jxTMS对开发者是无条件信任的，因为代码是开发者编写的、角色对应的权限是开发者定义的，从这两点来说，用jxTMS开发的管理系统，在单个组织层面，其开发者拥有除数据访问权之外的最高权力。

所以，对开发者的约束，是要依托社会来实现的，即使用jxTMS的组织对开发者要以合同、法律、人际等方方面面的约束来规范开发者的行为、并监督、管理、控制其履职过程。

但任何事情都要辨证的看，开发者应配合jxTMS来建立自己的开发、测试规范以确保所服务的组织的信息系统安全。但jxTMS也必须考虑到万一真有恶意的开发者采取极端措施发动自杀性攻击，也要限制其破坏范围和损失：

1、逐步提供代码的版本管理和数据库备份服务，以此缩小损失

2、限制开发者的能力，使得其破坏范围局限在本组织内

也就是说，在jxTMS的整体规划中，开发者是分等级的，一般的开发者，其能力是受限制的。

这里的限制包括两个方面：

1、限制扩展范围

jxTMS是二次开发平台，其二次开发使用的是python语言，而python可以通过导入各种内部模块、第三方包来提供强大的扩展功能。

所以jxTMS限制了用户模块的导包能力。在加载用户模块的capa.py文件时，会将import语句全部删除掉，然后拼入一个经过整理后的导包列表，从而限制了开发者只能使用python自身的基本能力和jxTMS提供的包【目前处于保密状态，只有经过大规模使用后才会逐步公开】，从而将开发者局限于jxTMS平台所提供的各种工具来开发业务系统，避免开发者使用无关的能力。

为了避免开发者绕过jxTMS的这一限制，jxTMS还删除了用户代码中的exec、eval等语句。

2、死锁检测

为防止开发者用for或用其它方法制造死锁来消耗系统资源，导致同一服务器的其它组织失去响应能力。所以jxTMS会对用户的事件响应函数执行死锁检测。

原理非常简单，通过限制开发者能力，使得开发者不能创建异步程序或线程，只能同步执行事件响应函数。所以jxTMS要求用户自定义的事件响应函数必须在一个固定的时间段内结束，否则就被认为已经出现死锁，当其超过最大允许存活时间后，其所在线程会被直接杀死。

当一个组织出现10次死锁现象，则该组织就会被自动关闭。

综上，jxTMS以简单、可靠为基本原则建筑起自己的安全防线，在提供完善的业务系统开发能力的前提下确保了足够的安全防护能力。

目前jxTMS已经开放个人注册试用，欢迎大家注册试用：

注册到jxTMS

下面的系列文章讲述了如何用jxTMS开发一个实用的业务功能：

如何用jxTMS开发一个功能

下面的系列文章讲述了jxTMS的一些基本功能：

jxTMS的HelloWorld