Golang 安全编码规范(Web和后端)

身份验证和密码管理:

  • 除了那些特定设为“公开”的内容以外,对所有的网页和资源要求身份验证。
  • 所有的身份验证过程必须在可信系统(比如:服务器)上执行。
  • 在任何可能的情况下,建立并使用标准的、已通过测试的身份验证服务。
  • 为所有身份验证控制使用一个集中实现的方法,其中包括利用库文件请求外部身份验证服
    务。
  • 将身份验证逻辑从被请求的资源中隔离开,并使用重定向到或来自集中的身份验证控制。
  • 所有的身份验证控制应当安全的处理未成功的身份验证。
  • 所有的管理和账户管理功能至少应当具有和主要身份验证机制一样的安全性。
  • 如果您的应用程序管理着凭证的存储,那么应当保证只保存了通过使用强加密单向 salted 哈希
    算法得到的密码,并且只有应用程序具有对保存密码和密钥的表/文件的写权限(如果可以避
    免的话,不要使用 MD5 算法)。
  • 密码哈希必须在可信系统(比如:服务器)上执行。
  • 只有当所有的数据输入以后,才进行身份验证数据的验证,特别是对连续身份验证机制。
  • 身份验证的失败提示信息应当避免过于明确。比如:可以使用“用户名和/或密码错误”,而不
    要使用“用户名错误”或者“密码错误”。错误提示信息在显示和源代码中应保持一致。
  • 为涉及敏感信息或功能的外部系统连接使用身份验证。
  • 用于访问应用程序以外服务的身份验证凭据信息应当加密,并存储在一个可信系统(比如:
    服务器)中受到保护的地方。源代码不是一个安全的地方。
  • 只使用 HTTP Post 请求传输身份验证的凭据信息。
  • 非临时密码只在加密连接中发送或作为加密的数据(比如,一封加密的邮件)。通过邮件重
    设临时密码可以是一个例外。
  • 通过政策或规则加强密码复杂度的要求(比如:要求使用字母、数字和/或特殊符号)。身份
    验证的凭据信息应当足够复杂以对抗在其所部署环境中的各种威胁攻击。
  • 通过政策和规则加强密码长度要求。常用的是 8 个字符长度,但是 16 个字符长度更好,或者
    考虑使用多单词密码短语。
  • 输入的密码应当在用户的屏幕上模糊显示(比如:在 Web 表单中使用“password”输入类
    型)。
  • 当连续多次登录失败后(比如:通常情况下是 5 次),应强制锁定账户。账户锁定的时间必须
    足够长,以阻止暴力攻击猜测登录信息,但是不能长到允许执行一次拒绝服务攻击。
  • 密码重设和更改操作需要类似于账户创建和身份验证的同样控制等级。
  • 密码重设问题应当支持尽可能随机的提问(比如:“最喜爱的书”是一个坏的问题,因为《圣
    经》是最常见的答案)。
  • 如果使用基于邮件的重设,只将临时链接或密码发送到预先注册的邮件地址。
  • 临时密码和链接应当有一个短暂的有效期。
  • 当再次使用临时密码时,强制修改临时密码。
  • 当密码重新设置时,通知用户。
  • 阻止密码重复使用。
  • 密码在被更改前应当至少使用了一天,以阻止密码重用攻击。
  • 根据政策或规则的要求,强制定期更改密码。关键系统可能会要求更频繁的更改。更改时间
    周期必须进行明确。
  • 为密码填写框禁用“记住密码”功能。
  • 用户账号的上一次使用信息(成功或失败)应当在下一次成功登录时向用户报告。
  • 执行监控以确定针对使用相同密码的多用户帐户攻击。当用户 ID 可以被得到或被猜到时,该
    攻击模式用来绕开标准的锁死功能。
  • 更改所有厂商提供的默认用户 ID 和密码,或者禁用相关帐号。
  • 在执行关键操作以前,对用户再次进行身份验证。
  • 为高度敏感或重要的交易账户使用多因子身份验证机制。
  • 如果使用了第三方身份验证的代码,仔细检查代码以保证其不会受到任何恶意代码的影响。

会话管理:

  • 使用服务器或者框架的会话管理控制。应用程序应当只识别有效的会话标识符。
  • 会话标识符必须总是在一个可信系统(比如:服务器)上创建。
  • 会话管理控制应当使用通过审查的算法以保证足够的随机会话标识符。
  • 为包含已验证的会话标识符的 cookie 设置域和路径,以为站点设置一个恰当的限制值。
  • 注销功能应当完全终止相关的会话或连接。
  • 注销功能应当可用于所有受身份验证保护的网页。
  • 在平衡的风险和业务功能需求的基础上,设置一个尽量短的会话超时时间。通常情况下,应
    当不超过几个小时。
  • 禁止连续的登录并强制执行周期性的会话终止,即使是活动的会话。特别是对于支持富网络
    连接或连接到关键系统的应用程序。终止时机应当可以根据业务需求调整,并且用户应当收
    到足够的通知已减少带来的负面影响。
  • 如果一个会话在登录以前就建立,在成功登录以后,关闭该会话并创建一个新的会话。
  • 在任何重新身份验证过程中建立一个新的会话标识符。
  • 不允许同一用户 ID 的并发登录。
  • 不要在 URL、错误信息或日志中暴露会话标识符。会话标识符应当只出现在 HTTP cookie 头
    信息中。比如,不要将会话标识符以 GET 参数进行传递。
  • 通过在服务器上使用恰当的访问控制,保护服务器端会话数据免受来自服务器其他用户的未
    授权访问。
  • 生成一个新的会话标识符并周期性地使旧会话标识符失效(这可以缓解那些原标识符被获得
    的特定会话劫持情况)。
  • 在身份验证的时候,如果连接从 HTTP 变为 HTTPS,则生成一个新的会话标识符。在应用程
    序中,推荐持续使用 HTTPS,而非在 HTTP 和 HTTPS 之间转换。
  • 为服务器端的操作执行标准的会话管理,比如,通过在每个会话中使用强随机令牌或参数来
    管理账户。该方法可以用来防止跨站点请求伪造攻击。
  • 通过在每个请求或每个会话中使用强随机令牌或参数,为高度敏感或关键的操作提供标准的
    会话管理。
  • 为在 TLS 连接上传输的 cookie 设置“安全”属性。
  • 将 cookie 设置为 HttpOnly 属性,除非在应用程序中明确要求了客户端脚本程序读取或者设置
    cookie 的值。

访问控制:

  • 只使用可信系统对象(比如:服务器端会话对象)以做出访问授权的决定。
  • 使用一个单独的全站点部件以检查访问授权。这包括调用外部授权服务的库文件。
  • 安全的处理访问控制失败的操作。
  • 如果应用程序无法访问其安全配置信息,则拒绝所有的访问。
  • 在每个请求中加强授权控制,包括:服务器端脚本产生的请求,“includes”和来自象 AJAX 和
    FLASH 那样的富客户端技术的请求。
  • 将有特权的逻辑从其他应用程序代码中隔离开。
  • 限制只有授权的用户才能访问文件或其他资源,包括那些应用程序外部的直接控制。
  • 限制只有授权的用户才能访问受保护的 URL。
  • 限制只有授权的用户才能访问受保护的功能。
  • 限制只有授权的用户才能访问直接对象引用。
  • 限制只有授权的用户才能访问服务。
  • 限制只有授权的用户才能访问应用程序数据。
  • 限制通过使用访问控制来访问用户、数据属性和策略信息。
  • 限制只有授权的用户才能访问与安全相关的配置信息。
  • 服务器端执行的访问控制规则和表示层实施的访问控制规则必须匹配。
  • 如果状态数据必须存储在客户端,使用加密算法,并在服务器端检查完整性以捕获状态的改
    变。
  • 强制应用程序逻辑流程遵照业务规则。
  • 限制单一用户或设备在一段时间内可以执行的事务数量。事务数量/时间应当高于实际的业务
    需求,但也应该足够低以判定自动化攻击。
  • 仅使用“referer”头作为补偿性质的检查,它永远不能被单独用来进行身份验证检查,因为它可
    以被伪造。
  • 如果长的身份验证会话被允许,周期性的重新验证用户的身份,以确保他们的权限没有改
    变。如果发生改变,注销该用户,并强制他们重新执行身份验证。
  • 执行帐户审计并将没有使用的帐号强制失效(比如:在用户密码过期后的 30 天以内)。
  • 应用程序必须支持帐户失效,并在帐户停止使用时终止会话(比如:角色、职务状况、业务
    处理的改变,等等)。
  • 服务帐户,或连接到或来自外部系统的帐号,应当只有尽可能小的权限。
  • 建立一个“访问控制政策”以明确一个应用程序的业务规则、数据类型和身份验证的标准或处理
    流程,确保访问可以被恰当的提供和控制。这包括了为数据和系统资源确定访问需求。

加密规范:

  • 所有用于保护来自应用程序用户秘密信息的加密功能都必须在一个可信系统(比如:服务
    器)上执行。
  • 保护主要秘密信息免受未授权的访问。
  • 安全的处理加密模块失败的操作。
  • 为防范对随机数据的猜测攻击,应当使用加密模块中已验证的随机数生成器生成所有的随机
    数、随机文件名、随机 GUID 和随机字符串。
  • 应用程序使用的加密模块应当遵从 FIPS 140-2 或其他等同的标准(请见:
    http://csrc.nist.gov/groups/STM/cmvp/validation.html)。
  • 建立并使用相关的政策和流程以实现加、解密的密钥管理。

错误处理和日志:

  • 不要在错误响应中泄露敏感信息,包括:系统的详细信息、会话标识符或者帐号信息。
  • 使用错误处理以避免显示调试或堆栈跟踪信息。
  • 使用通用的错误消息并使用定制的错误页面。
  • 应用程序应当处理应用程序错误,并且不依赖服务器配置。
  • 当错误条件发生时,适当的清空分配的内存。
  • 在默认情况下,应当拒绝访问与安全控制相关联的错误处理逻辑。
  • 所有的日志记录控制应当在可信系统(比如:服务器)上执行。
  • 日志记录控制应当支持记录特定安全事件的成功或者失败操作。
  • 确保日志记录包含了重要的日志事件数据。
  • 确保日志记录中包含的不可信数据,不会在查看界面或者软件时以代码的形式被执行。
  • 限制只有授权的个人才能访问日志。
  • 为所有的日志记录采用一个主要的常规操作。
  • 不要在日志中保存敏感信息,包括:不必要的系统详细信息、会话标识符或密码。
  • 确保一个执行日志查询分析机制的存在。
  • 记录所有失败的输入验证。
  • 记录所有的身份验证尝试,特别是失败的验证。
  • 记录所有失败的访问控制。
  • 记录明显的修改事件,包括对于状态数据非期待的修改。
  • 记录连接无效或者已过期的会话令牌尝试。
  • 记录所有的系统例外。
  • 记录所有的管理功能行为,包括对于安全配置设置的更改。
  • 记录所有失败的后端 TLS 链接。
  • 记录加密模块的错误。
  • 使用加密哈希功能以验证日志记录的完整性。

数据保护:

  • 授予最低权限,以限制用户只能访问为完成任务所需要的功能、数据和系统信息。
  • 保护所有存放在服务器上缓存的或临时拷贝的敏感数据,以避免非授权的访问,并在临时工
    作文件不再需要时被尽快清除。
  • 即使在服务器端,任然要加密存储的高度机密信息,比如,身份验证的验证数据。总是使用
    已经被很好验证过的算法,更多指导信息请参见“加密规范”部分。
  • 保护服务器端的源代码不被用户下载。
  • 不要在客户端上以明文形式或其他非加密安全模式保存密码、连接字符串或其他敏感信息。
    这包括嵌入在不安全的形式中:MS viewstate、Adobe flash 或者已编译的代码。
  • 删除用户可访问产品中的注释,以防止泄露后台系统或者其他敏感信息。
  • 删除不需要的应用程序和系统文档,因为这些也可能向攻击者泄露有用的信息。
  • 不要在 HTTP GET 请求参数中包含敏感信息。
  • 禁止表单中的自动填充功能,因为表单中可能包含敏感信息,包括身份验证信息。
  • 禁止客户端缓存网页,因为可能包含敏感信息。“Cache-Control: no-store”,可以和 HTTP 报头
    控制“Pragma: no-cache”一起使用,该控制不是非常有效,但是与 HTTP/1.0 向后兼容。
  • 应用程序应当支持,当数据不再需要的时候,删除敏感信息(比如:个人信息或者特定财务
    数据)。
  • 为存储在服务器中的敏感信息提供恰当的访问控制。这包括缓存的数据、临时文件以及只允
    许特定系统用户访问的数据。

通讯安全:

  • 为所有敏感信息采用加密传输。其中应该包括使用 TLS 对连接的保护,以及支持对敏感文件
    或非基于 HTTP 连接的不连续加密。
  • TLS 证书应当是有效的,有正确且未过期的域名,并且在需要时,可以和中间证书一起安装。
  • 没有成功的 TLS 连接不应当后退成为一个不安全的连接。
  • 为所有要求身份验证的访问内容和所有其他的敏感信息提供 TLS 连接。
  • 为包含敏感信息或功能、且连接到外部系统的连接使用 TLS。
  • 使用配置合理的单一标准 TLS 连接。
  • 为所有的连接明确字符编码。
  • 当链接到外部站点时,过滤来自 HTTP referer 中包含敏感信息的参数。

系统配置:

  • 确保服务器、框架和系统部件采用了认可的最新版本。
  • 确保服务器、框架和系统部件安装了当前使用版本的所有补丁。
  • 关闭目录列表功能。
  • 将 Web 服务器、进程和服务的账户限制为尽可能低的权限。
  • 当例外发生时,安全的进行错误处理。
  • 移除所有不需要的功能和文件。
  • 在部署前,移除测试代码和产品不需要的功能。
  • 通过将不进行对外检索的路径目录放在一个隔离的父目录里,以防止目录结构在 robots.txt 文
    档中暴露。然后,在 robots.txt 文档中“禁止”整个父目录,而不是对每个单独目录的“禁止”。
  • 明确应用程序采用哪种 HTTP 方法:GET 或 POST,以及是否需要在应用程序不同网页中以不
    同的方式进行处理。
  • 禁用不需要的 HTTP 方法,比如 WebDAV 扩展。如果需要使用一个扩展的 HTTP 方法以支持
    文件处理,则使用一个好的经过验证的身份验证机制。
  • 如果 Web 服务器支持 HTTP1.0 和 1.1,确保以相似的方式对它们进行配置,或者确保您理解
    了它们之间可能存在差异(比如:处理扩展的 HTTP 方法)。
  • 移除在 HTTP 相应报头中有关 OS、Web 服务版本和应用程序框架的无关信息。
  • 应用程序存储的安全配置信息应当可以以可读的形式输出,以支持审计。
  • 使用一个资产管理系统,并将系统部件和软件注册在其中。
  • 将开发环境从生成网络隔离开,并只提供给授权的开发和测试团队访问。开发环境往往没有
    实际生成环境那么安全,攻击者可以使用这些差别发现共有的弱点或者是可被利用的漏洞。
  • 使用一个软件变更管理系统以管理和记录在开发和产品中代码的变更。

数据库安全:

  • 使用强类型的参数化查询方法。
  • 使用输入验证和输出编码,并确保处理了元字符。如果失败,则不执行数据库命令。
  • 确保变量是强类型的。
  • 当应用程序访问数据库时,应使用尽可能最低的权限。
  • 为数据库访问使用安全凭证。
  • 连接字符串不应当在应用程序中硬编码。连接字符串应当存储在一个可信服务器的独立配置
    文件中,并且应当被加密。
  • 使用存储过程以实现抽象访问数据,并允许对数据库中表的删除权限。
  • 尽可能地快速关闭数据库连接。
  • 删除或者修改所有默认的数据库管理员密码。使用强密码、强短语,或者使用多因子身份验
    证。
  • 关闭所有不必要的数据库功能(比如:不必要的存储过程或服务、应用程序包、仅最小化安
    装需要的功能和选项(表面范围缩减))。
  • 删除厂商提供的不必要的默认信息(比如:数据库模式示例)。
  • 禁用任何不支持业务需求的默认帐户。
  • 应用程序应当以不同的凭证为每个信任的角色(比如:用户、只读用户、访问用户、管理
    员)连接数据库。

文件管理:

  • 不要把用户提交的数据直接传送给任何动态调用功能。
  • 在允许上传一个文档以前进行身份验证。
  • 只允许上传满足业务需要的相关文档类型。
  • 通过检查文件报头信息,验证上传文档是否是所期待的类型。只验证文件类型扩展是不够
    的。
  • 不要把文件保存在与应用程序相同的 Web 环境中。文件应当保存在内容服务器或者数据库
    中。
  • 防止或限制上传任意可能被 Web 服务器解析的文件。
  • 关闭在文件上传目录的运行权限。
  • 通过装上目标文件路径作为使用了相关路径或者已变更根目录环境的逻辑盘,在 UNIX 中实现
    安全的文件上传服务。
  • 当引用已有文件时,使用一个白名单记录允许的文件名和类型。验证传递的参数值,如果与
    预期的值不匹配,则拒绝使用,或者使用默认的硬编码文件值代替。
  • 不要将用户提交的数据传递到动态重定向中。如果必须允许使用,那么重定向应当只接受通
    过验证的相对路径 URL。
  • 不要传递目录或文件路径,使用预先设置路径列表中的匹配索引值。
  • 绝对不要将绝对文件路径传递给客户。
  • 确保应用程序文件和资源是只读的。
  • 对用户上传的文件扫描进行病毒和恶意软件。

内存管理:

  • 对不可信数据进行输入和输出控制。
  • 重复确认缓存空间的大小是否和指定的大小一样。
  • 当使用允许多字节拷贝的函数时,比如 strncpy(),如果目的缓存容量和源缓存容量相等时,需
    要留意字符串没有 NULL 终止。

  • 如果在循环中调用函数时,检查缓存大小,以确保不会出现超出分配空间大小的危险。

  • 在将输入字符串传递给拷贝和连接函数前,将所有输入的字符串缩短到合理的长度。
  • 关闭资源时要特别注意,不要依赖垃圾回收机制(比如:连接对象、文档处理,等)。
  • 在可能的情况下,使用不可执行的堆栈。
  • 避免使用已知有漏洞的函数(比如:printf,strcat,strcpy,等)。
  • 当方法结束时和在所有的退出节点时,正确地清空所分配的内存。

通用编码规范:

  • 为常用的任务使用已测试且已认可的托管代码,而不创建新的非托管代码。
  • 使用特定任务的内置 API 以执行操作系统的任务。不允许应用程序直接将代码发送给操作系
    统,特别是通过使用应用程序初始的命令 shell。
  • 使用校验和或哈希值验证编译后的代码、库文件、可执行文件和配置文件的完整性。
  • 使用死锁来防止多个同时发送的请求,或使用一个同步机制防止竞态条件。
  • 在同时发生不恰当的访问时,保护共享的变量和资源。
  • 在声明时或在第一次使用前,明确初始化您的所有变量和其他数据存储。
  • 当应用程序运行发生必须提升权限的情况时,尽量晚点提升权限,并且尽快放弃所提升的权
    限。
  • 通过了解您使用的编程语言的底层表达式以及它们是如何进行数学计算,从而避免计算错
    误。密切注意字节大小依赖、精确度、有无符合、截尾操作、转换、字节之间的组合、
    “not-a-number”计算、以及对于编程语言底层表达式如何处理非常大或者非常小的数。
  • 不要将用户提供的数据传递给任何动态运行的功能。
  • 限制用户生成新代码或更改现有代码。
  • 审核所有从属的应用程序、第三方代码和库文件,以确定业务的需要,并验证功能的安全
    性,因为它们可能产生新的漏洞。
  • 执行安全更新。如果应用程序采用自动更新,则为您的代码使用加密签名,以确保的您的下
    载客户端验证这些签名。使用加密的信道传输来自主机服务器的代码。

发表评论

电子邮件地址不会被公开。 必填项已用*标注