皖事通移动端接入服务应用安全测试服务
“皖事通”移动端服务应用排查整改情况
反馈表
XX单位：（单位盖章）
服务应用名称 | |
服务应用安全责任单位 | |
服务应用安全责任人及职务 | |
安全责任人联系方式 | |
服务应用是否涉及敏感信息 | ¨是 ¨否 |
是否对排查项（附件1）逐项 进行检测 | ¨是 ¨否 |
检测机构或团队 | |
检测中是否发现问题 | ¨是：填数字（附件2中对应检查项序号） ¨否 |
处理措施 | ¨保留运行 ¨下架整改 |
备注 |
填表说明：
一、“服务应用名称”：按“皖事通”对应分厅服务展示名称填写；“服务应用安全责任人及职务”：须填写对该服务应用安全负责的机关事业单位在职人员。
二、“敏感信息”：涉及到用户个人或企业隐私的信息，如：姓名、身份证号（证件号）、电话号码、家庭住址、卡号、车牌号、出行住宿记录、财产、通信、交易、生物基因等。
附件4：
关于申请在“皖事通”上线
“XXX”服务的报告（模板）
市数管局：
“XXX”服务主要功能是……。该服务安全责任单位是A（须机关事业单位）。根据《XXX》文件要求（或其他目的），现申请“XXX”服务上线至“皖事通”分站。我单位落实“XXX”服务安全责任，并配合做好服务相关问题解决。（XXX县区数管局会同A单位落实“XXX”服务安全责任，并配合做好服务相关问题解决。）
附件：1．XX单位关于“XXX”服务上线申请表
2．安全检测报告（检测机构盖章）
服务联系人：（业务联系人，电话）
安全责任人：（对服务安全负责的机关事业单位在职人员，职务电话）
技术人员：（技术联系人，电话）
客服人员：（客服联系人，电话）
XXX单位/XXX县区数管局
Y年M月D日
附件1
XX单位关于“XXX”服务上线申请表
申请单位：（盖章）
服务提供单位基本情况 | 服务提供单位 | |
联系人 | ||
手 机 | ||
服务基本情况 | 服务名称 | |
服务介绍 | ||
服务咨询电话 | ||
数据提供方式 | □前置机提供数据 □提供接口 □xx市政务云数据支撑平台上传 □excel提供 □其他 （请在横线处将提供方式说明清楚） | |
服务展示样式 | ||
申请理由 | ||
附件2
XX服务应用安全测试报告（样表）
检查方式：Nmap等端口扫描工具。
检查要求：对外只允许开启80和443端口。
检查结果：填写端口信息并附图。
检查方式：人工检查。
检查要求：
1.较敏感、 敏感和极敏感数据加密存储；
2.检查数据库表、字段结构信息，查看较敏感、敏感、极敏感数据存储是否满足对应安全要求。
敏感级别定义：
极敏感：私密信息（如：声纹、指纹、金融账号密码）、涉事涉法、资金数量、生理状态、生物特征；
敏感：姓名、详细信息、身份证号（证件号）、电话号码、卡号、车牌、账号密码；
较敏感：特殊职位、地点、知识产权、医疗卫生、出行住宿记录。
检查结果：填写敏感信息数据字段并附图。
检查方式：人工和抓包工具。
检查要求：
1.较敏感数据默认脱敏展示（后端脱敏），如业务需要需明文展示的，应先进行二次身份认证（二次认证有刷脸验证、密码验证和短信验证码三种方式认证）；
2.敏感和极敏感数据默认脱敏展示（后端脱敏），如业务需要需明文展示的， 应先进行二次身份认证，二次身份认证通过后用户可自行在明文展示和脱敏展示之间进行切换；
3.服务端业务日志没有打印或存储敏感信息。
检查结果：填写敏感信息数据字段并附图。
检查方式：抓包工具。
检查要求：
1.使用任意用户A身份,通过修改请求参数的方式，无法获取其他用户数据；
2.使用普通用户身份，无法通过访问管理员类接口的方式获取数据或者进行修改类操作；
3.前端调用后端的接口，必须由后端作二次校验，不能只相信前端页面控制；
4.不相信前端传进来的和权限有关的参数（或者不要让前端传进来和权限有关的参数），而是后端自动获取当前登录用户的权限相关的信息；
5.后端不能只判断用户是否登录，而是还要判断当前用户是否有权限；
6.特别小心传入id来查询或操作的场景，一定要校验当前用户是否有该id的权限。
检查结果：至少需要两张截图, 一张A用户正常的请求，一张A用户修改了URL参数的请求。截图需能看出请求的URL及返回的内容。
检查方式：人工和抓包工具。
检查要求：
1.接口只返回必要的数据给前端，不依赖前端来隐藏数据；
2.由后端来对敏感数据进行脱敏，不依赖于前端进行脱敏。
检查结果：结合业务场景进行测试并附图。
检查方式：人工检查。
检查要求：
1.前端调用后端的接口，必须由后端作二次校验，不能只相信前端页面控制；
2.系统对系统的接口，需要用身份认证机制（比如，appId和appSecret机制、token机制）。
检查结果：结合业务场景进行测试并附图。
检查方式：人工或漏洞扫描工具。
检查要求：
1.检查代码或程序中不含有敏感信息，特别是前端代码；
2.不要在前端代码中存放secret等敏感信息，即使已经加密过的secret；
3.正确配置.gitignore，不要将一些不应该提交的代码或配置文件放到了Web服务器上，特别是前端代码；
4.代码中含有一些测试用的管理用的“秘密”API URL；
5.代码中含有一些过时且保护不当的API URL；
6.防止泄漏代码到互联网上，比如GitHub；
7.在后端服务器上，在受控的服务配置中心来配置敏感信息。
检查结果：检查代码是否有泄漏情况。
检查方式：人工或漏洞扫描工具。
检查要求：系统没有XSS漏洞，用户输入的js代码在展示页面未执行。
检查结果：所有存在输入内容的页面都需进行测试，并且都不存在XSS漏洞。需要结合自己的业务场景进行测试，并截图。
检查方式：人工或漏洞扫描工具。
检查要求：系统没有SQL注入漏洞，程序未执行参数中的sql 语句（禁止拼接 sql 语句,需要使用预编译模式进行数据库操作）。
检查结果：需要结合自己的业务场景进行测试，并附测试情况截图。截图要求: 使用SQLMAP等工具检测证明不存在SQL注入漏洞或将执行SQL语句相关的关键代码进行截图。使得能够看出来未使用拼接SQL语句的方式。
检查方式：人工或漏洞扫描工具。
检查要求：系统没有CSRF漏洞，修改 referer 或 csrf-token 后，增删修改无法执行成功（对增删修改类请求接口的 referer 做白名单校验或在参数中增加随机 csrf-token）。
检查结果：若业务场景涉及信息的增删改，需要进行该项测试，并附测试情况截图。所有接口都需进行测试，并且都不存跨站请求伪造漏洞 漏洞。截图要求: 至少需要两张截图, 一张正常的REFERER或CSRF-TOKEN的请求，一张修改了REFERER或CSRF-TOKEN的请求。截图需能看出请求的内容及返回的内容。或使用APPSCAN等漏洞扫描工具检测证明不存在CSRF漏洞。
检查方式：人工和抓包工具。
检查要求：
1.上传文件类型限制，不能上传html、jsp、asp、cer等可执行文件，使用白名单检验文件后缀，在前端页面及后端都进行限制；使用黑名单规则过滤<、script、eval关键词校验文件内容,在后端进行限制；
2.上传文件查看，不能在应用上预览，或者保证安全的方式在应用里查看。
检查结果：若业务涉及文件的上传，需要进行该项测试，并附截图。
检查方式：人工检查。
检查要求：接口需使用HTTPS协议。
检查结果：是否使用HTTPS协议并附图。
检查方式：人工或工具扫描。
检查要求：同一域名/IP下包括服务本身或管理后台等需要二次登录的服务需要检查是否存在弱密码，如存在则要修改强制使用强密码（强密码的标准是长度大于10位且包括字母，符号和数字，建议使用特殊字符+字母大小写+数字的组合进行设置）。
检查结果：检查系统是否有弱密码。
