一、代码安全 · 凡普金科开发规范

## 一、代码安全 ### （一）框架与组件 1. 【强制】禁止使用高危安全漏洞频发的第三方开发框架和组件，如：Struts。 > **说明**：近年来，Struts框架频繁爆发能够导致服务器入侵事件的安全漏洞，对线上安全影响极大。 2. 【推荐】尽量避免使用长期无人维护的第三方开发框架和组件。 > **说明**：长期无人维护的第三方框架、组件，一旦被发现安全漏洞，难以得到官方的修复或升级，造成漏洞修复响应时间长、难度大，更容易被攻击者利用。 3. 【推荐】不在代码中引入不受控的第三方资源，如：CSS、js文件等。 ### （二）用户请求 1. 【强制】用户可控的输入参数必须做有效性验证。 > **说明**： > 未做参数校验可以引发多种类型的漏洞，包括但不限于： > * 跨站脚本攻击（XSS） > * SQL注入 > * 错误的URL解析，可能导致服务端请求伪造（SSRF）或任意URL跳转 > * 命令执行及代码执行 > * 文件遍历 > * HTTP响应分割（CRLF） > * 反序列化注入 > * LDAP注入 > * XML 实体注入、XPath注入 > * 恶意order by导致数据库慢查询，引发应用拒绝服务 > * 用户输入的正则表达式导致ReDoS 2. 【强制】禁止在页面中直接输出未通过正确安全过滤或转义的用户可控输入（包含用户输入并存储于数据库中的数据）。 > **说明**：为防止跨站脚本攻击（XSS），应进行输入过滤或输出转义，建议使用输出转义。 > > **示例**：<为`<`，>为&`gt;`，&为`&`，'为&`#x27;`，"为`"`。 3. 【强制】用户可控的用于执行SQL查询的参数，必须使用ORM、预编译等参数化封装形式，禁止直接拼接SQL字符串访问数据库。 > **说明**：如果用户输入为数据库表名，则应使用正则表达式判断，仅允许`[a-zA-Z0-9_-]`。 4. 【强制】禁止使用存在用户可控输入的系统命令、代码执行语句。如必须使用，应做好输入校验，并由安全组进行审核。 > **说明**：用户可控的系统命令、代码执行，可以导致攻击者写入WebShell到服务器中，导致服务器被入侵。 5. 【强制】禁止在线上应用、服务器中留存可执行系统命令的后门，用于服务器变更、代码调试等。 6. 【强制】用户请求中的URL参数，应当仅允许http、https协议，且使用白名单限定域名/IP，防范服务端请求伪造（SSRF）及钓鱼攻击。 > **说明**： > a) 如果允许非http、https协议请求，可能通过javascript、file、gopher等协议，造成XSS、文件遍历、命令执行等漏洞。 > b) 应使用语言自带的方法提取URL中的host。 > c) 如果URL用于服务端请求网页或下载文件，应当统一返回信息，使攻击者无法判断请求失败的原因。如无法使用白名单进行判断，应使用黑名单屏蔽内网请求，此时需注意302跳转、DNS解析、数值格式IP、IPV6等绕过方法。 > d) 短链接跳转应用应使用独立的主域名。 7. 【强制】如存在请求体为XML格式的请求，应当禁用XML外部实体。 8. 【强制】增删改操作的表单、AJAX请求必须执行CSRF安全过滤，且使用POST方法传输。 > **说明**：当增删改操作的URL中，请求参数可被预测时，攻击者可事先构造好URL，诱使受害者访问，此时用户即在不知情的状态下，执行了增删改操作。当使用GET方法执行增删改操作时，即使是普通的流量重放或黑盒扫描，都会对业务数据产生影响。 9. 【强制】上传文件应在后端进行有效验证，并存储在外网不可直接访问的位置。 > **说明**： > **上传文件需使用如下方式进行验证及处理**： > a) 白名单限制后缀。 > b) 验证请求头的Content-Type。 > c) 文件重命名，包含随机字符串，且不包含用户可控字符串。 > d) 图片执行resize、加水印等处理，破坏图片原有结构。 > > **上传文件存储应满足如下条件**： > a) 一般情况下，应存储于不对外网开放的存储服务器中。 > b) 如必须存储于Web服务器本地，则需放置在非Web目录，并禁用脚本执行权限和文件执行权限。 10. 【强制】上传、编辑、查看、下载、删除文件时，应当限定可操作的目录范围，避免跨目录操作。 > **说明**：过滤`../`，避免路径目录变更。最终的拼接结果应与限定目录比对，确认是否仍在该目录中。 ### （三）账号与权限 1. 【推荐】用户登录、注册、用户名检测功能应使用验证码等人机交互手段,限制用户请求次数及频率。 2. 【强制】用户登录失败时，应使用统一的出错信息。 > **说明**：如果用户名不存在和密码错误使用不同的出错信息，则攻击者可以通过撞库的手段确认用户名是否存在、密码是否错误；如使用统一的出错信息，则攻击者无法确定登录失败的原因是用户不存在还是密码错误。 3. 【强制】密码修改时，需通过session等手段正确判断当前用户，并对原密码进行校验。 4. 【强制】密码重置时，返回凭证应随机不可猜测，且设置访问次数、频率和有效期限制，操作成功后立即失效，不应在前端代码中出现。 5. 【强制】隶属于用户个人的页面或者功能必须进行权限控制校验。 > **说明**：防止未做水平/垂直权限校验时，用户可对其他用户（同级别或更高级别）的数据进行增删改查操作。 > **建议**：定义权限与角色，为每个用户分配角色，做到最小权限、默认拒绝。应通过session判断当前用户。避免使用可遍历的参数。 ### （四）敏感信息 1. 【强制】用户敏感数据禁止直接对外展示，必须对展示数据做脱敏处理。 > **说明**： > **页面展示数据包括如下几种场景**： > a) 无需登录，直接对外展示的数据。 > b) 登录后，对任意用户或特定用户展示的他人数据。 > c) 登录后，对用户自己展示的数据。 > d) 登录后，使用二次验证手段，才对用户自己展示的数据。 > 其中，a、b两种场景由于存在对外展示，必须做脱敏处理；c、d两种场景可依据业务需求决定是否脱敏。 > > **示例（建议）**： > 手机号：显示前3后4位，如138\*\*\*\*8000。 > 证件号（身份证、护照等）：仅显示首位3位和末位2位，如610\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*20。 > 姓名：仅显示名，如\*钱进。 > 银行卡号：仅显示最后4位，如\*\*\*\*\*\*\*\*\*\*\*\*1234。 > 邮箱：仅显示前3位和邮箱域名，其余位使用3个星号（不按照实际字符数），如iqi\*\**@163.com。 2. 【推荐】员工使用的管理后台中，敏感信息默认不显示或脱敏显示，如需获取未脱敏数据，应通过点击按钮等手段，避免批量获取。员工获取未脱敏数据时，应在日志中记录。 3. 【强制】测试环境数据必须进行脱敏处理，严禁将生产数据直接用于测试。 4. 【强制】管理后台不对外网开放，且应当设置账号、证书、IP限制等访问控制措施，防止任意员工直接访问。 5. 【强制】关闭调试信息显示，统一4XX、5XX等出错页面，禁止在出错页面上直接显示用户输入或显示数据库错误信息。 > **说明**：调试、出错页面可能泄露Web容器、应用版本、源代码等敏感信息。直接显示用户输入的错误信息可能引起XSS漏洞。页面中显示数据库出错信息，可能导致数据库信息泄露。 ### （五）流程逻辑 1. 【强制】在使用集团资源时，必须实现正确的防重放机制。如有用户可控输入，应当对用户输入进行审核。 > **说明**： > 未使用或不正确的防重放机制，可以造成用户被骚扰、公司资损。未对用户输入进行有效限制，可能会存在用户发送广告或违法信息的风险。 > > **集团资源**包括但不限于：短信、电话、邮件、支付。 > > **防重放机制**包括： > a) 限制数量、频率和有效期。 > b) 使用验证码等人机交互手段，验证码需在每次请求后立即失效更新。 > c) 判断referer来源是否为本站。 2. 【推荐】使用验证码时，应在服务端进行校验，并对验证码的请求频率、次数进行限制。 > **说明**： > **验证码的处理要求**： > a）图形验证码至少需要4位字母、数字混合，手机验证码至少需要6位纯数字或4位字母、数字混合。 > b）设置验证码请求频率，一定时间内请求次数过多的用户应当予以拒绝。 > c）验证码需要在服务端进行校验，并设置有效期。对于图形验证码，每次请求（无论是否成功）、超出有效期均应失效重新生成。