缺乏审计记录会限制检测和响应安全相关事件的能力，并导致无法进行取证调查。

可破坏日志记录功能的配置设置包括但不限于：
- 故意禁用审计日志记录
- 不记录特定用户、组或流程的操作
- 不充分保护日志完整性
- 不启用可选的审计日志记录
- 降低日志采样率

Terraform 配置设置了一个虚拟机子网，但未指定日志记录选项。这些日志包含用于网络监控、取证、实时安全分析和费用优化的重要数据。

权限管理不善会增加未经授权访问或修改数据的风险，且会破坏服务可用性。

服务帐户是应用程序或虚拟机（而非人员）使用的特殊 Google 帐户，它使用敏感权限来运行自动化流程或代表最终用户发出 API 请求。该帐户应仔细管理、控制和审核，以便其可以信任。将服务帐户角色分配给 IAM 用户（通常表示人员）会削弱安全控制。

未能阻止不需要的网络流量会扩大云服务的攻击面。向公众开放的服务会受到恶意实体近乎持续的扫描和探测。

未对静态数据启用客户管理的加密密钥 (CMEK)。

默认情况下，Google Cloud 使用随机生成的数据加密密钥 (DEK) 来加密静态数据。CMEK 功能允许组织使用他们选择的加密密钥来加密 DEK。这使组织可以更好地控制和记录加密过程。

因此，CMEK 通常是满足以下要求的解决方案的一部分，包括但不限于：
- 敏感数据访问的审核日志
- 数据驻留
- 更换、禁用或销毁密钥
- 防篡改硬件安全模块

未对静态数据启用客户管理的加密密钥 (CMEK)。

默认情况下，Google Cloud 使用随机生成的数据加密密钥 (DEK) 来加密静态数据。CMEK 功能允许组织使用他们选择的加密密钥来加密 DEK。这使组织可以更好地控制和记录加密过程。

因此，CMEK 通常是满足以下要求的解决方案的一部分，包括但不限于：
- 敏感数据访问的审核日志
- 数据驻留
- 更换、禁用或销毁密钥
- 防篡改硬件安全模块

URL 映射是一组规则，用于将传入的 HTTP(S) 请求路由到特定的后端服务。默认情况下，URL 映射接受未加密和不安全的连接。这些连接会使数据面临未经授权的访问、潜在的盗用和篡改风险。

示例 1：以下示例显示的 Terraform 配置定义了一个 URL 映射，该映射通过将 https_redirect 设置为 false，允许客户端使用 HTTP 进行通信。

resource "google_compute_url_map" "urlmap" {
...
  default_url_redirect {
...
    https_redirect = false
...
  }
...
}

DNSSEC 能够使用数字签名执行 DNS 响应验证，从而防止 DNS 欺骗。然而，任何使用 SHA-1 的 DNSSEC 签名算法都容易受到不断增加的攻击风险的影响。与数字签名一起使用时，SHA-1 不再被视为安全散列算法。

示例 1：以下示例显示的 Terraform 配置使用不安全的签名算法 rsasha1 启用 DNSSEC。

resource "google_dns_managed_zone" "zone-demo" {
...
  dnssec_config {
    default_key_specs {
      algorithm = "rsasha1"
      ...
    }
  }
...
}

GKE 支持两种群集网络模式：基于路由和 VPC-native。VPC-native 群集使用别名 IP 地址范围将流量从节点中的一个 Pod 路由到另一个 Pod。这为 Pod 提供了基于 IP 的精确策略和防火墙规则。相反，在基于路由的群集中，整个节点是最精细的控制粒度级别。

示例 1：以下示例 Terraform 配置通过将 networking_mode 设置为 ROUTES，不启用 VPC-native 群集。

resource "google_container_cluster" "cluster_demo" {
...
  networking_mode = "ROUTES"
..
}

X-XSS-Protection 是 Microsoft 推出的 HTTP 标头，自推出以来，已被许多其他浏览器采用。该标头旨在帮助阻止 Cross-Site Scripting 攻击成功，但会无意中导致产生缺陷，使得安全的网站易受攻击[1]。由于这个原因，不应将该标头用于旧版 Internet Explorer，应将其设置为 0 以禁用。

示例 1：以下示例在 Express 应用程序中错误地配置 Helmet 中间件，从而为所有 Internet Explorer 版本启用此标头：

var express = require('express');
var app = express();
var helmet = require('helmet');

...
app.use(helmet.xssFilter({ setOnOldIE: true}));
...

MIME 探查是检查字节流内容以推断其中数据文件格式的一种做法。

如果未明确禁用 MIME 探查，则攻击者会操控部分浏览器，让其以非预期方式解析数据，从而引发 Cross-Site Scripting 攻击。对于可能包含用户可控制内容的每个页面，您应该使用 HTTP 标头 X-Content-Type-Options: nosniff。

示例 1：以下代码配置了受 Spring Security 保护的应用程序，以禁用 MIME 探查保护：

	<http auto-config="true">
        ...
        <headers>
            ...
            <content-type-options disabled="true"/>
        </headers>
	</http>

Compiler optimization 错误会在以下情况中出现：

1. 机密数据储存在内存中。

2. 内存中的机密数据通过覆盖内容的方式进行清除。



3. 源代码使用一个优化编译器进行编译，从而标识和删除那些将相关内容作为死存储进行覆盖的函数，因为在随后的操作中不会再使用这一内存。
示例 1：以下代码将从用户处读取一个密码，使用该密码连接到后端大型机，然后尝试使用 memset() 来擦除内存中的密码。

  void GetData(char *MFAddr) {
  char pwd[64];
  if (GetPasswordFromUser(pwd, sizeof(pwd))) {
   if (ConnectToMainframe(MFAddr, pwd)) {
		 // Interaction with mainframe
	 }
  }
  memset(pwd, 0, sizeof(pwd));
}

如果例子中的代码被逐字执行，那么它就可以正确地运行，但是如果代码是使用优化的编译器进行编译的，如 Microsoft Visual C++(R) .NET 或者 GCC 3.x，那么 memset() 的调用会被当作一个死存储清除，因为 pwd 缓冲区在其数值被覆盖之后便不会再次使用了 [2]。因为缓冲区 pwd 包含一个敏感值，所以如果数据长期驻留在内存中，应用程序会很容易受到攻击。如果攻击者能够访问正确的内存区域，那么他们就能使用复原后的密码来获取系统的控制权。

为了防止攻击者获取系统机密，通常的做法是覆盖内存中操作的敏感数据，如密码或者用密码编写的密钥。然而，有了优化编译器，程序就不会一直仅按照源代码指示的那样运行。在本例中，编译器将 memset() 调用解析为一段 dead code，这是因为随后的操作不会再使用被写入的内存，然而显而易见的是这样做会引发安全问题。这里的问题是，很多编译器，实际上是很多编程语言在努力提高效率的同时没有考虑这个及其他安全问题。

通常，攻击者会通过一个核心转储或运行时机制来利用这种漏洞，以便访问某个特定应用程序所使用的内存，并恢复机密信息。在攻击者访问到机密信息之后，盗取更多的系统信息就相对简单了，并有可能危及到与该应用程序交互的其他资源。

如果数组边界检查涉及计算非法指针，然后确定该指针超出边界，那么一些编译器将优化检查，假设程序员绝不会故意创建非法指针。

示例 1：

  char *buf;
  int len;
  ...
  len = 1<<30;

  if (buf+len < buf)  //wrap check
    [handle overflow]

操作 buf + len 大于 2^32，因此最终值小于 buf。但是由于指针上的运算溢出是未定义行为，一些编译器将假定 buf + len >= buf 并优化封装检查。由于该优化，后面的代码可能容易受缓冲区溢出的攻击。

Django 应用程序显示 static files 应用程序的 serve 视图，而该应用程序不应该部署在生产环境中。从 Django 文档来看：

“static files 工具主要用于帮助在生产环境中成功部署静态文件。这通常意味着需要一台独立、专用的静态文件服务器，如果在本地开发这会是很大一笔费用。因此，staticfiles 应用程序附带了一个快速更新的辅助视图，可用来在开发过程中本地提供文件。

此视图只有在 DEBUG 为 True 时才有效。

因为此视图效率非常低，而且可能不安全。此视图只用于本地开发，不能用于生产。”

一般而言，包含敏感信息或提供特权功能的应用程序资源会面临更大的被攻击风险。在勘测阶段，攻击者会试图发现此类文件和目录。如果对此类资源使用可预测的命名方案，则会使攻击者更容易找到它们。处理身份认证、管理任务或私人信息处理等敏感功能的所有应用程序资源必须予以充分保护以免被发现。

例 1：在以下示例中，admin 应用程序部署在了可预测的 URL 中：

from django.conf.urls import patterns
from django.contrib import admin

admin.autodiscover()

urlpatterns = patterns('',
    ...
    url(r'^admin/', include(admin.site.urls)),
    ...

负责存储数据的资源必须与实现应用程序功能的资源分开。在创建临时或备用资源时，程序员必须小心谨慎。

大多数 Web 应用程序使用会话标识符对用户进行唯一标识，标识符通常存储在 Cookie 中，采用透明方式在服务器与 Web 浏览器之间传输。


如果应用程序未将会话标识符存储到 Cookie 中，则有时会作为 HTTP 请求参数或 URL 的一部分进行传输。接受 URL 中指定的会话标识符有利于攻击者发动 Session Fixation 攻击。

在 URL 中放置会话标识符还可以增加针对应用程序发动 Session Hijacking 攻击的成功率。当攻击者控制受害者的活动会话或会话标识符后，就会发生 Session Hijacking 攻击。在实践中，Web 服务器、应用程序服务器和 Web 代理往往会存储请求的 URL。如果 URL 中包含会话标识符，也会予以记录。增加查看和存储会话标识符的位置数量将提高攻击者的攻击概率。

如果您正在使用 Tomcat 执行身份验证，Tomcat 部署描述符文件会指定一个用于身份验证的“Realm”。它类似于以下内容：

示例 1：

  <Realm className="org.apache.catalina.realm.JAASRealm"
         appName="SRN"
         userClassNames="com.srn.security.UserPrincipal"
         roleClassNames="com.srn.security.RolePrincipal"/>

此 Realm 标签可采用一个名为 debug 的可选属性，用来指示日志级别。此数值越大，日志消息越详细。如果此调试级别设置得过高，Tomcat 会将所有用户名和密码以明文形式写入日志文件中。Tomcat JAASRealm 的相关调试消息的临界值为 3（3 或更大表示不合适，2 或更小表示合适），但该临界值会因 Tomcat 提供的 Realm 类型不同而有所不同。

在使用 Web 框架（例如，Struts 或 Spring）构建的应用程序中直接访问 Java Server Page (JSP)，此类应用程序使用操作或 Servlet 将请求委托给 JSP，这样可能会引发未处理异常和系统信息泄漏。已使用经特殊技术处理的请求将实现或配置欠佳的应用程序服务器收编至泄露源代码详细信息，例如 http://host/page.jsp%00 或 http://host/page.js%2570。更糟糕的是，如果应用程序允许用户上传任意文件，攻击者可能会利用这项机制以 JSP 的形式上传恶意代码，并请求上传的页面在服务器上执行恶意代码。

示例 1：以下示例显示了构造欠佳的安全限制，明确允许直接访问角色名称中带有“*”的 JSP，这表示允许所有用户访问相应的 Web 资源。

<security-constraint>
    <web-resource-collection>
        <web-resource-name>JSP Access for Everyone!</web-resource-name>
        <description>Allow any user/role access to JSP</description>
        <url-pattern>*.jsp</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <role-name>*</role-name>
    </auth-constraint>
</security-constraint>

安全角色重复无任何意义，因为仅应用给定安全角色的最后一个定义。
示例 1：web.xml 文件中的条目定义了两个 admin 角色。

<security-constraint>
    <web-resource-collection>
        <web-resource-name>AdminPage</web-resource-name>
        <description>Admin only pages</description>
        <url-pattern>/auth/noaccess/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <description>Administrators only</description>
        <role-name>admin</role-name>
    </auth-constraint>
</security-constraint>
...
<security-role>
    <description>Administrator</description>
    <role-name>admin</role-name>
</security-role>

<security-role>
    <description>Non-Administrator</description>
    <role-name>admin</role-name>
</security-role>

Servlet 映射重复无任何意义，因为当在多个 Servlet 映射中使用同一 URL 模式时，只会应用最后一个条目。

示例 1：在以下示例中，在两种不同的 Servlet 映射中使用 URL 模式 /servletA/*。

<servlet-mapping>
    <servlet-name>ServletA</servlet-name>
    <url-pattern>/servletA/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
    <servlet-name>ServletB</servlet-name>
    <url-pattern>/servletA/*</url-pattern>
</servlet-mapping>