今天完善了ASVS的PPT。整理成WORD了。
WEB应用安全评估标准- OWASP ASVS
(Application Security Verification Standard)
一、什么是ASVS
(Application Security Verification Standard)
uThe OWASP Application Security Verification Standard (ASVS) Project provides a basis for testing web application technical security controls.
uThe purpose for the ASVS is providing a standard of communication between software vendors and customers. The customer can ask 'How secure are you,' the vendor can answer 'THIS secure,' and everyone is on the same page.
uBy nature, the ASVS is platform independent and free of technical detail. It is simply a listing of security controls, subcategorized by topic and ordered by relative difficulty to implement. This lends itself tremendously well to supporting the development of an application security platform for any software - not just for communication with tool vendors.
uUse as a metric - Provide application developers and application owners with a yardstick with which to assess the degree of trust that can be placed in their Web applications,
uUse as guidance - Provide guidance to security control developers as to what to build into security controls in order to satisfy application security requirements, and
uUse during procurement - Provide a basis for specifying application security verification requirements in contracts.
二、怎样使用ASVS?
1.告知团队软件要有应用的安全测试计划,
2.确定至少达到的安全级别，建议至少1级。
3.与安全区域的验证点进行匹配查找，查找由于安全考虑，开发设计需要做改变的地方。
4.分派责任给开发团队，修改程序。
5.执行验证所选择的安全级别对应的验证点
举例
u一公司自己研发门户，开发团队遵循公司自己的SDLC进行开发，开发过程中，公司的安全团队要验证门户的安全性，可以采用自动化工具进行扫描。整个研发过程，参考ASVS的评估点进行设计、开发。
u同时，可以要求外部的专业安全渗透公司和专业人员，对客户端程序进行安全验证，采用ASVS中的一系列评估点评估。
u如果安全级别要求很高，还需要安全渗透人员，对源码、文档、程序、业务逻辑进行安全验证，依据ASVS中的评估点。
三、ASVS的历史版本
08/2014 – OWASP ASVS 2.0
06/2009 – OWASP ASVS “Release” 1.0
12/2008 – OWASP ASVS “Beta”
04/2008 – OWASP ASVS “RFP” (OWASP Summer of Code 2008)
四、ASVS 1.0与2.0的区别
u1.定义的安全级别不同。
u2.每个安全级别对应的安全区域和子项测试验证点不同。
定义的级别标准不同
ASVS 2.0---4个安全级别
uLevel 0 (Cursory)未定义，企业可以定义自己的标准，如自动扫描，强权限机制等，他适用于大部分的应用。0级不是个先决条件，如果企业没有定义了0级，则可以直接达到1级。如果定义了0级，则只有达到0级，才能达到其他级别。
uLevel 1 (Opportunistic) 能够抵御那些很容易发现的应用安全漏洞，适用于那些使用安全控制信任的系统，快速修复的系统，在有规划未来长期开发的产品的系统。
uLevel 2 (Standard) --能够抵御那些目前盛行、普遍流行的中高级风险应用安全漏洞，如OWASP TOP10，和业务逻辑的漏洞。代表了一个产业标准，大部分组织的敏感应用应该力求达到的标准，如重要的商业对商业的事务，包括哪些处理 医疗信息，执行重要商业敏感功能，其他敏感资产。
uLevel 3 (Advanced) ---能够抵御所有高级的应用安全漏洞，包括展示好的设计标准。包括了哪些很难被发现，必须高手有经验的攻击者花费精力锲而不舍的挖掘才能发现的漏洞。验证范围：包括本身写的代码，也包括第3方组件，但第3方组件是可选的，他没必要达到ASVS标准。
定义的安全验证区域和验证点不同
1.ASVS1.0中的V1\V12\V13\V14在ASVS2.0版本中的其他区域的验证点中包含了。
2.ASVS1.0包含121个验证点。ASVS2.0包含168个验证点。
| 安全验证区域 |
ASVS 1.0 |
ASVS 2.0 |
| V1.安全架构 |
√ |
—— |
| V2. 认证 |
√ |
√ |
| V3. 会话管理 |
√ |
√ |
| V4. 访问控制 |
√ |
√ |
| V5. 输入验证 |
√ |
√ |
| V6.输出解码与验证 |
√ |
√ |
| V7. 密码或密钥算法安全 |
√ |
√ |
| V8. 异常处理与日志 |
√ |
√ |
| V9. 数据保护 |
√ |
√ |
| V10. 传输安全 |
√ |
√ |
| V11. HTTP 安全 |
√ |
√ |
| V12. 安全配置 |
√ |
—— |
| V13. 恶意代码查找 |
√ |
—— |
| V14. 内部代码安全 |
√ |
—— |
| V15.业务逻辑 |
—— |
√ |
| V16.文件资源安全 |
—— |
√ |
| V17.移动应用安全 |
—— |
√ |
| 安全需求区域 |
1级评估点 |
2级评估点 |
3级评估点 |
| HTTP安全 |
3 |
7 |
7 |
| 传输安全 |
1 |
5 |
9 |
| 恶意攻击控制 |
0 |
0 |
11 |
| 会话管理 |
7 |
14 |
14 |
| 密码密钥安全 |
0 |
5 |
7 |
| 敏感数据保护 |
2 |
4 |
8 |
| 访问控制 |
8 |
12 |
13 |
| 认证 |
8 |
19 |
21 |
| 输入验证 |
9 |
13 |
16 |
| 文件资源安全 |
6 |
10 |
10 |
| 业务逻辑 |
0 |
10 |
10 |
| 移动应用 |
4 |
13 |
28 |
| 异常处理与日志 |
1 |
9 |
14 |
| 总计 |
49 |
121 |
168 |
五、ASVS 2.0 介绍
uASVS定义了4级，在深度上逐级增加。验证者职责要验证目标满足所有的定义级别的需求。如果满足所有N级需求，则说明应用程序达到了N级 安全标准。如果只满足了部分需求，而达到了低级别的如N-1，N-2的，则说应用程序达到了N-1，N-2级 安全标准
u验证的范围广度包含程序的组成部分的每一个安全需求，不仅包含编写的代码，也包含引用的外部组件。
u各级别的验证点：见《ASVS2.0安全区域验证点与安全级别对应关系表》
六、建议各应用采用的安全级别
u这只是个参考标准，每个企业可以定义自己的标准。
uLevel 1: 所有互联网可访问的应用程序。
uLevel 2:含有少量或适当数量敏感医疗信息（受保护的卫生信息）的应用程序，个人身份信息，支付数据等业务应用。产品目录信息，内部团体信息，及拥有有限用户信息的应用程序（如联系方式）。含有少量或适量支付数据或付款功能的应用程序
uLevel 3: POS所包含的大量交易数据可能被用来进行诈骗。这包括为这些应用程序预留的任何管理接口。拥有大量敏感信息如全额信用卡卡号，母亲的姓，社会保险卡号等的应用程序。应用程序用来控制医疗设备，器件，或记录内容，这些都可能危及到人类生命。POS包含的大量交易数据可能被用来进行犯罪诈骗。包括这些应用程序的任何管理接口。
