安全编码一些建议(二)

Posted by 周思进 on February 5, 2022

好早之前发过《安全编码一些建议》,本文继续做补充。

1、接口调用需要有权限控制
检测当前用户是否有权限调用相关接口,尤其是涉及敏感信息获取的,应该在提供用户最外层的协议接口就做判断拦截。需要注意仅给用户开放该有的最小权限即可。

另外对于权限判断,不要基于用户名判断,尤其是仅管理员可执行的一些操作。我是看到我们工程代码中就有不少基于用户名来做判断的,这样如果后续用户名发生变更,很多代码都要做修改处理。更可取的方式就应该基于是否拥有该操作权限来判断。


2、减少不必要的端口开放
多增加一个端口开放,就可能多增加对应服务被攻击的可能性。通过 nmap 等端口检查工具检测当前系统存在的开放端口(测试时注意把所有服务功能都开启),对于未记录在通信矩阵中的端口进行确认,如无必要,就应该关闭。

对于不安全的端口,也需要尽快考虑升级,比如 telnet 这种明文传输协议就不要支持了,需更换使用 SSH 服务;还有 FTP 等等这类明文传输协议。


3、敏感信息处理
如果是网络传输,则能做到支持 TLS 链路传输加密最好,如果不能,那对于敏感信息传输需要做到单独加密传输。
这里对于数据是否属于敏感信息,尽量做到在需求中就明确出来。

对于本地打印输出,无论是正常的还是异常的打印,都需要注意敏感信息不可以有打印输出行为。
对于敏感信息存储也需要做到加密存储。

敏感信息特别是密码使用后,需要对该内存进行清零操作。同样对于密码这类高敏感数据不允许可从服务端获取返回。

对于敏感信息的获取,也要考虑指定授权用户才能查看。即使做到了非授权用户不能查看,也需要做到不能有让对方可以检测到存在与否的可能。


4、审计日志
对于一些关键数据操作,需要有详细的日志记录,明确用户、源IP、时间、具体操作记录等信息,便于事后追溯。


5、代码漏洞
如果系统中有使用到开源代码,需要关注相关开源代码漏洞更新,对于重大漏洞都需要及时更新。
比如像 openssl 开源代码,后续都不维护 1.0.2 版本了,都应该尽快考虑切换到 1.1.1 版本。

对于研发内部自身编写的代码如存在严重漏洞,如果是内部发现的,那至少需要做到让尽可能少的人知晓,同时尽快安排修复更新程序。


6、威胁建模
尽量在开发流程中引入威胁建模,分析当前系统可能存在的威胁点,考虑后续需要进行的安全修改点,并制定计划,逐步在后面的版本中落实。

功能开发的时候,开发人员一般都会写概要设计,这个时候都需要考虑下在安全上是否存在安全隐患。


9、理解原有代码再修改
大部分情况我们都是在维护原有代码,解决一些bug,所以在改原有代码 bug 的时候,一定要先弄清楚原有代码逻辑,不要找到一处可疑点,修改了一把,测试下觉得没有问题就当解决了,有可能根本没有找到问题的根因,只是临时规避了下,最怕还因此引入了其他问题。