当满足以下任一条件时，就会产生 file permission manipulation 错误：

1. 攻击者能够指定在 file system 中修改权限的操作所使用的路径。

2. 攻击者能够指定 file system 上的操作所分配的权限。

示例 1：以下代码使用来自系统属性的输入来设置默认权限掩码。如果攻击者更改了系统属性，则他们可以使用该程序获得该程序所处理文件的访问权限。如果程序还容易受路径篡改攻击，那么攻击者可能会利用这一漏洞访问系统中的任意文件。

  String permissionMask = System.getProperty("defaultFileMask");
  Path filePath = userFile.toPath();
  ...
  Set<PosixFilePermission> perms = PosixFilePermissions.fromString(permissionMask);
  Files.setPosixFilePermissions(filePath, perms);
...

默认情况下，Flash 应用程序需要遵循 Same Origin Policy（同源策略），该策略可确保来自同一个域的两个 SWF 应用程序能够访问彼此的数据。Adobe Flash 允许开发人员通过编程或 crossdomain.xml 配置文件中的相应设置来更改该策略。不过，更改此设置时应小心谨慎，如果跨域策略过于宽松，恶意应用程序就能趁机采用不当方式与受害者应用程序进行通信，从而导致发生欺骗、数据被盗、转发及其他攻击。

示例 1：以下摘录的代码示例使用通配符以编程方式指定允许与应用程序通信的域。

   flash.system.Security.allowDomain("*");

将 * 作为 allowDomain() 的参数表明该应用程序的数据可供来自任何域的其他 SWF 应用程序访问。

默认情况下，Flash 应用程序需要遵循 Same Origin Policy（同源策略），该策略可确保来自同一个域的两个 SWF 应用程序能够访问彼此的数据。Adobe Flash 允许开发人员通过编程或 crossdomain.xml 配置文件中的相应设置来更改该策略。从 Flash Player 9,0,124,0 开始，Adobe 还引入了定义 Flash Player 可以跨域发送的自定义标头的功能。但是，在定义这些设置时应小心谨慎，因为当过于宽松的自定义标头策略与过于宽松的跨域策略一起应用时，将允许恶意应用程序将其选择的标头发送到目标应用程序，从而可能导致各种攻击，或导致不知道如何处理接收到的标头的应用程序在执行中出现错误。

示例 1：以下配置显示了如何使用通配符指定 Flash Player 可以跨域发送的标头。

  <cross-domain-policy>
    <allow-http-request-headers-from domain="*" headers="*"/>
  </cross-domain-policy>

使用 * 作为 headers 属性的值表明可以跨域发送任何标头。

默认情况下，Flash 应用程序需要遵循 Same Origin Policy（同源策略），该策略可确保来自同一个域的两个 SWF 应用程序能够访问彼此的数据。Adobe Flash 允许开发人员通过编程或 crossdomain.xml 配置文件中的相应设置来更改该策略。不过，在确定可更改此设置的人时应小心谨慎，如果跨域策略过于宽松，恶意应用程序就能趁机采用不当方式与受害者应用程序进行通信，从而导致发生欺骗、数据被盗、转发及其他攻击。在以下情况下会发生策略限制绕过漏洞：

1. 数据从一个不可信赖的数据源进入应用程序。

2. 数据用于加载或修改跨域策略设置。
示例 1：以下代码会将已加载的 SWF 文件中的一个参数值作为用于加载跨域策略文件的 URL。

   ...
   var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
   var url:String = String(params["url"]);
   flash.system.Security.loadPolicyFile(url);
   ...

示例 2：以下代码会使用已加载的 SWF 文件中的一个参数值来定义可信赖的域列表。

   ...
   var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
   var domain:String = String(params["domain"]);
   flash.system.Security.allowDomain(domain);
   ...

从 Flash Player 7 开始，默认情况下通过 HTTP 加载的 SWF 应用程序不允许访问通过 HTTPS 加载的 SWF 应用程序的数据。Adobe Flash 允许开发者通过编程或 crossdomain.xml 配置文件中的相应设置来更改此项限制。不过，定义这些设置时应小心谨慎，因为通过 HTTP 加载的 SWF 应用程序容易受到中间人攻击，所以不应信赖此程序。

示例：以下代码会调用 allowInsecureDomain()，它会取消相关限制，从而允许通过 HTTP 加载的 SWF 应用程序访问通过 HTTPS 加载的 SWF 应用程序中的数据。

   flash.system.Security.allowInsecureDomain("*");

Hadoop cluster control 错误在以下情况下发生：

- 数据从一个不可信赖的数据源进入程序。

- 数据被 NameNode、DataNode、JobTraker 等 Hadoop 群集核心组件用来更改群集的状态。

Hadoop 群集是一种有害环境。当用来防止对群集节点未经授权访问的安全配置设置不当时，攻击可能会乘机控制基础设施。这导致了由 Hadoop 群集提供的任何数据遭到篡改的可能性。

例 1：下列代码是典型客户端应用程序中提交的 Job，其输入来自 Hadoop 群集中主计算机的命令行：

  public static void run(String args[]) throws IOException {

    String path = "/path/to/a/file";
    DFSclient client = new DFSClient(arg[1], new Configuration());
    ClientProtocol nNode = client.getNameNode();

    /* This sets the ownership of a file pointed by the path to a user identified
     * by command line arguments.
     */
    nNode.setOwner(path, args[2], args[3]);
    ...
  }

包含来自其他网站的可执行内容是非常危险的。这就会将您站点的安全与其他站点的安全绑在一起。

示例：请考虑以下 script 标签。

  <script src="http://www.example.com/js/fancyWidget.js"></script>

如果此标签出现在 www.example.com 以外的网站中，则该站点将依赖 www.example.com 来运行正确的非恶意代码。如果攻击者可以入侵 www.example.com，则他们可以篡改 fancyWidget.js 的内容，损害站点安全。例如，他们可以将代码添加到 fancyWidget.js 中，窃取用户的机密数据。

当敏感数据（如密码或加密密钥）因为没有从内存中删除而被泄漏给攻击者时，就会发生 Heap inspection 漏洞。

realloc() 函数通常用来提高某个分配的内存块的大小。该操作经常要求将以前的内存块中的内容复制到新的且更大的内存块中。该操作会完整地保留原内存块中的内容，但不允许程序进行访问，这就使程序无法清除内存中的敏感数据。如果攻击者能够后期访问某个内存转储中的内容，敏感数据就会暴露。

示例：以下代码在一个包含敏感数据的缓冲区上调用了 realloc()：

plaintext_buffer = get_secret();
...
plaintext_buffer = realloc(plaintext_buffer, 1024);
...
scrub_memory(plaintext_buffer, 1024);

这段代码试图清除内存中敏感数据，但因为使用了 realloc()，所以在原来对 plaintext_buffer 分配的内存中仍会看到该数据的副本。

当敏感数据（如密码或加密密钥）因为没有从内存中删除而被泄漏给攻击者时，就会发生 Heap inspection 漏洞。

VirtualLock 函数旨在锁定内存中的页面，以防这些页面在磁盘上被标注页码。然而，在 Windows 95/98/ME 操作系统上，这一函数仅作为桩函数使用，因而不会产生什么影响。

程序员通常信任隐藏字段的内容，认为用户不会查看它们或操作其内容。攻击者则会推翻这些假设。他们将检查写入隐藏字段的值，更改它们，或使用攻击数据替换这些内容。

示例：

  Hidden hidden = new Hidden(element);

如果隐藏字段包含敏感信息，那么就会像捕捉该页面的其余部分一样捕捉这些信息。这会导致敏感信息在用户不知情的情况下在浏览器缓存中被隐藏起来。

默认情况下，通常会在常用浏览器中启用 X-XSS-Protection 标头。将标头值设置为 false (0) 后，禁用 Cross-Site Scripting 保护功能。

可以在多个位置设置标头，并且应检查其中是否存在配置错误和恶意篡改问题。

示例：以下代码配置了受 Spring Security 保护的应用程序，以禁用 XSS 保护功能：

	<http auto-config="true">
        ...
        <headers>
            ...
            <xss-protection xss-protection-enabled="false" />
        </headers>
	</http>

HTML5 的一项功能是在客户端 SQL 数据库存储数据。数据库名称是开始写入数据库或从数据库读取所需的重要信息。因此，数据库名称必须是每位用户特有的唯一字符串。如果数据库名称很容易被猜出，未经授权的人（例如其他用户）可能会窃取敏感数据或损坏数据库条目。
示例：以下代码使用了容易被猜出的数据库名称：

...
var db = openDatabase('mydb', '1.0', 'Test DB', 2 * 1024 * 1024);
...

该代码可以成功运行，但任何能猜到数据库名称为 'mydb' 的人都可以访问该数据库。

HTML5 提供一项新功能，可轻松实现输入表单字段验证。通过 required 属性，可指定是否必须填写某一输入表单字段。指定字段类型可确保根据输入类型对输入进行检查。甚至还可以使用自定义 pattern 属性根据正则表达式来对输入进行检查。然而，在表单标签上添加 novalidate 属性以及在提交输入标签上添加 formnovalidate 属性时，将禁用这一验证功能。

例 1：以下示例通过 novalidate 属性禁用表单验证。

      <form action="demo_form.asp" novalidate="novalidate">
        E-mail: <input type="email" name="user_email" />
        <input type="submit" />
      </form>

例 2：以下示例通过 formnovalidate 属性禁用表单验证。

      <form action="demo_form.asp" >
        E-mail: <input type="email" name="user_email" />
        <input type="submit" formnovalidate="formnovalidate"/>
      </form>

禁用 HTML 表单验证功能不利于用户使用，而且可能导致服务器容易受到各种攻击。未经校验的输入是导致各种漏洞的根源，如 cross-site scripting、process control 和 SQL injection。

由于存在 Spectre 和 Meltdown 等漏洞导致的旁路攻击，强制执行给定 Web 文档的数据隐私变得非常重要。创建跨源开放策略 (COOP) 是为了帮助防止由于旁路攻击而导致敏感信息泄露。具体来说，COOP 可以强制执行文档浏览上下文组与其他外部文档（例如弹出窗口）的隔离。

示例 1：以下代码显示了 Django 框架中不安全的 COOP 设置“unsafe-none”。由于旁路攻击，这可能允许外部文档访问源文档的浏览上下文组的私有数据。

SECURE_CROSS_ORIGIN_OPENER_POLICY = 'unsafe-none'

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

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

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

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

内容安全策略 (CSP) 是声明性安全标头，允许开发人员规定站点可从哪些域中加载内容，或呈现在 Web 浏览器中时向哪些域发起连接。它提供额外的安全层以避免重大漏洞，如 Cross-Site Scripting、Clickjacking、Cross-origin Access 等，此外还有输入验证以及代码中的允许列表检验。但配置不恰当的标头无法提供此额外的安全层。该策略是在十五条指令的帮助下定义的，包括八条控制资源访问的指令，即：script-src、img-src、object-src、style_src、font-src、media-src、frame-src、connect-src。

其中的每个指令均将一个源列表作为值，指定站点可访问的域，以使用该指令涵盖的功能。开发人员可使用通配符 * 表示所有或部分数据源。所有的指令都不是强制性的。浏览器允许对未列出的指令使用所有的数据源，或者允许从可选 default-src 指令中衍生其值。此外，此标头的规范也在不断发展。在 Firefox V23 和 IE V10 以前，它作为 X-Content-Security-Policy 实现，在 Chrome V25 以前，它作为 X-Webkit-CSP 实现。这两个名称现在均已弃用，目前使用的标准名称为 Content Security Policy。鉴于指令数、两个弃用的备用名称以及在单个标头中相同标头和重复指令多次出现的处理方式，开发人员很有可能会错误地配置此标头。

请考虑以下错误配置方案：

- 带 unsafe-inline 或 unsafe-eval 的指令背离了 CSP 的初衷。
- 设置了 script-src 指令，但未配置脚本 nonce。
- 设置了 frame-src，但未配置 sandbox。
- 此标头的多个实例允许出现在同一响应中。开发团队和安全团队可能都设置了标头，但其中一个团队可能使用了一个弃用的名称。如果不存在具有最新名称（即，Content Security Policy）的标头，则使用弃用标头也没问题，但如果存在名为 content-security-header 的策略，则应忽略弃用的标头。旧版本只能理解弃用的名称，因此，为了获得所需的支持，响应包括具有全部三个名称的相同策略非常重要。
- 如果指令在同一个标头实例中重复出现，则会忽略所有后续的重复。

例 1：以下 django-csp 配置使用 unsafe-inline 和 unsafe-eval 不安全指令来支持内联脚本和代码评估：

...
MIDDLEWARE_CLASSES = (
    ...
    'csp.middleware.CSPMiddleware',
    ...
)
...
CSP_DEFAULT_SRC = ("'self'", "'unsafe-inline'", "'unsafe-eval'", 'cdn.example.net')
...

内容安全策略 (CSP) 是声明性安全标头，允许开发人员规定站点可从哪些域中加载内容，或呈现在 Web 浏览器中时向哪些域发起连接。它提供额外的安全层以避免重大漏洞，如 Cross-Site Scripting、Clickjacking、Cross-origin Access 等，此外还有输入验证以及检查代码中的允许列表。

默认情况下，Spring Security 和其他框架不会添加内容安全策略标头。Web 应用程序作者必须声明一或多项安全策略，以针对受保护资源强制实施或监控，从而从额外的安全层获益。

允许将您的网站添加到框架会引发安全问题。例如，这可能引发 Clickjacking 漏洞或允许异常的跨框架通信。

默认情况下，Spring Security 等框架将 X-Frame-Options 标头包含在内，从而指示浏览器是否应对应用程序进行组帧。禁用或不设置此标头会引发与跨框架相关的漏洞。

示例 1：以下代码配置了受 Spring Security 保护的应用程序，以禁用 X-Frame-Options 标头：

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

内容安全策略 (CSP) 是声明性安全标头，使开发人员可以在浏览器中指定允许的安全相关行为，包括可从中检索内容的位置允许列表。它提供额外的安全层以避免重大漏洞，如 Cross-Site Scripting、Clickjacking、Cross-origin Access 等，此外还有输入验证以及检查代码中的允许列表。但配置不恰当的标头无法提供此额外的安全层。该策略是在 15 条指令的帮助下定义的，包括 8 条控制资源访问的指令：script-src、img-src、object-src、style_src、font-src、media-src、frame-src、connect-src。这 8 条指令将源列表作为值，该值指定站点可访问的域，以使用该指令涵盖的功能。开发人员可使用通配符 * 表示所有或部分数据源。其他源列表关键字（例如 'unsafe-inline' 和 'unsafe-eval'）提供了对脚本执行的更精细控制，但可能有害。所有的指令都不是强制性的。浏览器允许对未列出的指令使用所有的数据源，或者允许从可选 default-src 指令中衍生其值。此外，此标头的规范也在不断发展。在 Firefox V23 和 IE V10 以前，它作为 X-Content-Security-Policy 实现，在 Chrome V25 以前，作为 X-Webkit-CSP 实现。这两个名称现在均已弃用，目前使用的标准名称为 Content Security Policy。鉴于指令数、两个弃用的备用名称以及在单个标头中相同标头和重复指令多次出现的处理方式，开发人员很有可能会错误地配置此标头。

示例 1：以下代码设置了过度宽松且不安全的 default-src 指令：

	<http auto-config="true">
        ...
        <headers>
            ...
            <content-security-policy policy-directives="default-src '*'" />
        </headers>
    </http>

在 HTML5 以前的版本中，Web 浏览器会强制实施同源策略，以确保在使用 JavaScript 访问 Web 页面内容时，JavaScript 和 Web 页面必须来自同一个域。如果不实施同源策略，恶意网站可能就会使用客户端凭据运行从其他网站加载敏感信息的 JavaScript，并对这些信息进行提炼，然后将其返回给攻击者。如果定义了名为 Access-Control-Allow-Origin 的新 HTTP 标头，HTML5 就支持使用 JavaScript 跨域访问数据。通过此标头，Web 服务器可定义允许使用跨源请求访问服务器域的其他域。但是，定义标头时应小心谨慎，如果 CORS 策略过于宽松，恶意应用程序就能趁机采用不当方式与受害者应用程序进行通信，从而导致发生欺骗、数据被盗、转发及其他攻击。

示例 1：以下示例会使用通配符以编程方式指定允许与应用程序进行通信的域。

<websocket:handlers allowed-origins="*">
        <websocket:mapping path="/myHandler" handler="myHandler" />
</websocket:handlers>

使用 * 作为 Access-Control-Allow-Origin 标头的值，这表明任何域上运行的 JavaScript 都可以访问应用程序的数据。