/catalog/296695a3fdd74f71b4ced1996c9b6856//Document/304898482892869.html/Document/304549706600517.html/Document/304188584996933.html/Document/303818784497733.html/Document/302700517105733.html/Document/302416475320389.html/Document/302077848256581.html/Document/301288627347525.html/Document/300279638184005.html/Document/274792263872581.html/Document/273024381308997.html/Document/272683642789957.html/Document/272351623921733.html/Document/271961406242885.html/Document/271560844214341.html/Document/270477420015685.html/Document/269881559916613.html/catalog/c51244b85e704db9a2a34ca396e9fe27//Document/297463116619845.html/Document/296410729726021.html/Document/294281412902981.html/Document/289614801383493.html/Document/289336711553093.html/Document/288989717336133.html/Document/267736666357829.html

安全测试国家标准解读——访问控制

下面的系列文章主要围绕《GB/T 38674—2020 信息安全技术 应用软件安全编程指南》进行讲解,该标准是2020年4月28日,由国家市场监督管理总局、国家标准化管理委员会发布,2020年11月01日开始实施。我们对该标准中一些常见的漏洞进行了梳理,大家感兴趣的话可以自己去下载下来学习一下,里面有一些最佳实践是比较好的。

本标准从程序安全和环境安全两个方面提出了提升应用安全性的编程最佳实践。其中,程序安全部分描述软件在资源使用、代码实现、安全功能方面的安全性规范,环境安全部分描述软件的安全管理配置规范。前面的文章为大家介绍了数据清洗,本文我们针对安全功能实现的访问控制部分进行解读。

软件应用安全测试

【访问控制-身份鉴别】

应用安全测试

接下来我们一起看一下访问控制的身份鉴别部分。我们需要根据业务要求安全选择身份鉴别方式,安全性要求高的系统建议采用多因素身份鉴别方式。


大家都知道,身份鉴别方式一共有三种:用户所知、用户所有、基于生物特征的。用户所知一般指的是口令密码、动态验证码之类,用户所有指的是U盾之类的智能卡,基于生物特征指的是我们的面部识别、指纹、虹膜之类。

 

一般银行业会要求有两种及以上的身份鉴别方式。


其次会验证数字证书,传输过程中我们会去验证传输信息的数字证书。最后是避免鉴别过程被绕过。


【访问控制-口令安全】
1.禁止使用弱口令,空口令或已泄露的口令。
2.安全地存储口令:
(1)禁止明文存储口令。
(2)使用不可逆的加密算法或单向杂凑函数对口令进行加密存储。
比如国密3、SHA-256、AES等都可以。
(3)在散列过程使用添加变量,将口令转化为不可还原或难以使用字典攻击猜测的形式。
这样可以增加攻击的难度。
(4)将加密后的口令存储在配置文件、数据库或其他外部数据源中。
(5)禁止在源代码中写入口令。
这一条我们在源代码审计中有时还会看到,比如访问数据库、FTP时,很多都直接在源代码中写入了口令,这样都是不安全的。

现在有一些平台在针对互联网上的应用去扫描空口令和弱口令,一旦被扫描到就会被通告。


“禁止使用弱口令,空口令或已泄露的口令”这条还是很重要的,大家在使用过程中一定要避免。

【访问控制-权限管理(权限安全)】

 

1.遵循最小权限原则:确保服务账户或连接到外部系统的账号,仅具有执行经授权的任务所需的最小权限(或最低的安全许可)。

 

我们在连接数据库的时候,账号只给读写的最小权限,不要给sa管理员的权限。


2.只有授权的用户才能访问秘密数据或敏感数据。通常,这类数据有与用户信息或应用软件自身安全密切相关的状态信息、文件或其他资源、受保护的URL、受保护的功能、直接对象引用、应用程序数据以及与安全相关的配置信息等。
我们在设计一个软件的时候,要把全部的数据进行分类,把敏感数据预先定义出来,对这些数据的处理要做提前的规划,防止在处理过程中,每个开发人员的处理方式不一致而导致的漏洞和偏差。

从敏感数据的产生、传输过程中怎么处理,存储过程怎么处理,使用完之后敏感数据怎么销毁,这整个过程在设计之初就要设计出来,做一个整体的预案。

【安全功能实现-日志安全】


日志安全这部分是非常重要的,国家的一些标准中也有相关审计的要求。标准要求对每个重要的行为都记录日志。我们在软件系统中做的一些重要操作要有迹可循,帮助我们记录什么人在什么时刻做了什么事情,日志就是来帮助我们来做这个事情的。


确保系统在发生重要安全事件时创建日志。
重要安全事件包括:
重要数据更改,有些人有权限做数据更改,比如说针对资金、财务方面的更改,这些重要数据的更改需要记录下来,什么人做了什么操作。
认证尝试(特别是失败的认证),记录谁什么时间登陆上来了,谁什么时间退出了,以及登陆失败的认证,可以帮你分辨这是一个恶意登陆还是一个正常登陆。
失败的访问控制
失效或者已过期的会话令牌尝试,这个也可以帮你分辨是不是黑客在攻击,如果这个会话令牌已经过期了,他还在使用这个会话令牌,那就有可能是他恶意获取的。
系统例外、管理功能行为、失败的后端TLS链接、加密模块的错误
这些都需要记录日志,以便我们有据可查。我们要确保重要信息都记录到日志中,与此同时还需要采取安全措施防止攻击者写任意的数据到日志中,避免在日志中保存敏感数据。
比如说A改了B的工资,我们记录日志信息的时候要记录哪些信息呢?是B原先多少钱被改到了多少钱这些信息都记录下来吗?这样也是不合理的,因为工资已经是敏感数据了,那要怎么改才会既能留下记录,又不会泄漏敏感数据呢?
方法比较多,也要具体结合我们业务的要求。如果我们的业务要求只是知道改了这条数据就可以了,这些数据在数据库里有记录,可以通过这条日志查到数据库里的记录,这样就可以只记录A在某时间改了B的信息。


或者这条日志也可以是一个加密的日志,按照系统设定的要求去记录。
以上就是日志的安全,这也是每个系统都需要去建设的一部分。

 

后面的文章会继续对《GB/T 38674—2020 信息安全技术 应用软件安全编程指南》的其他部分进行解读,欢迎继续关注。