威胁风险 | 序 | 消减措施 | 检查说明 | 是否涉及 |
欺骗(认证) | 1 | 使用标准身份验证机制 | 使用客户端证书、基于 Windows认证、基于form表单、联合身份验证 – ADFS(活动目录文件系统)、联合身份验证 – 标识服务器任意一项作为身份认证机制 | |
2 | 安全地处理失败的身份验证 | 1、身份验证失败时,拒绝访问特权资源 2、身份验证失败并且发生访问被拒绝后,显示模糊错误消息 3、帐户认证失败的次数过多后进行锁定 | ||
3 | 安全地实现忘记密码功能 | 1、在重置密码之前,需要实施基于软令牌(例如动态令牌、短信验证码)进行身份验证; 2、发送给用户邮箱的内容是一次性且限时的激活链接(访问后可以修改密码),而不是新密码本身; 3、在“忘记密码”的流程中,不应锁定用户帐户; 4、在尝试“忘记密码”时,显示的错误消息应该模糊化,防止用户名枚举; 5、始终禁止使用旧密码,并实施强密码策略 | ||
4 | 确保密码强度和帐户锁定策略 | 1、大写/小写/数字/符号,四选三,长度不低于8位 2、禁止硬编码密码,初始密码要求修改 3、连续错误五次,锁定2分钟,或者要求输入验证码 | ||
5 | 实施控制来防止用户名枚举 | 1、所有错误消息应该模糊化(如账户或密码错误),以防止用户名枚举; 2、在注册/密码找回等功能必须要告知账户是否注册的情况,需使用验证码等频率限制方法防止自动化攻击 | ||
6 | 启用多重身份验证[可选] | 授予用户对敏感信息的访问权限之前,或执行重大更改操作前,需通过多重身份验证进行升级或自适应的身份验证 | ||
7 | 确保管理界面的访问限制[可选] | 仅授予从某个源IP或网段到管理界面的访问权限 | ||
篡改(授权和加密) | 1 | 处理授权逻辑流时,要求按步骤有序处理 | 若授权逻辑的执行步骤是有序的,且每个步骤执行完成才能进入下一步骤。可以强制要求应用程序按规定步骤,依序处理授权逻辑流,并按照真实的操作时间处理所有步骤,拒绝无序步骤、跳过步骤、由其他用户处理步骤,或者过快提交事务。 | |
2 | 实施速率限制机制来防止枚举 | 1、确保敏感标识符(如Token令牌)是随机的。 2、实施CAPTCHA(验证码)区分用户或者机器。 3、确保错误和异常不会透露特定的数据 | ||
3 | 确保实施适当的授权,并遵循最低特权原则 | 1、可以创建自定义用户角色和角色权限; 2、只授予用户工作所需的特权 | ||
4 | 业务逻辑和资源访问授权决策,不应该基于传入的请求参数 | 检查用户是否有权查看特定的数据时,应该在服务器端处理访问限制 | ||
5 | 不需要公开的内容,需应用访问控制或删除内容本身 | 1、不应在 web 根目录中保留敏感的静态文件(例如web.zip、db.sql等)和配置文件(例如password.properties等)。 2、对于不需要公开的内容,应该应用适当的访问控制或删除内容本身。 | ||
6 | 只使用批准的对称块加密算法、密钥长度、算法模式和初始化向量 | 1、使用高级加密标准AES-128、AES-192 和 AES-256 2、算法模式只允许CBC(密码分组链接模式)和CTS(XTS密文窃取模式),应当避免ECB(电码本模式) 3、初始化向量IV通常是一个强加密型随机数,绝对不会是常量值。 | ||
7 | 使用批准的非对称加密算法、密钥长度和填充 | 1、密钥长度不低于2048位; 2、填充模式需使用OAEP或RSA-KEM,禁止null | ||
8 | 使用批准的随机数生成器 | 1、Java(包括Android):使用java.security.SecureRandom 类 2、Win32/64:CNG使用BCryptGenRandom,CAPI使用cryptGenRandom 3、.NET:使用RNGCryptoServiceProvider 或 RNGCng 4、Apple OS X (10.7+)/iOS(2.0+):使用int SecRandomCopyBytes (SecRandomRef random, size_t count, uint8_t *bytes ) 5、Apple OS X (<10.7):使用 /dev/random | ||
抵赖(日志记录和数字签名) | 1 | 在系统中强制实施日志记录与审核 | 1、识别所有重要事件并记录这些事件; 2、审核日志应捕获用户上下文; 3、实现集中式日志记录 | |
2 | 实施日志轮转和分离 | 1、借助日志轮转来限制日志的总大小,并滚动记录最新的日志信息(默认保留5个日志文件)。 2、日志文件存储在跟应用不同的分区中,避免影响IO读写性能,造成应用性能降级或拒绝服务。 | ||
3 | 日志不要记录敏感的用户数据 | 敏感数据包括: 1、用户凭据(例如账户密码) 2、身份证号或其他身份信息 3、信用卡号或其他财务信息 4、私钥,或者其他可用于解密已加密信息的数据 | ||
4 | 对日志文件设置访问限制 | 应用程序只允许写权限,维护员与审计员只允许读权限,只有管理员帐户才拥有完全访问权限 | ||
5 | 确保记录所有用户管理事件 | 确保应用程序监视所有用户管理事件,包括:用户登录成功与失败状态、密码重置、密码更改、帐户锁定和用户注册,这些措施可帮助检测潜在的可疑行为并对其做出反应。 | ||
6 | 应用内部需设计针对滥用或攻击的防御措施[可选] | 例如,设计了输入验证防御的接口,在攻击者尝试注入与验证规则不匹配的恶意代码时,会触发异常告警。 建议针对以下问题,记录安全异常并采取措施: 1、输入验证(例如限制仅数字、仅字母、无符号,或采用正则表达式验证) 2、暴力破解(例如短时间内某个用户请求数超过上限) 3、文件上传(例如上传了非白名单后缀的文件) | ||
信息泄露(敏感信息保护) | 1 | 不要在错误消息中公开安全详细信息 | 禁止公开Exception类的Message或StackTrace的值,仅公开一般消息(如服务器发送错误,请联系管理员处理),详细错误信息记录到受保护的日志文件或数据库 | |
2 | 不要在浏览器中缓存敏感内容 | 涉及敏感信息的页面请将 cache-control 响应标头值设置为“no-store” | ||
3 | 显式禁用敏感表单的自动填充功能 | 对于敏感表单(例如登录/注册表单)必须显式禁用自动填充功能,如:<form autocomplete=”off”></form> | ||
4 | 默认屏蔽显示敏感数据 | 1、在屏幕上显示密码、信用卡号、身份证号等敏感数据时,应该默认将它们屏蔽或脱敏显示。 2、若需要查看完整敏感信息,可提供“眼睛按钮”,经过进一步身份验证后再显示。 | ||
5 | 确保以加盐哈希格式存储密码 | 使用加盐哈希格式存储密码。其中要求用户的 salt始终唯一,并在存储密码之前应用 b-crypt、s-crypt 或 PBKDF2加密,消除暴力破解的可能性 | ||
6 | 确保数据库列中的敏感数据经过加密 | 银行卡号等敏感数据必须加密存储。可以使用列级加密,或者使用加密函数通过应用程序函数将数据加密。 | ||
特权提升 | 1 | 禁用 XML 实体解析 | 【推荐】禁用实体解析:setFeature(“http://apache.org/xml/features/disallow-doctype-decl”,true); 【方案二】 1、禁用外部实体:setFeature(“http://xml.org/sax/features/external-general-entities”, false); setFeature(“http://xml.org/sax/features/external-parameter-entities”, false); 2、开启安全过程:setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true); | |
2 | 确保接受用户的文件时实施适当的控制 | 针对文件上传功能实施以下安全控制: 1、文件扩展名检查(以白名单的方式限制允许上传的文件类型) 2、设置文件大小上限 3、不应将文件上传到网站根目录,位置应是非系统驱动器上的某个目录 4、应该遵守命名约定,使上传文件的名称具有某种随机性,防止文件覆盖 5、将文件写入磁盘之前,应扫描它是否包含病毒 6、确保验证文件名和其他任何元数据(例如文件路径)是否包含恶意字符 7、应检查文件格式签名,防止用户上传伪装的文件(例如,通过将扩展名更改为 txt 来上传 exe 文件) | ||
3 | 使用类型安全的参数进行数据访问 | 1、带参数的预编译语句; 2、存储过程; 3、白名单输入验证:表或列的名称以及排序顺序指示符等无法参数化,应将参数值映射到合法/期望的表名或列名 | ||
4 | 防止跨站脚本攻击XSS | 1、对用户的输入输出进行过滤,参考ESAPI或doFilter过滤方案。 2、Cookie设置HttpOnly和有效期。 3、限制用户输入数据长度和数据格式。 | ||
5 | 不要将 DOM 元素分配到没有内置编码的接收器 | 不要使用 innerHtml,而是使用innerText。同样,不要使用$(“#elm”).html(),而是使用 $(“#elm”).text(value) | ||
6 | 验证所有重定向是否闭合或安全执行 | 重定向目标限制为站点或域的预定义“安全”列表 | ||
拒绝服务(数据稀释和数据清洗) | 1 | 内容分发网络 CDN | CDN技术能稀释通过域名发起的DDoS攻击的流量,如果攻击者直接通过IP地址进行攻击,就无法稀释流量了。 | |
2 | 任播 Anycast | 使用Anycast技术能够稀释DDoS攻击流量,在Anycast寻址过程中,流量会被导向最近的节点,攻击者不能对流量路径进行操控。 由于Anycast技术的高度可靠性,即使少数节点被DDoS攻击打垮,请求也能够被快速地引导向其他可用的服务器。 | ||
3 | 负载均衡、分布式、集群 | 1、分布式将一个业务拆分成多个子业务部署在不同的服务器,便于针对性扩容,同时若某子业务出了问题,不至于影响整个系统。 2、集群指同一个业务,部署在多台服务器,提高业务健壮性。 3、在服务器集群前端添加负载均衡设备,实现流量分流,解决“访问统一入口问题”。 |