北京教育行业SRC平台运营办法

 

一、基本原则

为落实北京教育行业SRC平台工作要求，建立健全SRC运营机制，制定本平台运营办法，旨在规范SRC平台的白帽注册、提交漏洞、漏洞定级和奖励机制，确保平台的安全、稳定运行。本办法依据全国信息安全标准化技术委员会的相关标准（见附件1）、EDUSRC和国内众测平台的运营方案，结合市教育系统的具体情况，给出SRC平台运营全流程的做法，同时给出对于不同等级漏洞的奖励标准，为漏洞发现者及漏洞报告者从事漏洞发现和报告的活动提供指引。

针对提交的漏洞，本平台会有内部安全合规专家进行评审和跟进，本办法承诺对每一位提交者提交的漏洞都有专人负责、反馈、分析和处理，并及时给予答复。SRC平台将恪守并支持负责任的漏洞报告流程，尊重每一位白帽子的研究成果。真诚欢迎每一位白帽子向SRC平台报告漏洞，SRC平台将按照漏洞质量给予感谢和回馈。

未经允许请勿在任何公众场合或平台讨论或披露隐私漏洞的细节，不得向任何第三方透露隐私漏洞。如有上述行为，平台将有权追究其法律责任。

二、运营流程

1、白帽注册与审核流程

白帽子是指具备安全测试技能和道德标准的个人或组织，他们通过发现和报告系统漏洞来帮助提升网络安全。SRC平台为白帽子提供邀请注册制，适用于高校在职教师和在校学生。

注册账号：白帽子登录北京教育行业SRC平台的官方网站或相关入口。依据邀请码填写注册信息，根据平台要求，准确填写个人或组织的相关信息。可能需要填写申请表格或提供相关安全测试证明材料，例如安全认证、过往漏洞报告经验等。确保提供的资料准确、真实。仔细阅读注册页面上列出的平台条款、规则和义务。确保充分理解并同意遵守这些规定。只有在理解并同意遵守平台规定的前提下，才能继续进行注册流程。

审核过程：平台会对白帽子申请进行审核。审核过程可能包括对个人或组织资质的核实、安全测试能力的评估等。审核的时间可能需要几天或几周的时间。

遵守规则和义务：一旦成为注册成功，白帽子需要遵守平台的规则和义务。包括保持诚实、合法的行为，遵循平台的报告流程和指导方针等。

2、漏洞提交流程：

本流程用于规范白帽子提交漏洞的流程，白帽子需要仔细阅读漏洞提交指南，了解漏洞填写规范（见附录1），确保理解提交流程、要求和相关政策。根据规范的要求，报告应包含漏洞的详细描述及漏洞证明（见附录2）、复现步骤、可能的影响和建议的修复方案。通过在线表单或其他指定的渠道完成。一旦提交完成漏洞报告，需要耐心等待SRC平台的响应。这需要一些时间，在技术组和专家组完成对漏洞报告的评估和验证后，如果漏洞报告被确认有效，白帽子可能有资格获得奖励值。根据平台规定，可能需要提供额外的信息以领取奖励值。

3、漏洞处理方法和流程

由SRC平台技术组对漏洞报告进行评估和处理（见附录3），验证漏洞的存在和潜在威胁。通过尝试复现漏洞，并评估其可能的危害程度。根据漏洞的严重性、影响范围和潜在危害将漏洞进行分类和初步定级。常见的漏洞等级包括严重、高、中、低和无，具体的级别和标准参考《工作手册-05-SRC漏洞定级办法》。

由SRC平台专家组进行漏洞终审定级。专家终审定级是一个关键步骤，用于对漏洞进行最终的定级和评估。技术组将漏洞的初步定级结果提交至专家组，专家可能会对漏洞进行进一步评估和验证，以确保其准确性和影响的确认，可能涉及更深入的测试和分析，通过综合考虑漏洞的严重性、影响和可能的风险，决定采取何种措施来修复漏洞。在完成进一步评估后，专家组对漏洞完成最终定级。

漏洞提交后，技术组会确认收到的漏洞报告，并开始评估问题，对漏洞问题进行处理、给出初步定级结论并给出建议奖励值（见附录4），上报专家组，专家组完成审核后给出最终结论并计入奖励值（必要时会与报告者沟通确认，请报告者予以协助）。

4、上报教委和整改复测

经专家定级的漏洞报告将及时上报给北京市教育委员会，提供详细的漏洞信息和修复建议。教委将要求相关业务单位按时对漏洞进行修复。

 

三、本文附录

附录1：漏洞提交填写规范

提交漏洞需按本规范要求填写，不符合规范填写的漏洞报告将被直接驳回。

（一）漏洞标题

（1）漏洞名称应明确说明漏洞所在业务、漏洞类型等信息，请避免使用「某业务」、「某网站」等泛指的词；

（2）不确定漏洞所属的业务时，请使用域名或IP等代替；

（3）漏洞标题请对漏洞进行简要描述，请勿出现该漏洞对业务的具体影响。

（二）测试时间

请如实填写测试时间。

（三）自评等级

请按照《SRC漏洞定级办法》如实判断所提交漏洞等级。

（四）漏洞类型

（1）请按照漏洞情况选择准确的漏洞类型；

（2）若该报告内阐述漏洞内容是需若干漏洞组合利用，请选择其中最主要漏洞类型进行填写。

（五）漏洞URL

Web类漏洞需要提供漏洞URL，漏洞URL应当为漏洞最关键部分的URL，如存储XSS的输入或输出点页面URL、SQL注入点的URL、POST型反射XSS的目标URL等。

*注URL需要是完整的链接，不能仅写主域名。

（六）漏洞详情

尽可能详尽地书写漏洞详情，参见漏洞详情详细说明和漏洞证明（附录2），如无特殊必要情况，所有信息能直接提供在漏洞详情的请直接在漏洞详情填写，若漏洞详情过于简单，漏洞报告将被直接驳回；

请准确、客观地描述漏洞出现的位置、测试步骤、PoC/EXP、影响大小等，并提供关键步骤的截图、利用成功的截图；测试步骤和POC必须填写完整。漏洞利用点：客户端漏洞需要提供准确的漏洞代码位置，包括包名、类名、关键部位代码问题说明。如果是非代码类的，业务操作相关的漏洞，需要明确说明功能入口；

按照逻辑对漏洞复现顺序进行详细描述，若使用工具复现漏洞，应提供工具名称。

（七）修复建议

请提供可执行的修复建议，可以提供代码级的修复建议，也可以提供防护策略。

 

附录2：漏洞详情说明及漏洞证明

1. 报告中需复现过程完整，URL及重要参数完整，有详细的漏洞复现步骤、测试步骤，并每个步骤配有图文描述。审核可根据描述一次性完成漏洞复测，无需二次沟通或补充数据。

2. 尽可能提供足够的信息，如无特殊必要情况，所有信息能直接提供在漏洞详情的请直接在漏洞详情填写，请勿仅提供简单描述+文档/视频等方式提交漏洞详情。

3. 准确、客观的描述漏洞的来源，漏洞出现的位置、详细URL（包括入口URL及漏洞位置的完整URL）、测试步骤、PoC/EXP、影响大小等，并提供关键步骤的截图、利用成功的截图、视频等（视频等信息仅做为漏洞详情的补充说明，不能只提供视频）；测试步骤和POC必须填写完整。漏洞利用点：客户端漏洞需要提供准确的漏洞代码位置，包括包名、类名、关键部位代码问题说明。如果是非代码类的，业务操作相关的漏洞，需要明确说明功能入口。

4. 客户端漏洞需要提供存在问题的客户端、版本号，特殊渠道下载的包请说明下载来源。

5. 接口类URL上的漏洞请同时提供调用此接口的业务页面URL；需要前置步骤或前置权限的，请一并说明，如有Referer校验的URL需要提供前置的测试步骤；如果接口类URL是爆破所得，需在报告说明爆破时间、爆破ip及爆破方法，否则仅给对应漏洞级别的最低漏洞奖励。

6. 对于其他类型漏洞，未提供漏洞利用条件的来源和证明的，都仅给对应漏洞级别的最低漏洞奖励。

7. 非常见的漏洞类型请额外提供漏洞原理、成因、修复方案等，并附上参考资料链接；常见的漏洞无需提供漏洞上述信息。

8. 漏洞关键步骤为HTTP POST的，请在漏洞详情正文最后提供完成的POST包，如SQL注入、越权等漏洞。HTTP头中的Cookie字段的值可置空，但需要留有Cookie字段名。若为文件上传类等漏洞，请把包中文件内容字段置空以减少内容大小。

 

部分漏洞详情额外要求说明：

1.POST型CSRF等：请提供PoC、漏洞所在页面URL。

2.存储型XSS：请提供输入点所在页面URL、输入点字段名、Payload、输出点URL、输出点具体位置的截图说明，如果触发路径较长，需同时提供触发方式。

3.SQL注入漏洞：请提供注入点URL所在页面URL（如果有）、注入点URL、注入成功后的截图。

4有账号认证的应用需提供漏洞测试时所使用的账号名信息，如账号来源不是通过注册获得的，需要提供所用账号密码及账号密码的来源，否则将扣除该漏洞奖励。

5.漏洞测试如果获取到webshell，请提供完整的webshell访问地址和连接密码。

 

附录3：漏洞处理策略

按提交漏洞的情况，分为一般漏洞处理策略和漏洞降级、无效、重复场景处理策略和重复漏洞处理策略。

一般漏洞处理策略为：

（一）同一应用下大量存在的同一类型漏洞：按正常等级确认前3个；若漏洞都由同一问题点导致的，修复一个漏洞其他也都会被自动修复时，只确认第1个漏洞，如同一过滤函数导致的XSS绕过、框架层漏洞等。

（二）同一功能的越权增删改查，只确认1个；相似功能或接口的同一类型漏洞，比如getDetail和getList按第1条规则确认。

（三）同一应用下的同一数据库的SQL注入，确认前3个，其中第1个正常确认，后2个降一级确认。

（四）0Day类漏洞按实际影响的业务确认，最多确认前3个；无实际影响案例的，不关注。

（五）同一组件导致的多个业务问题，确认前3个，比如同一个二方SDK导致的多个APP漏洞；若是同一漏洞源导致的问题，修复一个漏洞其他也都会被自动修复时，只确认第1个漏洞。

（六）内部已知的Web漏洞，仍在漏洞处理时效内的，对外按重复驳回；严重超出处理时效的，对外正常确认（已申请不修复，或确认短期内不修复的除外）。

（七）内部已知的APP、终端上漏洞，对外按重复驳回。

（八）外部上报后严重超期未处理的Web漏洞及严重超期的APP类漏洞，对外正常确认（已申请不修复，或确认短期内不修复的除外）。

（九）内部安全工具检测到白帽子的漏洞，在一个工作日内上报的，对外正常确认；超出一个工作日上报的，按重复驳回。

（十）通过社会工程学（主要是非xss盲打类的钓鱼）获取重要账号登录系统等利用方式，不在收集范围内。

（十一）信息泄露类、未授权访问类的漏洞如 SSRF、github 信息泄露，memcache、redis 等未授权访问等，根据存储的内容的有效、回显情况、敏感程度进行确认评级；key泄露问题需要提供key有效性证明和影响证明。

（十二）漏洞报告者复查状态为“已修复”的漏洞，如果发现漏洞仍然存在或未修复好，当作新漏洞继续得分。

（十三）同一个报告里提交多个不同漏洞，只按级别最高的漏洞计分；报告网上已公开或者在修复前被作者投到其他三方平台的漏洞不计分；同一漏洞最早提交者得分。

（十四）在漏洞未修复之前，被公开的漏洞将追回奖励处理。禁止未经明确的书面授权，私自公开漏洞的任何细节信息以及在漏洞测试过程中所获知的任何数据，一旦发现严肃处理，包括追回奖励，账户禁用等。

（十五）漏洞的最终奖励由利用难度及影响范围等综合因素决定，若漏洞触发条件非常苛刻，则可跨等级调整积分数量。

 

漏洞降级、无效、重复场景处理策略为：

（一）需要用户交互才能利用的漏洞，除CSRF、反射XSS、Jsonp劫持等本身就需要交互的前端漏洞外，其他漏洞若需要受害者进行一定动作存在交互成本，如访问攻击者提供的链接、点击页面内容、按键等，降级确认。

（二）有一定限制的利用，如任意重置密码需在一定时间内爆破六位验证码、仅在特定环境触发有依赖组件，降级确认。

（三）影响用户量或数据量非常小，比如新上线系统只有少量有效用户、旧系统只有少量有效数据等，降级确认。

（四）部分环节与其他漏洞重复的利用，降级确认；全部重复的，按重复驳回。

（五）URL跳转类需要登录或需要注册固定域名来跳转的，降级确认。

（六）利用环节较为复杂，多个漏洞无法组合成简单利用，或是需要结合爆破等问题，需要一定的时间或人力成本的，降级确认。

（七）未提供成功案例，只是说明理论可行的，漏洞无效；仅提供漏洞利用结果，未提供漏洞POC的，漏洞无效。

（八）只有非Chrome下才能触发的XSS、JSONP等前端漏洞最高为低危。

（九）未运行有实际业务的服务器不在关注范围，如云上测试机器的RCE等；影响的数据为测试数据时，漏洞无效。

（十）为用户提供服务的子域名下的前端漏洞、部分服务端漏洞不在关注范围。

（十二）漏洞产生在测试系统、边缘系统、以及弃用系统的，对业务不产生直接影响的，漏洞等级将降级处理。

（十二）漏洞报告需严格按照漏洞提交规范提交，漏洞提交报告应尽量详细、规范，包括但不限于：域名，详细URL、poc代码或截图或视频、数据证明等，如有漏洞利用工具，请提供利用工具名称，经过验证切实可用并造成相应危害的才收取；若漏洞标题与内容严重不符，或描述信息过于简略，根据情节会做漏洞降级处理。

 

漏洞重复性判定和处理策略为：

（一）同一个CGI文件/数据包对应的多个相同漏洞类型的漏洞，属于同一漏洞。

（二）不同CGI文件/数据包对应的多个相同漏洞类型的漏洞，属于不同漏洞。

（三）同一个CGI文件/数据包对应的不同漏洞类型的漏洞，属于不同漏洞。

（四）由同一个漏洞源产生的同一服务器上的多个漏洞计漏洞数量为一个，例如：服务器某一配置、应用框架某一全局功能、同一文件或模板、泛域名解析等引起的多个问题；存在于不同服务器的漏洞均属于不同漏洞。部分无数据测试环境影响较小的漏洞评级会较低。

（五）关于弱口令（正常对外可注册的系统不算在弱口令范围内）。同一类弱口令，如管理员权限弱口令、VPN系统弱口令，每种均仅收取1个。若通过弱口令后，有额外操作可进一步获得数据与权限，酌情收取。若弱口令为自身测试所造成，则不收取。部分无数据测试环境影响较小的漏洞评级会较低。

（六）若B漏洞是基于A漏洞的，则认为A与B重复：如通过注入漏洞（A）得到写文件的权限上传shell漏洞（B），漏洞取危害大的一个。

 

附录4：漏洞等级和奖励原则

根据漏洞的危害程度将漏洞等级分为严重、高、中、低、无五个等级。 参考《工作手册-05-SRC漏洞定级办法》，结合利用场景中漏洞的严重程度、利用难度等综合因素给予相应分值的贡献值和漏洞定级，每种等级的奖励标准如下：

严重  21-40分

高    11-20分

中    5-10分

低    0-4分

无