当应用程序出现以下情况时，将出现 cross-frame scripting 漏洞：

1. 允许自身包含在 iframe 内。
2. 未能通过 X-Frame-Options 标头指定组帧策略。
3. 使用不力保护，如基于 JavaScript 的 frame busting 逻辑。

跨框架脚本漏洞经常为 clickjacking 攻击奠定基础，攻击者可利用其执行跨站请求伪造或钓鱼攻击。

HTML5 提供 localStorage 和 sessionStorage 映射，以支持开发人员保留程序值。sessionStorage 映射仅在页面实例和即时浏览器会话期间为调用页面提供存储。但是，localStorage 映射会提供可供多个页面实例和浏览器实例访问的存储。此功能允许应用程序在多个浏览器选项卡或窗口中保留和使用同一信息。

例如，开发人员可能希望在旅游应用程序中使用多个浏览器选项卡或实例，以支持用户打开多个选项卡来比较住宿选择，同时保留用户最初的搜索条件。在传统的 HTTP 存储方法中，用户会面临在一个选项卡中执行的购买和决策（并存储在会话或 cookies 中）与另一个选项卡中的购买相干扰的风险。

借助跨多个浏览器选项卡使用用户值的功能，开发人员必须多加小心，以免将敏感信息从 sessionStorage 范围移至 localStorage，反之亦然。

示例 1：以下示例将信用卡 CCV 信息存储在会话中，表明用户已授权该站点收取文件中卡的购买费用。对于在浏览器选项卡环境中的每个购买尝试，都需要信用卡许可。为避免重新输入 CCV，该信息存储在 sessionStorage 对象中。但是，开发人员还将该信息存储在 localStorage 对象中。

...
try {
    sessionStorage.setItem("userCCV", currentCCV);
} catch (e) {
    if (e == QUOTA_EXCEEDED_ERR) {
        alert('Quota exceeded.');
    }
}

...
...

var retrieveObject = sessionStorage.getItem("userCCV");
try {
    localStorage.setItem("userCCV",retrieveObject);
} catch (e) {
    if (e == QUOTA_EXCEEDED_ERR) {
        alert('Quota exceeded.');
    }
    ...

    var userCCV = localStorage.getItem("userCCV");
    ...
}
...

通过将信息放回 localStorage 对象中，此 CCV 信息在其他浏览器选项卡和新调用的浏览器中可用。这样可以绕开预期工作流的应用程序逻辑。

Cross-Site Request Forgery (CSRF) 漏洞会在以下情况下发生：
1.Web 应用程序使用会话 Cookie。
2.应用程序未验证请求是否经过用户同意便处理 HTTP 请求。

示例 1：在下列示例中，Web 应用程序允许管理员创建新帐户：

  RequestBuilder rb = new RequestBuilder(RequestBuilder.POST, "/new_user");
  body = addToPost(body, new_username);
  body = addToPost(body, new_passwd);
  rb.sendRequest(body, new NewAccountCallback(callback));

攻击者可以设置一个包含以下代码的恶意网站。

  RequestBuilder rb = new RequestBuilder(RequestBuilder.POST, "http://www.example.com/new_user");
  body = addToPost(body, "attacker";
  body = addToPost(body, "haha");
  rb.sendRequest(body, new NewAccountCallback(callback));

如果 example.com 的管理员在网站上具有活动会话时访问了恶意页面，则他们会在毫不知情的情况下为攻击者创建一个帐户。这就是 CSRF 攻击。正是由于该应用程序无法确定请求的来源，才有可能受到 CSRF 攻击。任何请求都有可能是用户选定的合法操作，也有可能是攻击者设置的伪操作。攻击者无法查看伪请求生成的网页，因此，这种攻击技术仅适用于篡改应用程序状态的请求。

如果应用程序通过 URL 传递会话标识符（而不是 Cookie），则不会出现 CSRF 问题，因为攻击者无法访问会话标识符，也无法在伪请求中包含会话标识符。

部分框架会自动将 CSRF nonce 包含在其中，以保护应用程序的安全。禁用此功能会将应用程序置于风险之中。

示例 2：受此 Spring Security 保护的应用程序明确禁用 CSRF 保护功能。

	<http auto-config="true">
        ...
        <csrf disabled="true"/>
	</http>

当站点需要能够为用户提供下载时，打开下载文件的选项意味着，所提供的在浏览器中运行的任何文件均可以在与站点位于相同安全上下文的当前浏览器中打开。
如果攻击者能够操纵下载的文件，则他们可以插入在浏览器中运行的 HTML 或脚本作为跨站脚本攻击，从而窃取或操纵当前会话中的信息。

示例 1：以下示例明确禁用了对运行于浏览器中的提供的下载的保护：

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

app.use(helmet({
    ieNoOpen: false
}));
...

当用户受诱使访问恶意站点时，该站点将与合法的后端站点建立 WebSocket 连接，这时将发生跨站 WebSocket 劫持。用于请求服务器更新到 WebSocket 协议的初始 HTTP 请求是一个常规 HTTP 请求，因此浏览器将发送任何绑定到目标域的 cookie，包括任何会话 cookie。如果服务器无法验证 Origin 头文件，它将允许任何恶意站点模拟用户并在用户不知情的情况下建立双向 WebSocket 连接。

应用程序使用 exclude 拒绝列表。这很难维护，而且容易出错。如果开发人员向表单或备份表单的 Model 添加新字段，并忘记了更新 exclude 筛选器，则可能会向攻击者暴露敏感字段。攻击者将能够向任何未排除的字段提交和恶意绑定数据。

示例 1：以下表单显示了一些 User 属性，但对以下用户 id 检验了拒绝列表：

from myapp.models import User
...
class UserForm(ModelForm):
  class Meta:
    model = User
    exclude = ['id']
...

如果使用新的 role 属性更新了 User 模型，但未更新相关联的 UserForm，则 role 属性将显示在表单中。

当满足以下条件时会发生 File Based Cross Zone Scripting 漏洞：

1. 加载一个文件，这可能会允许在您的应用程序中运行脚本

2. 加载的脚本采用与运行的应用程序一样的来源。

当满足这两个条件时，可以实现一系列攻击，尤其是当其他各方根据信息是否来自您的应用程序范围内来确定信任时。

例 1：以下代码使用 Android WebView 以便在本地加载文件：

...
myWebView.loadUrl("file:///android_asset/www/index.html");
...

在Example 1 中，Android WebView 呈现器会将使用 loadUrl() 通过以“file://”开头的 URL 加载的所有内容视为来源相同。

当从文件进行加载时，攻击者可以通过几种典型方法来利用 File Based Cross-Zone Scripting 漏洞：
- 本地文件可能受可将脚本注入该文件的攻击者操纵。
这将取决于文件权限、文件所在位置，或者文件先保存再加载的竞争条件（可能有供进行修改的时间段）。

- 文件可能会调出到外部资源。
当加载的文件从外部资源检索脚本时，可能会发生这种情况。

例 2：以下代码查看外部数据源，以确定它应该运行的 JavaScript。

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

在Example 2 中，使用了不安全的协议，这可能会允许恶意操作者修改所生成的脚本。或者，可能会执行其他攻击，以将计算机重新路由到攻击者的站点。

- 加载的文件可能包含 cross-site scripting 漏洞。
如果所加载的文件能够注入代码，则注入的代码也许能够在您的应用程序上下文中运行。这不一定是注入 JavaScript 的能力，而仅仅能够注入 HTML 也可以实现涂改或拒绝服务攻击。

默认情况下，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 应用程序容易受到中间人攻击，所以不应信赖此程序。

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

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

一种常见的开发实践是添加专用于调试或测试目的的“后门”代码，这些代码不会随应用程序一起发布或部署。当这种类型的调试代码意外地留在应用程序中时，应用程序将暴露于意外的交互模式下。这些后门入口点会产生安全风险，因为在设计或测试期间未考虑这些入口点，且它们不在应用程序的预期操作条件内。

GraphiQL 是一种浏览器内工具，它利用 GraphQL 架构自检机制为 GraphQL API 开发和测试提供图形界面。GraphiQL 帮助用户探索 GraphQL 架构以及编写和执行 GraphQL 查询。

不建议允许在生产环境中访问 GraphiQL，因为通过 GraphiQL 启用 GraphQL 架构的自检可能会给您的整体安全状况带来风险。攻击者可以利用 GraphiQL 和自检从 GraphQL 架构中获取实现详细信息，从而执行更有针对性的攻击。GraphQL 架构可能会泄漏信息，例如内部使用的字段、描述和弃用说明，这些信息可能不适合公开使用。

示例 1：以下代码将初始化默认启用了 GraphiQL 的 GraphQL.js 端点：

app.use('/graphql', graphqlHTTP({
    schema
}));

GraphQL 自检功能使任何人都可以查询 GraphQL 服务器，以获取有关当前架构的信息。相关方可以发出 GraphQL 自检查询，以检索架构的可用操作、数据类型、字段和文档等全面信息。

GraphQL 自检在开发和共享有关 GraphQL API 的信息方面可发挥重大作用。自检是 GraphQL 的一项强大功能，可以促进与各种工具的集成。例如，IDE 可以利用架构自检来提供用于开发和测试 GraphQL API 的增强功能。

但是，允许任何人在生产环境中查询 GraphQL 架构可能会给您的整体安全状况带来风险。攻击者可以利用自检从 GraphQL 架构中获取实现详细信息，从而执行更有针对性的攻击。GraphQL 架构可能会泄漏信息，例如内部使用的字段、描述和弃用说明，这些信息可能不适合公开使用。

示例 1：以下代码将初始化默认启用了架构自检的 Hot Chocolate GraphQL 端点：

    services
        .AddGraphQLServer()
        .AddQueryType<Query>()
        .AddMutationType<Mutation>();
    

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

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

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

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

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

示例 1：

  Hidden hidden = new Hidden(element);

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

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

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

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

内容安全策略 (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 = (
    ...
    '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>