2023年7月27日发(作者：)

安全编码规范⼀.上线前通⽤安全开发要求1.使⽤“经测试和可信的平台/框架代码”开发应⽤程序2.应⽤系统应当保持对所依赖的框架、第三⽅组件的更新，以避免出现已知漏洞3.应⽤程序就避免于页⾯（HTML、JavaScript）中包含技术性注释语句、功能说明或解释等信息4.应⽤系统上线前，应删除相应的测试内容，包括但不限于：测试页⾯、测试⽤例、测试代码、控制台输出等5.应⽤系统部署后，应删除默认部署页⾯，禁⽌留存SVN/Git相关⽂件、备份⽂件等6.如果应⽤软件部署在客户端，例如移动APP，应使⽤混淆、签名、加固等措施防⽌逆向获取源代码⼆.输⼊验证与输出净化（⼀切输⼊都是有害的，应当对所有输⼊的参数进⾏合法性、合理性校验）1.应⽤系统应对所有输⼊的参数进⾏合法性、合理性验证，拒绝接受验证失败的数据，包括但不限于验证数据的类型、长度、格式、范围和内容等。 对于输⼊数据范围可确定的场景，合法性检测建议使⽤“⽩名单”的⽅式（⽐如：⽇期、⾝份证号、银⾏卡号、⼿机号、数字等可明确格式的数据，须在服务器端验证格式是否正确） 对于输⼊数据范围不确定的场景，合法性检测可采⽤“⿊名单”的⽅式（⽐如：在可⾃由输⼊的⽂本框过滤或转义SQL关键字、HTML标签、XML标签、单引号、双引号、路径字符、换⾏符、空字节等）根据实际情况设置⿊⽩名单，避免影响业务正常使⽤。2.应⽤系统应对所有输出到客户端、操作系统、web页⾯等位置的数据进⾏编码或过滤净化，避免潜在危险字符，导致安全问题发⽣，包括但不限于：SQL注⼊漏洞、XSS漏洞、命令注⼊漏洞等。 危险字符如 ' " .. / r n < > ^ | ! ` * ( ) & ; - : %等，应当在服务器端进⾏安全过滤或转义编码。

三.⾝份验证与权限控制1.密码输⼊界⾯应采取安全保护措施，包括但不限于：不以明⽂形式显⽰密码、利⽤图形验证码防⽌暴⼒破解等。2.密码的创建应当符合复杂度检测要求 包括但不限于以下要求：静态密码长度⾄少8位，⾄少应同时包含⼤⼩写字母、数字和特殊字符这三类字符中的两类，密码不能与⽤户名相同，避免密码中包含公司特征密码等。3.所有的⾝份验证过程应在可信任环境中执⾏，且在每次⽤户登录时进⾏⾝份验证。避免 仅在客户端⽽⾮服务器端执⾏⾝份验证4.服务端应对验证尝试的频率进⾏限制，连续多次登录失败的，应当对其进⾏限制。 限制同⼀IP地址能够进⾏验证尝试的频率和次数。在超过尝试次数后，封禁IP地址⼀段时间，防⽌攻击者持续进⾏暴⼒破解。 限制同⼀账号能够进⾏验证尝试的频率和次数。在超过尝试次数后，锁定账户⼀段时间，防⽌攻击者持续进⾏暴⼒破解5.在⽤户执⾏关键或者不可逆的操作，如交易时、修改密码之前，应再次验证⽤户⾝份，以减少不安全会话带来的损失，防范跨站请求伪造攻击。6.遵循最⼩权限原则 进⾏权限管理的设计和实现，将许可权限尽可能地细化，建议使⽤细粒度权限管理访问控制。7.⾪属于⽤户个⼈的页⾯或者功能必须进⾏权限控制校验 防⽌⽔平越权漏洞（同级、跨级⽤户之间的越权），避免任意访问、修改、删除他⼈的数据，⽐如查看他⼈的私信内容、修改他⼈的订单。8.确保只有授权的⽤户才能访问秘密数据或敏感数据 这类数据包括：与⽤户信息或应⽤软件⾃⾝安全密切相关的状态信息、⽂件或其他资源、受保护的URL、受保护的功能、直接对象引⽤、应⽤程序数据以及与安全相关的配置信息等。应避免未授权访问。四.⽂件及资源管理1.在上传⽂件前应对⽤户⾝份进⾏验证，并对上传⽂件进⾏验证和控制包括但不限于： 应对上传⽂件的⽂件类型扩展名进⾏验证，还应通过检查⽂件报名头信息的⽅式，验证上传⽂件是否是满⾜业务需要的⽂件类型，避免攻击者上传恶意⽂件。 应对上传⽂件进⾏重命名，如果⽂件名中有路径符号，会在⽂件存储时造成⽂件穿越 ⽂件上传后不应向⽤户返回⽂件保存的绝对路径，避免泄露服务器信息 上传的⽂件不能带有执⾏权限，如果有，需要取消掉⽂件的执⾏权限2.在下载⽂件前应对⽤户⾝份进⾏验证，并对下载⽂件进⾏验证和控制包括但不限于： 验证⽂件的真实路径是否在允许下载范围内。 验证下载⽂件名是否含有../和..防⽌路径遍历导致的任意⽂件下载3.应正确释放资源，及时释放系统资源，禁⽌再次释放已释放的资源，确保释放资源前完全清除敏感信息。4.发⽣异常时，应及时回收并释放系统资源五.会话管理与通信安全1.会话标识应当采⽤随机且唯⼀的不可预测的散列值，具备⾜够强度（⽐如128位），使⽤服务器或者框架的会话管理控制，确保会话标识符的随机性，避免暴⼒散列攻击2.⽤户登录成功后，服务器应更新会话标识符，或者增加IP等其他判断标志，并周期地使旧会话标识符失效。 这可以缓解那些原标识符被获得的特定会话动持情况。3.不应在URL、错误信息或⽇志中暴露会话标识符。 敏感操作应当采⽤POST请求 不要将会话标识符以GET参数进⾏传递，会记录在服务器访问⽇志中4.应设置会话令牌有效期，建议公⽹系统会话有效时间不超过30分钟5.⽤户注销时应当⽴即清理当前⽤户会话6.在通信过程中，对敏感信息应进⾏加密并使⽤加密通道传输。使⽤安全的协议，禁⽌使⽤SSL V2和V3，建议使⽤TLS V1.2 为所有要求⾝份验证的访问内容和所有其他的敏感信息提供TLS连接六.异常处理与⽇志审计1.精确捕获异常，并对捕获的异常进⾏恰当的处理，避免在捕获异常后不做任何处理2.当奶瓶vtg时，不要将系统产⽣的异常信息直接反馈给⽤户包括但不限于：系统的详细信息、会话标识、账号信息、调试或堆栈跟踪信息、源代码⽚段等。3.应创建默认的错误页⾯，使⽤通⽤的错误消息提⽰，防⽌攻击者从出错页⾯中得到⼀些敏感的系统信息。4.不要在⽇志中保存敏感信息。对⽇志记录的内容进⾏审核，防⽌将关键级敏感信息写⼊⽇志 ⽇志记录中不得以任何形式保存密码、密钥等⾼敏感性数据，其他敏感信息仅应在脱敏或加密的前提下保存。5.使⽤信息摘要算法以验证⽇志记录的完整性。6.对⽇志中的特殊元素进⾏过滤和验证。确保⽇志记录中的不可信数据，不会在查看界⾯或者运⾏软件时以代码的形式被执⾏ r n等换⾏符的录⼊，可能会造成⽇志内容换⾏，从⾯篡改⽇志内容。 如果⽇志中存在恶意代码，在页⾯读取展⽰时，可能会造成恶意代码执⾏，如XSS攻击、⼀句话⽊马等七.敏感数据加密与保护1.保护重要秘密信息免受未授权访问。 明确应⽤系统中的敏感数据、隐私数据的范围，以及有权访问这些数据的⽤户范围。 对数据的授权访问遵循最⼩权限原则2.⽤户敏感信息，在页⾯显⽰和传输过程中应注意脱敏和加密，数据库中也应当进⾏加密存储，避免数据库端信息泄露。3.⽤于访问系统资源的系统⽤户、密码、密钥必须加密保存在配置⽂件中，同时要求配置参数要统⼀集中管理，避免同⼀个参数在多个配置⽂件中保存。4.代码中不应当出现硬编码的敏感信息，如⽤户名、密码、IP地址、公司邮箱等。5.数据库中存储的⽤户密码等鉴别信息，应使⽤不可逆的加密算法（国密SM3、SHA-512），并进⾏加盐Salted处理，然后将盐和密码哈希值⼀起保存在数据库中，或通过加密机完成加密。 推荐如下加密算法： ⾮对称加密算法：SM2、RSA 对称加密算法：SM4、3DES、AES 散列算法：SM3、SHA2566.使⽤安全的随机数⽣成器，避免将具有密码学弱点的伪随机数⽣成器⽤于加密场景⼋.业务安全1.在使⽤平台资源，譬如短信、邮件、电话、下单、⽀付，必须实现正确的防重机制，如数量限制、接⼝请求频率限制、验证码⼈机校验，避免被滥刷⽽导致的资损 如注册时发送验证码到⼿机，如果没有限制次数和频率，那么可以利⽤此功能骚扰到其他⽤户，并造成短信平台门资源浪费2.在调⽤接⼝时，应该采取API签名机制，防⽌数据在传输过程中被篡改。如⽀付订单等重要且敏感的数据，应当采取数字签名等⽅式，保证数据完整性