基于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 未验证的重定向和转发
– 重定向接口是否对域名进行了控制