安全编码规范

一.上线前通用安全开发要求
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、SHA256
6.使用安全的随机数生成器，避免将具有密码学弱点的伪随机数生成器用于加密场景

八.业务安全
1.在使用平台资源，譬如短信、邮件、电话、下单、支付，必须实现正确的防重机制，如数量限制、接口请求频率限制、验证码人机校验，避免被滥刷而导致的资损
    如注册时发送验证码到手机，如果没有限制次数和频率，那么可以利用此功能骚扰到其他用户，并造成短信平台门资源浪费
2.在调用接口时，应该采取API签名机制，防止数据在传输过程中被篡改。如支付订单等重要且敏感的数据，应当采取数字签名等方式，保证数据完整性