作者：（美国）OWASP基金会
出版社：电子工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
软件安全开发指南试读：
前言
背景
2016年和2017年是我国网络安全行业飞速发展的两年。自2016年年底至2017年，国家先后发布并实施《网络空间安全战略》《网络安全法》《关于加强网络安全学科建设和人才培养的意见》等涉及网络安全方面的法律法规和政策文件。同时，“WannCry勒索病毒”“Structs2漏洞”“Office高危漏洞”等这样的全球性网络安全事件也不时刺痛着人们的神经。越来越多的网络安全研究机构、软件研发机构、专家学者逐渐认识到“没有软件安全，就没有网络安全”“安全不仅是网络安全专家的责任，更是每个软件开发从业人员的责任”。
那么，软件研发机构如何开发出安全的应用程序呢？安全的应用程序应该符合哪些标准呢？软件研发机构需要验证应用程序的哪些方面呢？本书是在这样的背景下翻译出版的。
ASVS简介“OWASP应用程序安全验证标准（ASVS）”项目是OWASP全球安全组织的成功项目之一。该项目的主旨如下：为执行 Web 应用程序安全验证提供一套可行的标准，以规范应用程序的安全验证覆盖范围和安全级别。该项目的研究成果，即《OWASP应用程序安全验证标准（ASVS）》，最新版本为第3.0.1版。
该成果不仅为Web应用程序技术安全控制提供了测试参考标准，还为应用程序开发人员提供了一系列安全开发需求建议。为测试应用程序技术安全控制及依赖于测试环境中的任何技术安全控制提供了参考依据，以消除应用程序受到跨站脚本（XSS）、SQL注入等软件安全威胁的影响。此外，该成果还可用于标识应用程序的安全信任级别。
该成果可根据读者或使用人员的需要，作为度量标准、安全指导和采购要求。（1）度量标准：为应用程序开发人员和应用程序所有者提供一个参考标准，以评估应用程序的可信任程度。（2）安全指导：为应用程序中安全控制的开发人员提供有关构建安全控制的指导建议，以满足应用程序的安全开发需求。（3）采购要求：为应用程序的采购合同，提供应用程序安全验证需求的参考标准。
读者对象
本书的主要读者对象包括但不限于：（1）软件研发组织机构的技术专业负责人和项目主管。（2）软件安全开发服务咨询与验证的相关人员。（3）网络安全基础核心领域研究的专家学者。（4）高等院校软件工程专业和网络安全专业的教育工作者。（5）对软件安全开发感兴趣的个人。
内容结构
本书分为3篇，共19章。第一篇由第1、2章组成，对ASVS及其评估软件的使用方式进行了介绍。第二篇由第3～18章组成，分别介绍了16类验证关键点。第三篇由第19章组成，表述了ASVS的实践案例。
全书由王颉负责总体架构设计和质量控制，由Rip、张家银担任翻译顾问，由包悦忠、李旭勤负责技术指导。第1章由王颉翻译，第2章由王厚奎翻译，第3～10章由王厚奎和吴楠共同翻译，第11～18章由吴楠翻译，第19章及附录由王厚奎翻译。全文由赵学文负责统稿与编排。
致谢
特别感谢OWASP总部对OWASP中国组织本中文版ASVS相关工作予以的支持。
感谢 OWASP 中国和 SecZone 自 OWASP Application Security Verification Standard（V2.0）发布以来对该项目持续的跟进、翻译、研究与分享。同时，也对该项目的参与人员表示感谢。
OWASP中国将对OWASP ASVS项目保持跟进，持续完善和深化本书。
中文版说明（1）本书为OWASP Application Security Verification Standard（V3.0.1）的中文版。本书尽量保留原版本的格式与风格，但部分语言风格调整为中文表述。其中存在的差异，敬请谅解。（2）为方便读者阅读和理解本书中的内容，本书对原英文版中明确内容为空的章节进行了删除，并对原英文版中的部分章节内容进行了顺序调整，致使本书的章节编号与原英文版中的章节编号不同。（3）本书中的表格包含每条描述项的序号，以及其在原英文版中的原描述项序号，以方便读者进行匹配。（4）由于译者团队水平有限，存在的错误敬请指正。（5）如果您有关于本书的任何意见或建议，可以通过以下方式联系我们：
邮箱：project@owasp.org.cn
微信公众号：
OWASP ASVS项目支持单位：
中文版工作团队成员简介：（按姓氏拼音顺序排序）
Rip
OWASP中国主席
OWASP S-SDLC项目、OWASP中文项目、OWASP中国各项目发起人，超过15年的安全领域从业经验，资深安全专家。
包悦忠
OWASP中国副主席
加拿大滑铁卢大学应用科学硕士。曾任职亚马逊（中国）首席信息安全官、微软可信赖计算部总监。长期在北美和中国高科技软件和互联网公司从事信息安全管理、软件安全开发及相关流程体系建设。微软内部认证SDL讲师，曾负责为中国政府、电信和金融等行业大客户提供软件安全评估、SDL培训及流程实施方面的咨询服务，帮助客户利用SDL的方法和实践，通过在软件开发生命周期过程中融入必要的安全活动，整体提高软件和应用的安全性。先后参与“OWASP Top 10”“OWASP安全测试指南”等多个OWASP中国分部项目。
李绪勤
英国华威大学博士，长期关注金融业务风险、金融风险等领域。拥有超过10年IT工作经验和信息安全实践经验。
王厚奎
OWASP中国广西区域负责人
南宁职业技术学院信息工程学院 副教授
硕士研究生，持有CISP（CISO）、NISP、网络规划设计师、初级等保测评师、NSACE网络信息安全讲师等资质证书，并取得中国信息安全测评中心颁发的CISI讲师资格。中国计算机学会会员、广西信息安全学会会员。拥有14年IT工作经验，8年信息安全实践经验和培训教学经验，涉及网络管理、信息安全与风险管理、信息产品安全管理、信息安全省级项目调研等多个方面。自 2010 年加入 OWASP 组织和 OWASP 中国分部以来，先后参与了“OWASP Top 10”“OWASP Cheat Sheets”“OWASP Hacking-Lab”等多个应用安全研究项目。
王颉
OWASP中国副主席
OWASP中国成都区域负责人
深圳开源互联网安全技术有限公司 副总经理
英国拉夫堡大学网络安全博士。长期从事企业信息体系建设落地和软件开
发全生命周期研究工作，具有丰富的信息安全学术研究和资深的企业信息化建设实践经验。自2009年加入OWASP组织和OWASP中国分部以来，曾参与了“OWASP中文项目”和“OWASP S-SDLC项目”两个OWASP全球项目，并先后主持、参与和独立开展了“OWASP Top 10”“OWASP OpenSAMM”“OWASP安全编码规范快速参考指南”“OWASP安全测试指南”等多个OWASP中国分部项目，为在国内提高OWASP安全组织的影响力、提升OWASP研究成果的实用性和适用性做出了重要贡献。
吴楠
OWASP中国辽宁区域负责人
大连银行 高级信息安全顾问
长期从事信息安全体系建设、银行业安全合规建设、S-SDLC的研究工作，并深入项目实施安全代码审计。在从事信息安全工作前，曾多年从事全生命周期的软件开发及项目管理工作。获得CISP、PMP、ISO 27001 IA、ISO 22301、Risk Mangement、CWASP L2安全专家、国家软件工程师、C-CCSK、ITIL等认证资质。自2015年加入OWASP组织和OWASP中国分部以来，先后参与了“OWASP Top 10”“OWASP Cheat Sheets”“OWASP Code Review”等应用安全项目，并从中积累了宝贵的经验。
张家银
OWASP S-SDLC项目主要负责人
安徽开源互联网安全技术有限公司 总经理
拥有15年安全领域从业经验，资深S-SDLC专家。对软件安全开发流程、安全架构设计、应用安全解决方案、安全测试，以及应用安全扫描工具原理与设计有深入的研究与实践经验，曾主导完成全球最大云安全产品（年用户数7+亿人次）的S-SDLC全流程及落地。
赵学文
OWASP中国会员“注册软件安全开发人员（CWASP CSSD）”认证持有者。自 2017 年加入OWASP中国分部以来，先后参与了OWASP中国组织的“OWASP Top 10 2017”“OWASP SAMM”“OWASP Cheat Sheets”“OWASP Code Review”等中文项目，为应用软件技术的研究与推广做出了积极项献。第一篇ASVS概述
第1章 使用应用安全验证标准
第2章 评估软件达到验证水平第1章使用应用安全验证标准
本书的编写有两个主要目标：（1）帮助组织开发和维护安全的应用程序。（2）允许安全服务提供商、安全工具厂商和终端用户调整应用程序的安全要求和功能。1.1 应用安全验证级别
应用程序安全验证标准定义了3个安全验证级别，每个级别的深度都在增加。（1）ASVS 1级适用于所有应用程序。（2）ASVS 2级适用于包含需要保护敏感数据的应用程序。（3）ASVS 3级适用于最关键的应用程序，包括处理高价值业务的应用程序、存储和处理敏感医疗数据的应用程序、需要最高级别信任度的应用程序。
每个ASVS级别包含一个安全需求的列表。这些需求通过开发商的软件开发也可以映射到特定安全的特性和功能。如图1-1所示，为第3.0.1版OWASP应用程序安全验证标准模型。图1-1 第3.0.1版OWASP应用程序安全验证标准模型1.2 如何使用这个标准
使用应用程序安全性验证标准的最佳方式之一是将其用作蓝图，创建特定于应用程序、平台或组织的安全编码清单。将ASVS调整到软件开发过程中的用例，将加强对项目和环境最重要安全要求的关注。
1.2.1 1级验证标准：取巧级
如果应用程序充分防范《OWASP Top 10》和其他类似清单中包含的安全漏洞，它就实现了ASVS 1级（或取巧级）。
ASVS 1 级验证标准通常适用于具有较低安全控制需求的应用程序、对应用程序进行快速分析、协助编制安全需求的优先级列表。ASVS 1级验证标准可以通过工具自动完成，也可以通过无须访问源代码的简单手动操作完成。我们认为，ASVS 1级验证标准是应用程序所需的最低标准。
应用程序的威胁很可能来自攻击者。攻击者会使用容易发现和容易利用的漏洞对应用程序进行攻击。这与一个意志坚定的攻击者形成对比，后者将把精力集中在具体的应用程序上。如果组织机构的应用程序处理的数据具有很高的价值，那么组织机构会希望不仅仅是1级安全检查。
1.2.2 2级验证标准：标准级
如果应用程序能够充分抵御当前与软件相关的大部分风险，那么应用程序就实现了ASVS 2级（或标准级）。
ASVS 2级验证标准确保安全控制在应用程序中被恰当、有效地使用。ASVS 2级验证标准通常适用于处理重要业务交易的应用程序，包括处理医疗信息、执行重要且敏感的业务、处理其他敏感资产。
对ASVS 2级应用程序的威胁通常来自熟练的、有动机的攻击者，他们使用工具和技术来关注特定的目标，这些工具和技术在发现和利用应用程序的弱点方面是非常有效的。
1.2.3 3级验证标准：高级
ASVS 3级是ASVS最高的验证级别。这个级别通常保留用于需要大量安全验证的应用程序，例如，在可能发现安全性问题的军事领域、健康和公共安全领域、关键基础设施等。组织可能需要ASVS 3 级用于执行关键功能的应用程序，因为安全防护失败可能会对组织的运营产生重大影响，甚至影响组织的生存。下面提供了关于ASVS 3 级应用的示例指导。如果应用程序充分防范高级的安全漏洞，并且还展示了良好的安全设计原则，它就达到了ASVS 3级验证标准。
ASVS 3级需要比所有其他级别更深入的分析、架构、编码和测试。安全应用程序以有意义的方式进行模块化（以促进如弹性、可扩展性及最重要的安全层），并且每个模块（由网络连接或物理实例分隔）负责其自身的安全责任（防御深入），这需要妥善记录。责任包括确保机密性（如加密）、完整性（如交易、输入验证）、可用性（如正常处理负载）、认证（包括系统之间）、不可否认性、授权、审计和日志记录的控制。1.3 在实践中应用ASVS
不同的威胁有不同的动机。一些行业具有独特的信息和技术资产，以及具体领域的法规要求。
下面提供关于ASVS级别的特定行业的指导。尽管对于每个行业存在一些独特的条件和不同的威胁，在所有行业领域一个共同的主题是投机取巧的攻击者。这样的攻击者会寻找应用程序中任何容易的脆弱点进行利用，这就是为什么“OWASP ASVS”建议所有应用程序至少达到ASVS 1级，而不论它们处在什么行业。这是一个建议的起点，用来管理最容易发现的风险。强烈建议组织基于其业务的性质更深入地研究其独特的风险特征。而另一个极端是ASVS 3级，它是为那些可能危及人身安全的案件保留的，或者当一个应用程序被破坏会完全地严重影响组织时，用高级验证标准。如表 1-1所示为在不同行业中实践ASVS。表1-1 在不同行业中实践ASVS续表第2章评估软件是否达到验证水平2.1 使用指导《OWASP应用程序安全性验证标准》可用作应用程序的开放式验证标准，包括无限制地访问关键资源（如架构师、开发人员）、项目文档、源代码、验证的访问测试系统（包括各角色至少访问一个账户），特别是ASVS 2级和ASVS 3级验证标准。
通常，渗透测试和安全代码审查包括“异常”的问题只在最终报告中才会出现。组织必须在相关报告中包括验证范围（特别是，如果关键组件超出范围的情况，例如，SSO认证）、验证结果的摘要，包括通过和失败的测试，并明确指出如何解决测试失败。
保存详细的工作文件、屏幕截图或电影、可靠的和重复暴露问题的脚本、电子测试记录（例如，代理日志、相关注释等）被认为是标准行业实践，并且可以作为开发者非常有用的研究证据。简单地运行工具并报告失败是不够的，这不能够提供足够的证据来证明所有的认证级别问题已经经过彻底的测试。如有争议，应有足够的证据证明每个经过验证的要求都经过测试。2.2 自动渗透测试工具的作用
鼓励自动渗透工具提供尽可能多的覆盖范围，并尽可能多地使用许多不同形式的恶意输入参数。
不可能使用自动渗透测试工具单独完全完成ASVS验证。虽然1 级验证标准中的大部分要求可以使用自动化测试执行，但是大多数要求不适合自动渗透测试。
请注意，随着应用程序安全行业的成熟，自动化和手动测试之间的界限模糊不清。自动化工具通常由专家手动调整，手动测试人员经常利用各种自动化工具。2.3 渗透测试的作用
可以执行手动渗透测试并验证所有ASVS 1级问题，而不需要访问源代码，但这不是主要的做法。ASVS 2级验证至少需要访问开发人员、文档、代码和对系统进行身份验证的访问。由于大部分额外的问题涉及系统配置、恶意代码审查、威胁建模和其他非渗透测试伪装的检查，因此，无法完成ASVS 3级的完整渗透测试。2.4 用作详细的安全架构指导
应用程序安全验证标准的更常见用途之一就是安全架构师的资源。两个主要的安全架构框架SABSA或TOGAF都缺少完成应用程序安全体系结构审查所需的大量信息。ASVS可用于填补这些差距，允许安全架构师为常见问题（如数据保护模式和输入验证策略）选择更好的控制。2.5 用作现有安全编码清单的替代
许多组织可以通过采用 ASVS，选择 3 个层次之一，或通过划分ASVS并以特定于域的方式更改每个应用程序风险级别所需的内容。只要维护可追溯性，我们就鼓励这种类型的分支，因此，如果应用程序已经通过了第 4.1 条的要求，这就意味着分支副本与标准一样可行。2.6 用作自动化单元和集成测试指南
ASVS 被设计为高度可测试，除架构和恶意代码要求外。通过构建测试特定和相关的模糊和滥用情况的单元和集成测试，该应用程序几乎能自动验证每个构建。例如，可以通过登录控制器的测试套件，利用常用用户名的用户名参数、账户枚举、暴力破解、LDAP、SQL注入及XSS制作额外的测试。类似地，密码参数测试应包括常用密码、密码长度、空字节注入、删除参数、XSS、账号枚举等。2.7 用作安全开发培训
ASVS 也可用于定义安全软件的特性。许多“安全编码”课程只是道德黑客课程，具有轻微的编码技巧，这不利于开发人员学习和提升。相反，安全开发课程可以使用ASVS来强调ASVS中的主动控制，而不是仅遵从《OWASP Top 10中列明的内容》。第二篇ASVS详解
第3章 V1：架构、设计和威胁建模
第4章 V2：认证
第5章 V3：会话管理
第6章 V4：访问控制
第7章 V5：恶意输入处理
第8章 V6：密码学安全
第9章 V7：错误处理和日志记录
第10章 V8：数据保护
第11章 V9：通信安全
第12章 V10：HTTP安全配置
第13章 V11：恶意控件
第14章 V12：业务逻辑
第15章 V13：文件和资源
第16章 V14：移动应用程序
第17章 V15：Web服务
第18章 V16：安全配置第3章V1：架构、设计和威胁建模3.1 控制目标
经过验证的应用程序，需确保满足如下高级别要求。（1）ASVS 1级：需识别应用程序中所有的组件，并明确应用程序中使用该组件的原因。（2）ASVS 2级：应用程序已定义架构，并且代码遵循架构设计。（3）ASVS 3级：架构及设计方案具体落地、实施并有效地应用于程序中。3.2 验证要求
表3-1所示为架构、设计和威胁建模的验证要求。表3-1 架构、设计和威胁建模的验证要求3.3 参考文献
有关详细信息，请参阅：（1）威胁建模 Cheat Sheet。https：//www.owasp.org/index.php/Application_Security_Architecture_Cheat_Sheet（2）攻击面分析Cheat Sheet。https：//www.owasp.org/index.php/Attack_Surface_Analysis_Cheat_Sheet第4章V2：认证4.1 控制目标
认证是一种用以建立或者确认某件事物（或者某个人）是否如其所声称的或本身具有的真实行为。确保经验证后的应用程序满足如下高级别要求：（1）验证通信发送者的数字身份标识。（2）确保仅授权的实体能够以安全的方式进行身份认证和凭证传输。4.2 验证要求
表4-1所示为认证的验证要求。表4-1 认证的验证要求续表续表4.3 参考文献
有关详细信息，请参阅：（1）OWASP 测试指南 4.0：认证测试。https：//www.owasp.org/index.php/Testing_for_authentication（2）密码存储 Cheat Sheet。https：//www.owasp.org/index.php/Password_Storage_Cheat_Sheet（3）忘记密码 Cheat Sheet。https：//www.owasp.org/index.php/Forgot_Password_Cheat_Sheet（4）选择和使用安全问题 Cheat Sheet。https：//www.owasp.org/index.php/Choosing_and_Using_Security_Questions_Cheat_Sheet第5章V3：会话管理5.1 控制目标
控制和维护用户与之交互状态的机制，是所有基于Web应用程序的核心组件之一，被称为会话管理。其被定义为在用户和基于Web的应用程序之间，治理全状态交互的所有控制的集合。
确保经验证的应用程序满足如下会话管理的高级别要求：（1）会话对每个实体来说是唯一的，不能被猜到或共享。（2）在非活动周期内，当会话不再被需要或超时时，会话将被无效化。5.2 验证要求
表5-1所示为会话管理的验证要求。表5-1 会话管理的验证要求5.3 参考文献
有关详细信息，请参阅：（1）OWASP测试指南4.0：会话管理测试。https：//www.owasp.org/index.php/Testing_for_Session_Management（2） OWASP 会话管理 Cheat Sheet。https：//www.owasp.org/index.php/Session_Management_Cheat_Sheet第6章V4：访问控制6.1 控制目标
授权是仅获得许可的实体才被授予资源访问的概念。确保经验证后的应用程序满足如下高级别要求：（1）访问资源者持有有效身份证件。（2）用户与一组明确定义的角色和特权关联。（3）角色和权限元数据免受重播或篡改。6.2 验证要求
表6-1所示为访问控制的验证要求。表6-1 访问控制的验证要求6.3 参考文献
有关详细信息，请参阅：（1） OWASP 测试指南 4.0：授权。https：//www.owasp.org/index.php/Testing_for_Authorization（2） OWASP 访问控制 Cheat Sheet。https：//www.owasp.org/index.php/Access_Control_Cheat_Sheet第7章V5：恶意输入处理7.1 控制目标
最常见的Web应用程序安全性、脆弱性是由于在使用程序输入内容之前，没有正确合理地验证来自客户端或外部环境的输入。这一脆弱性几乎导致了Web应用程序中的所有关键漏洞，如跨站脚本攻击、SQL注入、解释器注入、locale/Unicode攻击、文件系统攻击和缓冲区溢出。
确保经验证后的应用程序满足如下高级别要求：（1）验证所有输入是正确的，符合预期目的。（2）绝不信任来自外部实体或客户端的数据，应该采取相应的处理措施。7.2 验证要求
试读结束[说明：试读内容隐藏了图片]