企业中安全团队应当如何反馈漏洞
无论是做漏洞研究还是做安全测试，最终都需要以文本和图片的方式将安全漏洞的信息呈现给需要理解漏洞的人，这个人可能是漏洞相关产品所在机构的审核人员，也可能是漏洞所属产品的研发人员，或者是产品经理之类的决策或管理人员。
在企业的安全管理中，无论是通过自动化漏洞扫描，还是通过人工安全测试，再或者是和相关团队就安全漏洞进行反馈，安全部门都需要将安全漏洞的信息传递给业务部门进行修复。
但往往出于自身的便捷以及专业理解的偏差，安全团队提交的漏洞信息往往是安全产品原生的报告，或者是略加修饰的报告，从安全人员角度可以很容易理解的报告。对于业务方的产品经理、研发人员、运维人员，在庞杂的工作压力之余查看漏洞信息就像从100份简历中用5分钟筛选值得面试的候选人，“简历”的清晰、简单、易懂成为首选，加之专业名词的应用，使得查看漏洞信息的人可能会对这些专业的漏洞信息有一种莫名其妙、不知所云的感觉。
当然会有技术人员可以很容易，或者稍加注意可以通过漏洞报告发现程序中的漏洞或缺陷，但通用型的漏洞修复方案会增加漏洞修复人员的学习成本和修复成本，不得不花时间和精力就漏洞修复方式进行二次沟通，或者自我学习，倘若是自我学习之后“发现”的修复方式，可能会又会面临漏洞修复不彻底，或者漏洞根本未被修复的尴尬。
笔者曾经遇到某客户的副总看着产品漏洞报告，一脸疑惑的询问漏洞描述中的某专业术语是什么含义，并随口问了与会的研发人员，对方也支支吾吾，而从安全人员的角度这个名词早已众人皆知。
因此，在安全工作中，安全团队反馈给其他团队或部门的漏洞信息如果足够的详实，能够减少很多安全人员与非安全人员之间的沟通成本，尤其是复杂的漏洞或者是危害性高但又从业务角度体现不明显的漏洞，安全人员与非安全人员之间常常会对于漏洞定级产生分歧和争议，比如研发人员认为是低危，安全人员认为是高危，又或者研发人员不认为是漏洞，需要安全人员展示漏洞的危害性，比如安全人员反馈的漏洞是关于SSL/TLS协议的漏洞，或者是HTTP请求中使用了PUT/DELETE等不安全的请求方法，这时安全团队面对研发人员关于漏洞危害性的反问，会陷入无法自证的尴尬局面。
对于企业安全工作，漏洞报告或漏洞信息的根本目的是方便漏洞修复人员理解漏洞，并制定策略、确定优先级、执行修复、排查漏洞和预防同类漏洞再次发生，将内部的协作效率尽可能提升，并降低不必要的内部沟通成本，以及不必要的矛盾，就像用户开着车辆去4S店进行车辆保养，4S店的工作人员找到用户反馈车辆保养中发现的车辆维修或配件问题，用户大概会考虑：
怎么理解这个问题？听不懂的问题没有办法判断要不要解决，可能会白花钱；
理解问题之后，问题能有多严重？不严重的问题可能不用处理，可能会白花钱；
如果问题严重，怎么证明问题的存在，而不是4S店瞎编？只是理论上的严重也可以不用处理，可能会白花钱；
如果问题存在且严重，需要什么代价，用什么方式处理？如果代价过高可能不如过段时间换一辆新车，否则会白花钱。
根据笔者在企业安全建设过程中做安全建设的经验，以及和白帽子对漏洞进行沟通和评估的经验，笔者认为，无论是在企业内部的漏洞信息呈现，还是安全人员作为乙方提供漏洞信息至漏洞平台或甲方公司，漏洞信息或安全报告中的漏洞详情的部分需要体现以下内容：
▪ 漏洞名称：即简洁、清晰、易懂的标题
▪ 漏洞描述：漏洞的上下文关系、漏洞原理以及利用成功后的影响
▪ 漏洞位置：漏洞出现的位置，比如URL、参数、文件或其他资源
▪ 影响范围：漏洞利用成功后受影响的用户、客户或其他目标人群
▪ 漏洞危害：漏洞利用成功后的危害情况简短说明
▪ 漏洞复杂度：漏洞利用的条件和难度的简短说明
▪ 发生概率：发生漏洞被利用的概率，比如：高、中、低
▪ 漏洞严重性：结合漏洞危害和发生概率评估的漏洞严重性，比如：严重、高危、中危、低危
▪ 复现过程：能够复现漏洞的逐步的操作说明，确保漏洞修复人员可复现漏洞
▪ 修复建议：能够帮助开发者或相关人员修复或缓解漏洞的具体方式
漏洞名称
漏洞名称是对于漏洞信息的简要说明，但不建议在其中使用专业术语或名词，过于简单的漏洞名称和过于专业的漏洞术语对于修复人员而言无法都无法立即了解漏洞的基本情况。
比如，上图中是某漏洞扫描工具导出的扫描报告，其中一个漏洞的名称是：
电话号码
如果将这个漏洞名称进行口头反馈，大概是“您好，我们发现了一个安全漏洞，它的名字叫电话号码”，听到这句话的修复人员大概也会产生一个大大的问号，就像早年有公司宣传的“手机号码中毒”风险。这个漏洞标题过于简单，以至于需要漏洞修复人员仔细查看完整的漏洞描述之后，才能注意到是应用程序的注释或错误信息页面中包含了手机号码信息。
如此，这个漏洞名称应该改为：
XX页面或注释存在电话号码泄露
较为清晰的漏洞名称可以帮助漏洞修复人员在看到漏洞名称后快速初步判断漏洞修复的优先级，并决定是否需要进一步查看该漏洞的后续信息。
漏洞描述
漏洞描述是对于漏洞名称的更加详细的补充，描述用来介绍漏洞的基本原理，以及漏洞在应用程序中的上下文关系，还有一旦漏洞利用成功可能产生的通用的影响（即一般情况下可能会有什么影响）。通过查看详细、精准的漏洞描述，漏洞修复人员能够更准确理解应用程序中的漏洞情况，甚至学习这类漏洞的基本情况，在后续的开放过程中避免类似漏洞的发生。
以上文中的漏洞名称为例，通用的漏洞描述如下：
Web应用程序中错误消息或者代码注释中含有电话号码，可能被用于社会工程学攻击。
这段描述中的“社会工程学”会让多数非安全人员感觉到困惑：什么是社会？还有工程学？是一种学术么？漏洞描述做人人都理解的假设，会让看到漏洞信息的其他技术人员增加漏洞修复的隐性成本。
更为详细的漏洞描述如下：
XX页面路径下包括XX等地址在内的页面注释或页面信息中存在手机号码的泄露，该号码可能会被攻击者用于挖掘、检索更多关于企业和员工的信息，造成更大范围的攻击，或伪装成企业内部人员通过手机通讯诱导企业员工做出符合攻击者意图的操作。
漏洞位置
漏洞位置描述的是发现漏洞的具体位置，包括应用程序中具体的地址、部分以及相应的参数，且能够让修复人员根据位置信息快速定位漏洞。比如：
URL：https://example.com/news （新闻页面）
参数：请求参数page
在安全漏洞响应中，花费时间最多的往往不是漏洞修复方法，而是如何定位漏洞在企业资产中的位置，大到具体的系统，小到具体的代码行，以及相应的责任人，即漏洞响应最终需要将漏洞信息、业务、资产、人员进行关联。因此，详细的漏洞位置也可以帮助技术人员快速应对漏洞的修复。
影响范围
影响范围是从应用程序的业务角度考虑的，对于安全研究人员或测试人员这通常比较难获取，但对于企业内的安全部门应该是易如反掌的，通常应用的业务影响是由真正使用应用程序的用户或者应用程序的负责人才清除的，这也是为什么安全部门也是业务支撑部门的原因，如果纯粹把部门看作技术部门，那和第三方的安全公司的差异便不大了。另外，从漏洞所在位置的功能也能够了解大概的漏洞影响范围。比如，上文描述的页面或注释信息的电话号码泄露会影响到公司的内部员工或者公司的内部信息保密性。
漏洞危害
漏洞危害是漏洞描述中漏洞利用成功后的影响结合影响范围综合评估的危害程度，需要简单明了说明漏洞一旦被利用成功对于影响范围内的用户、企业或业务的危害情况，危害情况的考虑要分别从以下方面着手：
人身安全、业务稳定性、数据安全性、其他资产安全性、无形资产（品牌、声誉、知识产权、商标等等）。
比如，某个应用系统中存在SQL注入漏洞，可以造成数据库拖库，但这些数据均是该系统的测试数据，且应用也只是是所在企业边缘环境的测试应用，虽然通过注入漏洞可能进一步提权，植入后门，进而横向移动产生更大危害，但就这个SQL注入漏洞而言，无论漏洞类型是什么，或者漏洞描述的危害多么严重，即便漏洞利用成功，对于企业的用户、员工、业务、数据、资产影响也会非常有限，因此这个SQL注入漏洞便不能算作高危及以上漏洞。也就是，漏洞的影响和危害应当像刑法中犯罪行为危害的因果关系的判定，不能无限关联，否则每个漏洞都可以说牵扯到企业的生死存亡。
漏洞复杂度
漏洞复杂度是漏洞利用条件和利用难度的说明，尤其是利用条件，所有的受保护对象都存在漏洞，最极端的攻击方式是物理攻击，物理攻击的难度天花板就是热战争，但对于漏洞信息或者漏洞报告而言，显然其复杂度需要考虑漏洞实际的利用条件，这也可以作为漏洞修复人员制定漏洞修复策略的参考之一。比如在诸如Nessus的漏洞扫描工具扫除的漏洞中，常常会看到SSL/TLS的协议漏洞，但这些漏洞基本都是知道是漏洞，又无法有效利用或者利用条件及其苛刻，又或者利用难度及其高，这个适合倘若运维人员收到这样的漏洞信息，一句话就可以回应漏洞的修复：要不然把这个漏洞复现给我们看看？
发生概率
发生概率是对于漏洞复杂度的更加直接表述，即漏洞被利用的可能性有多大，漏洞利用条件越低，利用难度越小，发生概率越大，反之，利用条件越高，利用难度越大，发生概率越小。漏洞是否进行修复根本上在于发生概率的大小和危害的大小，毕竟风险等于概率（Rate Of Occurrence）乘以危害（Single Loss Expectancy）。
以上文漏洞为例，无论是在企业的安全漏洞测试中，还是在渗透测试过程中，电话号码泄露漏洞被利用的发生概率通常是高，但其危害性也需要安全人员的专业能力和经验加以判断，因为对于社工能力不同的安全人员而言，漏洞利用难度会不同，危害性也会不同，因此不同人的判断结果上也可能会不同。因此在风险评估的定性评估方法中，风险结果的大小因人而异。
漏洞严重性
漏洞严重性是结合漏洞危害和漏洞发生概率综合评估的严重性描述，但通常是基于安全研究人员或安全测试人员个人经验判断，也是漏洞报告最容易产生争议的部分，许多安全人员习惯性的按照漏洞类型进行严重性划分，比如命令行执行是严重，信息泄露是低危，如上文漏洞危害部分的描述，直接按照漏洞类型进行漏洞严重性划分并不严谨。倘若如实描述漏洞危害和发生概率，漏洞严重性的描述也会相对客观。所以，为了客观起见，国外许多漏洞报告中需要安全人员填写CVSS评分，通过CVSS评分规则来确保漏洞严重性的客观性。
复现过程
复现过程是漏洞信息中的最重要部分之一，它能够帮助漏洞修复人员按照步骤一步一步重现漏洞发掘的过程，进而确认漏洞的存在（之所以如此说，也是有安全人员曾经伪造漏洞，以获得工作成果或奖金），以及设计合适的漏洞修复方式。复现过程的重点在于描述的步骤和每个步骤的描述。比如：
在页面中点击鼠标右键，选择“查看网页源代码”。
在网页源代码页面的底部，可以看到存在两个企业员工的手机号码。
如果在复现过程的步骤中需要用到截图展示漏洞的证明（PoC），则需要在截图中通过标注等方式提示漏洞复现过程中提及的漏洞位置、请求、响应等信息。
修复建议
修复建议是从安全人员对于应用程序和漏洞信息掌握的情况，对于漏洞解决方法的详细建议（之所以是建议，是修复人员可以不必采纳，仅供参考），漏洞报告中的漏洞解决思路主要包括缓解（Mitigated）和修正（Remediated），前者是降低漏洞被利用的机率，后者则是彻底解决漏洞，大多数情况下的漏洞修复都应该按照后一种思路设计，但有时候会因为业务的约束或者资源的约束，不得不选择前一种办法，比如典型的情况是某个0-day漏洞被曝光后一时没有合适的修复方法，通过设置WAF规则来降低漏洞被利用概率。
修复建议需要根据漏洞严重性、影响范围以及应用程序的业务和功能需要提出，早年间，修复建议编写的一个不良做法是粗暴的写一句“ 你懂的 ”，甚至在企业内部也有安全人员习惯性的用这种高傲的语气描述修复建议，又或者根据漏洞类型给出一个通用的修复方式，比如上文漏洞的通用修复建议是“关闭Web服务器错误提示；确保代码注释中不含有电话号码”。
企业官方网站中的电话号码信息可能是用于业务联系的，按照上述的修复方法显然是和企业业务需求冲突。因此，需要结合该业务需要编写修复建议：
建议将页面中的员工个人手机号码修改为企业座机号码。
当安全行业对于行业外的企业、人员对于安全漏洞的不重视痛心疾首的时候，或许漏洞信息或呈现方式也对于安全漏洞的“漠视”有推波助澜作用，就像文章开头的例子，如果用户在4S店中可以很清晰的得到关于更换汽车火花塞的必要性的详细描述，或许对于用户下决心更滑配件有莫大帮助。
问题名称： 汽车行驶里程过大需要更换发动机火花塞
问题描述： 汽车火花塞的主要作用是将点火线圈产生的高压电引入发动机燃烧室内，在火花塞电极之间产生电火花，点燃混合气体，从而推动发动机正常运转。汽车行驶里程或汽车使用时间增加，火花塞会逐渐老化，影响到发动机正常启动或发动机性能。
问题位置： 汽车发动机，同时工作人员应该展示具体位置的照片。
影响范围： 汽车发动机启动异常或者发动机性能下降会导致汽车动力不足，并可能会在汽车启动后，在指示灯中提示发动机故障标识。
问题危害： 汽车发动时间变长，反复按启动按钮无法启动，或者在汽车行驶过程中，踩油门发现汽车动力不够，或者在汽车处于怠速时明显感觉到汽车的抖动。
问题复杂度： 低
发生概率： 高
问题严重性： 严重
复现过程： 此处应该拍视频显示火花塞的老化情况或问题情况。
修复建议： 花费60元更换发动机火花塞，每颗火花塞15元。