基于AppSec USA 的调查,各种Code Review方法找出的漏洞数量对比如下:

可以看出,人工Code Review发现漏洞的效果很明显,应该被纳入公司SDLC流程

何时做Code Reivew:

代码提交前
代码合入时

Code Review前的准备:

安全代码审计应当发现应用程序的常规安全漏洞以及业务逻辑漏洞。

对于软件开发者来说,Code Review好像是针对个人的审查,这需要通过代码审查人员与开发团队建立一种合作氛围来解决,要把自己塑造成开发团队的合作顾问,而不是警察。

一般来说,审查的范围要根据项目大小来定,保持弹性。
理想情况下,代码审查需要在需求设计阶段就介入,但是现实情况往往无法做到。
为了有效的进行审查,审查人员需要熟悉以下方面:
* 应用程序功能及业务规则
* 上下文(了解项目背景及主要功能)
* 敏感数据(确定账号、密码及其他敏感信息的定义)
* 用户角色及访问权限(了解账号角色类型及相应的权限)
* 应用程序类型(桌面app,移动app、web ,不同的程序类型面临不同的风险)
* 代码(需要熟悉编码语言特性以及一些常用的最佳实践)
* 架构设计(需要了解软件架构,如web中的MVC等,以便了解程序如何运行)
* 公司标准或指南(了解公司安全管理标准及行业安全要求)

一些关于设计方面的问题:

开发团队需要提供的审查人员的关键信息:

进行简单的威胁建模及STRIDE风险评估

代码审计

A1 注入(最常见的是SQL注入,此外还有XPATH注入,命令注入、LDAP注入、XML注入等)
审计什么:
– 不信任任何输入(尤其是用户输入)
– 过滤所有的用户输入(htmlEncode)
– 使用静态代码分析工具
– 使用参数化查询
– 使用存储过程
– 提供安全编码最佳实践培训
审计点:(需要重点关注SQL执行、EXEC等函数)
– 总是对全部的用户输入内容进行了类型、格式、长度、范围等维度的验证
– 从不直接使用用户输入数据拼接SQL
– 使用存储过程或参数化查询执行SQL
– 实现了多层数据验证

A2 失效的认证和会话管理
– 确认登录页面采用了TLS
– 确认用户名、登录ID是不区分大小写的
– 确认登录失败提示没有泄露额外信息(不要提示用户不存在等内容)
– 不要记录失败的密码
– 使用更长的复杂密码可以增加暴力破解难度
– 为防止暴力破解,需要加入账户锁定和尝试登录频率限制
– 对于内部系统,考虑定期强制修改密码,并禁止使用近期使用过的历史密码
– 强制用户使用复杂密码
– 通常需提供密码找回或者重置机制
– 选用合适的密码加密/编码方式很重要

A3 XSS
– 不可信的数据不能在HTTP响应中原样返回
– 对于客户端来说,不要信任服务器端返回的不可信数据,需要对返回的数据进行编码
– 当引入数据到DOM,必须使用一下安全API
a. Node.textContent
b. document.createTextNode
c. Element.setAttribute (second parameter only)

A4 不安全的对象直接引用
– SQL注入的动态字段
– HTTP POST请求里面的对象参数

A5 错误的安全配置
– Apache Struts
– Java Enterprise Edition Declarative Configuration
– Apache/nginx/jetty/tomcat/weblogic/iis
– WEB应用程序框架配置

A6 敏感数据泄露
– 传输保护,采用TLS
– 存储保护,使用安全的高强度加密算法
– 流转保护,增加日志、读取数量、读取频率限制

A7 功能级别的访问控制缺失
– 每个端点都进行了认证和授权
– 授权检查方法必须统一,以便授权结果一致
– 当使用RBAC时,用户的角色和权限必须清晰可控
– 必须提供简易界面对RBAC进行管理
– 敏感权限操作必须增加日志,方便审计
– RBAC角色尽量简单,避免过于复杂
– 避免直接在client侧实施授权(不通过server进行授权)
– 未授权前,尽量拒绝所有页面访问
– 线上环境移除所有测试功能和数据

A8 CSRF
– 避免使用一些无效防护策略:
* 使用更加安全的Cookie编码
* 只接受POST请求
* 使用多阶段提交(多阶段提交并不能防住CSRF,例如,加购、下单、支付)
* URL REWRITE
– 避免在GET请求中携带TOKEN
– TOKEN必须足够随机不易猜测
– TOKEN需要有过期机制

A9 使用存在已知漏洞的组件
– 控制组件的引入

A10 未验证的重定向和转发
– 重定向接口是否对域名进行了控制

Post Navigation