【YD通讯标准】 Web 应用安全评估系统技术要求

ICS33.040
中华人民共和国通信行业标准
YD/T3153-2016
Web应用安全评估系统技术要求
Technical requirements of Web application security assessment system2016-07-11发布
2016-10-01实施
中华人民共和国工业和信息化部发布前
范围·
术语、定义和缩略语
部署要求.
4功能要求…
自身安全要求·
管理要求
YD/T3153-2016
YD/T3153-2016
本标准按照GB/T1.1-2009给出的规则起草请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。本标准由中国通信标准化协会提出并归口。本标准起草单位：中国信息通信研究院、中国移动通信集团公司、北京云安志信信息安全科技有限公司、北京安赛创想科技有限公司。本标准主要起草人：廖璇、许子先、下哲、张峰、叶丰华、历建、林俞坚
HiiKAoNiKAca
1范围
Web应用安全评估系统技术要求
YD/T3153-2016
本标准规定了Web应用安全评估系统的技术要求，具体包括部署要求、功能要求、性能要求、自身安全要求和管理要求。
本标准适用于扫描Web层应用漏洞、代码缺陷、业务逻辑等安全问题的系统。2术语、定义和缩略语
2.1术语和定义
下列术语和定义适用于本文件。2.1.1
Web应用安全评估系统WebApplicationSecurityAssessmentSystem一种主动扫描发现Web系统应用层安全漏洞扫描系统。它依据一定的策略，对网页系统进行URL发现并扫描，发现安全漏洞并提出相应的改进意见。2.1.2
爬虫Spider/Crawler
种按照一定的规则，自动的抓取万维网信息的程序或者脚本2.1.3
静态页面StaticWebpage
存储在网站系统所在的服务器上，下载到用户客户端运行，其内容不会因访问条件的不同而发生变化的网页文件，比如采用html、htm等技术开发的网页。2.1.4
动态页面DynamicWebpage
存储并运行在网站系统所在的服务器上，能根据访问条件的不同而发生变化的网页文件，比如采用PHP、ASP、JSP等技术开发的网页。2.1.5
SQL注入SQLInjection
一个代码注入技术，它利用一个Web应用程序的安全漏洞，在数据库层实施攻击。如果对用户输入的非法字符串（如Web表单递交或输入域名或页面请求的查询字符串）过滤不严谨，则会把构建的恶意SQL语句传递到数据库，欺骗服务器执行恶意的SQL命令。2.1.6
跨站脚本CrossSite sCripting
一种Web应用程序的漏洞类型，能令攻击者往Web页面里插入恶意html代码，当用户浏览该页之时，嵌入其中的恶意html代码会被执行，从而达到攻击者的特殊目的。2.1.7
TiiKAoNiKAca
YD/T3153-2016
csRF跨站请求伪造Cross-SiteRequestForgery利用网站合法用户对网站的信任，构造未经授权的命令，通过诱骗等手段让合法用户的浏览器实施攻击。
Cookie注入CookieInjection
网页系统对客户端的Cookie值处理不当，恶意人员在访问网页时构造特定的Cookie参数值实现对Web系统后台数据库的非法操作。常用于非法修改动态网页数据或者获取后台数据库保存的敏感信息。2.1.9
目录遍历DirectoryTraversal
网页系统的WebServer配置不当，恶意人员可以直接遍历系统的目录，获取系统的敏感信息。2.1.10
信息泄露InformationLeakage
网页系统的实现不当，导致网站信息泄露，包括但不限于：网站测试文件泄露、网站源码泄露、网站phpinfo文件泄露等。
认证缺陷AuthenticationFlaws
Web应用系统在认证访问者时存在缺陷，可被攻击者绕过进而访问特定网站资源。2.1.12
误报率RateofErrorReport
误报率是指在评估过程中由于系统机制或定义问题导致误报的概率。误报是指Web应用安全评估系统对安全漏洞的判断不准确，即有A漏洞的时候，判断为B漏洞，或当前系统不存在而漏洞却判断为存在。2.1.13
漏报率RateofMissingReport
漏报率是指对于已知的安全漏洞样本，评估系统存在漏报的概率。漏报是指当前安全漏洞已知，但Web应用安全评估系统未判断其存在。2.1.14
扫描深度ScanningDepth
系统对于检测出问题的部分，进行弱点取证和风险利用。2.1.15
扫描广度ScanningBreadth
系统利用爬虫引擎获取指定Web应用的所有URL。2.2缩略语
下列缩略语适用于本文件。
Cross-site request forgery
Hypertext Transfer Protocol
HypertextTransferProtocoloverSecureSocketLayerStructured Query Language
跨站请求伪造
超文本传输协议
超文本传输安全协议
结构化查询语言
HiiKAoNiKAca
3部署要求
UniformResourceLocator
Cross Site Script
统一资源定位符
跨站脚本攻击
系统应有合理的系统/环境适应性，适用于常见/一般的软硬件平台。YD/T3153-2016
系统如对软硬件平台有特殊需求，涉及操作系统层/硬件芯片层变更，应在部署前出具合理说明。4功能要求
4.1扫描功能
4.1.1信息收集
系统应该能够发现Web应用中的以下各种URL，并在界面中予以呈现：a）页面文件包括的URL
b）解析JavaScript等脚本而获得的URL；c）执行JavaScript等脚本而获得的URL；d）Flash中内嵌的URL；
e）解析Ajax请求而获得的URL；f）执行HTMLDOM事件而获得的URL。系统应该能够发现基于HTTPS协议的Web应用中的各种URL。4.1.2漏洞检测
系统应能够检测出Web应用漏洞，至少包括以下内容：a）SQL注入漏洞，支持基于GET、POST方式提交的至少包括字符、数字、搜索等的注入漏洞：b）Cookie注入漏洞，支持基于Cookie方式提交的至少包括字符、数字、搜索等的注入漏洞：c）XSS漏洞，支持基于GET、POST方式的跨站攻击漏洞：d）CSRF漏洞
e）目录遍历漏洞：
f）网站信息泄漏漏洞，包括但不限于网站测试文件泄露、网站源码泄露、网站PHPinfo文件网站配置文件泄露等：
g）认证缺陷漏洞，包括但不限于各种登录绕过、常见的账号、弱口令等。h）命令注入漏洞，支持linux和windows的命令注入漏洞：i）暗链，能够发现网中隐藏且不能从浏览器激活的链接ji）应用程序漏洞,支持国内主流cms系统漏洞等；k）文件上传漏洞。
对于以上漏洞的检测，系统的漏报率不得高于10%，误报率不得高于10%。4.1.3变形检测
系统应支持变形检测，以此绕过简单的过滤检测机制。比如：应支持SQL注入的各种注入语句的变形以及其编码形式、跨站漏洞的各种变形以及编码形式等。4.2扫描配置
4.2.1配置向导
HiiKAoNiKAca
YD/T3153-2016
系统应提供可视化的配置向导功能，方便用户在使用时明确各项功能。4.2.2扫描范围
系统应能够按照下列条件配置扫描的范围：a）当前URL、当前域名、整个域：b）IP地址、IP地址段：
c）扫描时的深度，广度等：
d）配置为不扫描的URL，例如二级域名等。4.2.3登录扫描
系统应支持用户登录状态的Web应用页面扫描4.2.4扫描方式
系统应能够按照用户选择提供下列扫描方式：a）主动/自动扫描：
b）手动/半自动扫描：
c）支持手工导入URL列表扫描。4.2.5扫描策略
系统应能够按照下列方式来选择扫描策略：a）漏洞类型；
b）危害程度；
c）自定义：
d）扫描强度，如线程数量或并发连接数量。4.2.6定制扫描
系统应能够按照设定方式、时间进行单一扫描和批量扫描，并根据设置在任务结束后自动完成结果的保存或报告的输出。
4.2.7稳定性和容错性
系统应能够稳定的运行：
a）主界面不应失去响应或非正常退出；b）扫描进度应有合理显示：
c）扫描任务应可随时停止和暂停。4.3结果输出
4.3.1结果保存
系统应能在扫描过程中及扫描结束后，自动保存扫描结果。4.3.2结果验证
系统应具备Web应用漏洞验证的功能：a）自动验证：能在扫描结果中展示漏洞相关信息，如对于SOL注入漏洞，扫描报表中能提示目标服务器的数据库类型及权限。
b）手工验证：提供对应的漏洞验证程序，支持自动和手工配置验证参数。4.3.3结果生成
HiiKAoNiKAca
系统应能对扫描结果进行分析并形成报告，报告可分为下列类别：YD/T3153-2016
a）对扫描信息的结果生成相应报告，漏洞信息至少包括URL、漏洞名称、漏洞描述等详细信息：b）应对漏洞提出相应的安全性建议、解决方案和帮助链接等。4.3.4报告输出
系统的扫描报告应能按下列要求输出：a）导出为常用文档格式（支持Html、Word、excel、PDF、Text和XML中的一种或几种）：b）通过文字、图表等形式将统计结果展现。4.4扫描扩展
系统应提供或采用一个标准的、开放的接口，支持规则模型，添加简易。4.5系统升级
系统应提供便捷的升级方式，支持自动、手动升级，支持最新出现的高危漏洞检测不得晚于2周。5自身安全要求
5.1用户安全
5.1.1用户身份标识
系统应能对用户权限进行区分：a）系统应提供用户权限标识，分配与之相应的安全属性和操作权限；b）系统应提供使用默认值对创建的每个用户的属性进行初始化的能力：c）系统应为用户提供唯一标识，并将用户的身份标识与该用户的所有可审计能力相关联。5.1.2用户身份鉴别
系统应能对用户角色进行区分：a）系统应在执行任何与管理员相关功能之前鉴别用户的身份：b）系统应保证鉴别数据不被未授权查阅或修改：c）系统应提供一定的鉴别失败处理措施，防止暴力猜测口令：d）系统应具有登录超时锁定或注销功能。在设定的时间段内没有任何操作的情况下，终止会话，需要再次进行身份鉴别才能够重新操作。最大超时时间仅由授权管理员设定5.2安全管理
5.2.1安全功能管理
应允许管理员对系统进行管理：a）授权管理员应能对安全属性进行查看；b）授权管理员应能对安全属性进行修改：c）授权管理员应能启动、关闭全部或部分安全功能d）授权管理员应能制定和修改各种安全策略5.2.2安全角色管理
系统应能对管理员角色进行区分：a）具有至少两种不同权限的管理员角色，例如管理员、操作员、审计员等：b）应根据不同的功能模块，自定义各种不同权限角色，并可对管理员分配角色。5.2.3数据完整性
HiiKAoNiKAca
YD/T3153-2016
系统应确保用户信息、策略信息和关键程序的数据完整性。应采取必要的手段对其完整性自动进行检验。
5.2.4保密传输
若扫描结果通过网络进行传输，应采取保密措施保障没有被未授权的第三方截取5.2.5敏感信息保护
系统应确保用户的敏感信息的机密性，如对用户口令进行加密存储。5.2.6可信管理主机
若控制台提供远程管理功能，应能对可远程管理的主机地址进行限制。5.2.7适用限制
系统应提供对扫描范围进行限制的手段，如限制可扫描的具体IP地址、域名等。5.3审计日志
5.3.1审计日志生成
应对与自身安全相关的以下事件生成审计日志：a）管理员的登录成功和失败；
b）对安全策略进行更改的操作：c）对安全角色进行增加、删除和属性修改的操作d）对扫描结果的导出和删除：
e）对扫描结果的备份：
f）管理员的其他操作。
产品应在每一个审计日志记录中记录事件发生的日期、时间、用户标识、事件描述和结果。若采用远程登录方式对产品进行管理还应记录管理主机的地址。5.3.2审计日志保存
审计日志应能存储于永久性存储介质中。5.3.3审计日志管理
应提供下列审计日志管理功能：a）只允许授权管理员访问审计日志：b）提供对审计日志的查询功能：c）授权管理员应能保存、删除和清空审计日志。宜提供日志外发功能，通过syslog等方式将日志发送到统一平台进行审计。6管理要求
6.1配置管理
6.1.1版本号
开发者应为产品的不同版本提供唯一的标识。6.1.2配置管理文档
配置管理文档应包括一个配置清单，配置清单应唯一标识组成产品的所有配置项并对配置项进行描述，还应描述对配置项给出唯一标识的方法，并提供所有的配置项得到有效维护的证据。6.1.3授权控制
HiiKAoNiKAca
YD/T3153-2016
开发者提供的配置管理文档应包括一个配置管理计划，配置管理计划应描述如何使用配置管理系统。实施的配置管理应与配置管理计划相一致。开发者应提供所有的配置项得到有效地维护的证据，并应保证只有经过授权才能修改配置项。6.1.4配置管理覆盖
配置管理范围至少应包括产品交付与运行文档、开发文档、指导性文档、生命周期支持文档、测试文档、脆弱性分析文档和配置管理文档，从而确保它们的修改是在一个正确授权的可控方式下进行的。配置管理文档至少应能跟踪上述内容，并描述配置管理系统是如何跟踪这些配置项的。6.2交付与使用
6.2.1交付程序
开发者应使用一定的交付程序交付产品，并将交付过程文档化。交付文档应描述在给用户方交付产品的各版本时，为维护安全所必需的所有程序。6.2.2使用程序
开发者应提供文档说明系统的安装、生成和启动的过程。6.3使用指南
6.3.1管理员指南
开发者应提供管理员指南，管理员指南应与为评估而提供的其他所有文档保持一致。管理员指南应说明以下内容：
a）管理员可使用的管理功能和接口：b）怎样安全地管理产品：
c）在安全处理环境中应被控制的功能和权限：d）所有对与产品的安全操作有关的用户行为的假设：e）所有受管理员控制的安全参数，如果可能，应指明安全值；f）每一种与管理功能有关的安全相关事件，包括对安全功能所控制实体的安全特性进行的改变；g）所有与管理员有关的IT环境安全要求。6.3.2用户指南
开发者应提供用户指南，用户指南应与为评估而提供的其他所有文档保持一致用户指南应说明以下内容：
a）产品的非管理员用户可使用的安全功能和接口；b）产品提供给用户的安全功能和接口的使用方法：c）用户可获取但应受安全处理环境所控制的所有功能和权限：d）产品安全操作中用户所应承担的职责；e）与用户有关的IT环境的所有安全要求。6.4生命周期支持
开发者应提供开发安全文档。
开发安全文档应描述在产品的开发环境中，为保护产品设计和实现的保密性和完整性所必需的所有物理的、程序的，人员的和其他方面的安全措施，并应提供在产品的开发和维护过程中执行安全措施的证据。
YD/T3153-2016
6.5测试
6.5.1测试覆盖
开发者应提供测试覆盖的证据，应表明测试文档中所标识的测试与功能规范中所描述的产品的安全功能是对应的。
开发者应提供测试覆盖的分析结果，测试覆盖的分析结果应表明测试文档中所标识的测试与功能规范中所描述的产品的安全功能之间的对应性是完备的。6.5.2测试深度此内容来自标准下载网
开发者应提供测试深度的分析。深度分析应证实测试文档中所标识的测试足以证实该产品的功能是依照其高层设计运行的。6.5.3功能测试
开发者应测试安全功能，将结果文档化并提供测试文档测试文档应包括以下内容：
a）测试计划，应标识要测试的安全功能，并描述测试的自标：b）测试过程，应标识要执行的测试，并描述每个安全功能的测试概况，这些概况应包括对于其他测试结果的顺序依赖性：
c）预期的测试，结果应表明测试成功后的预期输出；d）实际测试结果，应表明每个被测试的安全功能能按照规定进行运作。6.6脆弱性分析保证
6.6.1安全功能强度评估
开发者应对指导性文档中所标识的每个具有安全功能强度声明的安全机制进行安全功能强度分析，说明该安全机制达到或超过指导性文档中定义的最低强度级别和特定功能强度度量。6.6.2脆弱性分析
开发者应执行脆弱性分析，并提供脆弱性分析文档。开发者应从用户可能破环安全策略的明显途径出发，对产品的各种功能进行分析并提供文档。对被确定的脆弱性，开发者应明确记录采取的措施。对每一条脆弱性，应有证据显示在使用产品的环境中，该脆弱性不能被利用。在文档中，还需证明经过标识脆弱性的产品可以抵御明显的渗透性攻击。
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。