安全编码规范
⼀.上线前通⽤安全开发要求
1.使⽤“经测试和可信的平台/框架代码”开发应⽤程序
2.应⽤系统应当保持对所依赖的框架、第三⽅组件的更新，以避免出现已知漏洞
3.应⽤程序就避免于页⾯（HTML、JavaScript）中包含技术性注释语句、功能说明或解释等信息
html实现用户注册登录代码
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签名机制，防⽌数据在传输过程中被篡改。如⽀付订单等重要且敏感的数据，应当采取数字签名等⽅式，保证数据完整性

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。