自上而下做好安全代码审查
安全的程序开发实践的一个关键方面就是安全代码审查。安全代码审查，与常规的代码审查一样，可以使用自动化工具完成，也可以要求开发者亲自参与到代码审查中人工完成。那么，安全代码审查与常规的代码审查有哪些差别、如何做到更有效的安全代码审查呢？大家可以通过本文了解一下。
安全代码审查：对安全知识要求高
常规的程序代码审查需要代码审查者具备业务、程序语言和相关技术知识的积累，安全代码审查则需要具备以下 3 个不同方面的安全知识：
让安全代码审查更有效：自上而下
要做到有效的安全代码审查，方式之一就是采用自上而下的方法，此方法要求代码审查者了解用例细节且对此有比较深入地掌握。进行安全代码审查，建议你按照下面的步骤进行。
1，了解待审查代码的用例细节
2，分解用例
以下面形式分解用例，该种分解属于数据流图（DFD）式威胁模型：
- 角色（Actor，外部实体）
- 数据流
- 应用程序/模块
- 数据存储
3，识别威胁
STRIDE 可用来识别对上述元素的威胁。STRIDE，是“假冒身份、篡改数据、否认、信息泄露、拒绝服务和权限提升”英文单词的缩写（对应的英文为 Spoofing Identity、Tampering Data、Repudiation、Information Disclosure、Denial of Service 与 Elevation of Privelege)。比如，角色（Actor）可能会受到来自“假冒身份”和“否认”的威胁；数据流可能会受到“篡改数据”、“信息泄露”和“拒绝服务”等方式的威胁等。
4，检查安全漏洞
一旦威胁与全部元素发生了关系，则需检查潜在的可能转变为攻击的安全漏洞。如，SQL 注入，会话处理，已破坏的验证与授权等。可以查看文章 OWASP Top 10 了解常见的 10 种安全漏洞。
5，做好补救控制
一旦确认安全漏洞，则需检查补救控制措施是否到位或针对这些漏洞的措施是否恰当。这些补救控制措施通常就是更为安全的代码。可以在OWASP Top 10 每个单独链接页查看相应的补救控制措施建议。
下面针对部分威胁和安全漏洞给出了对应的补救控制建议：
- SQL 注入攻击：在查询相关的代码中搜索参数化 API（parametrized API）的使用情况。同时，也要请求一个或多个输入验证架构，如 OWASP ESAPI 用在转义可能带来注入攻击的字符的情况。
- 跨站点脚本攻击（XSS）：搜索基于 HTML 上下文（主体、属性、JavaScript、CSS或URL）用于转义全部不受信任数据的代码。可以查看 OWASP 跨站点脚本攻击备忘了解数据转义技术细节。
- 敏感数据曝光：查询敏感数据并检查该类数据的存储策略。可以从代码角度来检查数据的加密强度。
- 功能级权限控制缺失：在代码审查时，要确认何人具备访问该功能的授权、是否根据用户类型赋予了其合理的权限控制。在控件或业务逻辑中，数据集有时仅能由特定类型的用户进行访问。
结语
目前，对部分开发者来说，可能还需要一定程度的安全培训才能胜任安全代码审查工作、实现有效的安全代码审查。代码的常规审查不可少，安全审查也不可少，对安全性要求较高的程序尤其要注意。如果缺少了这道流程，万一遭受攻击，带来的损失将远超过我们的想象，“预则立，不预则废”说的就是这个道理。
Via Vitalflux
推荐阅读