在分析了我们产品近一年的所有安全问题单后，我得到了开发最容易犯错同时稍加注意即可改善的17个改进点。
- 敏感信息泄露
描述：用户未脱敏的信息，比如手机号，银行卡cvv号等。不允许在日志中明文显示。明文密码，密钥。SQL。堆栈信息不允许打印在页面中。诸如此类。页面显示的信息尽可能少的显示详细信息。使用的组件版本号。
目的：保护用户隐私，避免透露信息过多被人利用找到容易攻击的点。
正确操作：打印日志时使用log4j等组件，对接组件进行脱敏操作。开发打印调试信息时，如json，一定要在开发阶段清楚内部会有什么内容，尽量打印细致，比如有些json中会包含密码，密钥等信息，如果脱敏组件没有拦截住，既是重大问题。安全测试定期使用工具扫描测试环境中的日志，进行分类，分析。 - 用户清单和实际不符
描述：用户清单指产品在所有的用户，比如连接数据库所使用的用户，登录服务器所使用的用户。
目的：向客户展示所有用户，避免让用户怀疑产品留有后门。
正确操作：新增/变更/删除用户时，比如新对接中间件，其他服务。及时更新用户清单，确保该版本用户清单和产品实际相符。 - 通信矩阵和实际不符
描述：通信矩阵指产品中所有使用到的端口，使用的协议，源设备，目的设备，该通道的目的。
目的：向客户展示所有通信道路，避免让用户怀疑产品留有后门，传输客户隐私信息。
正确操作：新增/变更/删除端口时，比如新对接中间件，其他服务。及时更新通信矩阵，确保该版本通信矩阵和产品实际相符。 - 所有对外的配置参数需要在资料中体现
描述：对外提供的调优参数，逃生通道，开关等，都需要在资料中写明。
目的：向客户展示所有参数，避免让用户怀疑产品留有后门。
正确操作：新增/变更/删除参数时，及时更新产品资料，确保该版本资料和实际产品相符。 - 巡检，维护脚本需要在资料中体现
描述：如启动脚本，定时巡检脚本，需要在资料中公开。
目的：避免让客户怀疑产品留有后门。
正确操作：在交付件中体现，让用户知道每个脚本目的是什么，必要时用户可以拿着交付件去找人检查。避免客户怀疑后产品层面说不清楚。 - 巡检，维护脚本禁止使用过大的权限
描述：脚本中使用的权限操作尽量少的文件及目录
目的：避免被攻击者利用
正确操作：明确脚本功能，权限，能力范围。给脚本单独设置用户或用户组。 - 在代码/资料中暴露未备案的公网地址
描述：除代码中不可避免地打印的公网地址，如Java中import com.google.xxx。
目的：避免被人通过公网地址找到易攻击点。
正确操作：如内部研讨如设计规格，开发中参考文档，应当写在内部资料中，或者其他面向用户的交付件中体现。不能在产品代码，帮助手册中对外体现。 - 禁止硬编码ip地址，密码
描述：禁止代码中硬编码ip地址，密码。
目的：如果源码泄露，可以通过硬编码ip，密码进行攻击。
正确操作：每次部署产品时可以通过动态配置（如通过域名，挂载卷）进行部署，确保安全。 - 禁止使用私有加密算法
描述：只允许使用主流的没有被淘汰的加密算法，且算法参数要符合要求，如长度等。
目的：公开的主流的没有被淘汰的加密算法经得起挑战，如有漏洞也会及时公布并告知解决方法。而私有加密算法不一定受到了充分挑战，有可能被攻破不会被发现，持续的泄露信息。
正确操作：只允许使用主流的没有被淘汰的加密算法，且算法参数要符合要求，如长度。订阅/周期性的查看漏洞网站，确认加密算法是否有安全隐患。如：中国国家信息安全漏洞库（https://www.cnnvd.org.cn），美国国家信息安全漏洞库（https://nvd.nist.gov/），CVE披露网站（https://www.cve.org/） - 解释型语言不可以留有未使用的代码，或用注释处理不使用的代码
描述：巡检，维护脚本中不使用的代码应当立即删除。不使用的代码有可能是过时方法，实现一般的方法，通常是没有进行验证的方法。
目的：在解释型语言中，攻击者更容易发现这类代码，攻击者可以利用这一点进行攻击。
正确操作：不使用的代码需要立即删除，不光解释型语言，所有语言代码不再使用都应立即删除，除了避免被攻击，也可以避免误导开发者。另外要注意一点，如Java语言反射调用，IDE中不一定能识别出来该代码的调用点，需要核查后再删除。 - 解释型语言不可以留有开发者工号等信息
描述：如JS文件，脚本信息等，不允许留下具体开发人员的工号，姓名，手机号，邮箱等信息。
目的：避免攻击者根据信息寻找开发者在网络上的其他信息，如博客，github信息寻找攻击线索。甚至通过邮件发出钓鱼邮件。或者收卖开发者。
正确操作：发布前扫描代码，确认没有相关信息。 - 文件权限不满足要求（550 640）
描述：文件权限应当尽量小，只允许相关用户访问。
目的：如多服务部署在同一台机器上，避免其他服务操作本服务内容，造成影响。多租场景下，避免租户可以访问其他租户内容，进而导致泄露租户数据。
正确操作：清晰文件使用范围，读写操作对应用户，尽可能小的暴露权限。 - 临时文件没有老化机制
描述：产生的临时文件必须建立删除机制。
目的：避免随着产品的使用产生大量的垃圾文件，导致磁盘撑爆，服务异常。避免攻击者利用该漏洞进行DOS攻击。
正确操作：设立老化机制如人工删除，定时任务删除。 - 用户应当满足最小权限原则
描述：用户尽可能细化，只能访问/操作有限的文件。
目的：避免攻击者获取一个用户后可以进行全盘的操作。
正确操作：如各个服务使用各自的用户，脚本使用自己的独立用户。 - 人机接口需要有审计日志
描述：如用户通过页面对产品进行了操作，需要在审计日志页面中查看具体操作
目的：可以通过审计日志进行问题定位分析，溯源。
正确操作：每个非查询类的人机接口一定要记录审计日志：至少要包括：时间，操作内容，用户，对应服务，影响等级。能够清晰描述出用户实施的操作。 - 不好的正则表达式引发redos攻击
描述：正则DOS攻击，也就是redos攻击。由于正则表达式写的不够好，可以构造特殊正则表达式，消耗cpu，内存，服务运行缓慢，甚至导致服务挂掉。
目的：避免redos攻击
正确操作：尽量避免宽泛的正则表达式，用一些在线工具去检查是否有redos攻击风险。 - 流未关闭
描述：比如文件流读了没有关
目的：避免资源长时间占用不释放，也就是资源泄露，最后资源不足，导致服务宕机。
正确操作：写在try with中，或者要在使用完立即关闭。或者明确规划好关闭的环节，并集中审视，充分验证。
备注：
由于我们服务是偏底层的服务，不会和用户有过多的交集，另外我们的上下游服务，分别已经做了相应的防护，或者有相关的看护手段策略。除了上述注意点，如需更完备的考虑安全问题，还需要进一步分析以下服务/组件在安全方面的看护能力。
- 密钥管理服务：
背景：跨信任网络需要通过加密通道传输，或者数据需要进行加解密处理，这时候
提供能力：具备更新，过期，上传，查询，更新等操作，不可以导出。 - 日志脱敏sdk：
背景：日志中不允许打印aksk，明文密码，组件版本号等敏感信息，大多数情况下可以通过正则或者类似手段对日志进行预处理
提供能力：通过对log4j的增强，只需要在log4j以及其sdk的配置文档中配置开启关闭，敏感信息规则，即可进行脱敏操作。 - 接口参数校验sdk：
背景：http接口参数都要进行适当的校验，不能是非常宽范围的校验。这个校验如何配置，管理，审计是一个问题。如果是在各个服务内自己处理，难免有不同的格式，不同的规范。就此我们有一个公共的sdk来处理。
提供能力：通过xml来进行配置，配置接口的参数个数，对应类型，以及对应策略，如文件的大小限制，字符串的正则表达式限制。
租户管理服务：
背景：多租场景方便计费，同一套环境可以给多个服务使用，那么租户的增删改查就是一个必要能力。各个服务都需要类似的能力，所以租户管理可以提供这一点
提供能力：租户的增删改查
认证服务：
背景：登录系统基本上是一个必备的能力。
提供能力：用户的认证，token管理等。
扫一扫
275
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
