“跨站点脚本编制”攻击是一种隐私违例，可让攻击者获取合法用户的凭证，并在与特定 Web 站点交互时假冒这位用户。
这个攻击立足于下列事实：Web 站点中所包含的脚本直接将用户在 HTML 页面中的输入（通常是参数值）返回，而不预先加以清理。 如果脚本在响应页面中返回由 JavaScript 代码组成的输入，浏览器便可以执行输入中的代码。 因此，有可能形成指向站点的若干链接，且其中一个参数是由恶意的 JavaScript 代码组成。 该代码将在站点上下文中（由用户浏览器）执行，这授权它通过用户浏览器访问用户所拥有的站点 Cookie 以及站点的其他窗口。
攻击依照下列方式继续进行：攻击者诱惑合法用户单击攻击者生成的链接。 用户单击该链接时，便会生成对于 Web 站点的请求，其中的参数值含有恶意的 JavaScript 代码。 如果 Web 站点将这个参数值嵌入在响应的 HTML 页面中（这正是站点问题的本质所在），恶意代码便会在用户浏览器中运行。
脚本可能执行的操作如下：
[1] 将用户的 cookie（针对合法站点）发送给攻击者。
[2] 将可通过 DOM（URL、表单字段等）访问的信息发送给攻击者。
结果是在易受攻击的站点上，受害用户的安全和隐私受到侵害。
部分注意事项如下：
[1] 虽然受攻击的 Web 站点涉入其中，但它没有直接受害。 它被用作攻击者发送的恶意脚本的“跳板”，用来以合法身份返回受害者的浏览器。 不过，由于受害者的隐私是在特定站点的上下文中受到侵害，并且由于站点有直接责任，因此，这将视为站点的安全缺陷。
[2] 如果受害的用户所访问的站点由攻击者来维护，攻击者便可以使用 Web 站点链接来提供恶意的链接。 如果攻击者知道用户的电子邮件地址，且用户的电子邮件客户端使用浏览器来呈现 HTML 消息，恶意的链接也可以由电子邮件来提供。
[3] 用户输入在表单字段值（即 URL 参数）中最常见，但也有已知的攻击将恶意的代码嵌入路径、查询，或 HTTP Referrer 头中，甚至是嵌入 Cookie 中。
[4] AppScan 会发送许多类型的“跨站点脚本编制”攻击，其中包括只作用于特定浏览器或浏览器版本的攻击。AppScan 的“在浏览器中显示”功能使用 Internet Explorer 来显示漏洞。对于不易侵害 Internet Explorer 而易侵害其他浏览器的变体来说，“在浏览器中显示”功能无法运作，且不会出现弹出窗口。
将输入发送给很容易受到跨站点脚本编制攻击的 Web 应用程序，有两种可能的方案：
A. 在响应页面中，返回发送给 CGI 脚本的参数值，嵌入在 HTML 中。
例如：[请求]
GET /cgi-bin/script.pl?name=JSmith HTTP/1.0
[响应]
HTTP/1.1 200 OK
Server: SomeServer
Date: Sun, 01 Jan 2002 00:31:19 GMT
Content-Type: text/html
Accept-Ranges: bytes
Content-Length: 27
1 <HTML> 2 Hello JSmith 3 </HTML>
B. 在 HTML 参数值上下文中，返回发送给 CGI 脚本的参数值。
例如：[请求]
GET /cgi-bin/script.pl?name=JSmith HTTP/1.0
[响应] HTTP/1.1 200 OK Server: SomeServer Date: Sun, 01 Jan 2002 00:31:19 GMT Content-Type: text/html Accept-Ranges: bytes Content-Length: 254
1 <HTML> 2 Please fill in your zip code: 3 <FORM METHOD=GET ACTION="/cgi-bin/script.pl"> 4 <INPUT TYPE=text NAME="name" value="JSmith"> <br> 5 <INPUT TYPE=text NAME="zip" value="Enter zip code here"> <br> 6 <INPUT TYPE=submit value="Submit"> 7 </FORM> 8 </HTML>
示例 1 - 方案 A 下列请求由用户发送：
[攻击请求] GET /cgi-bin/script.pl?name=>"'><script>alert('Watchfire%20XSS%20Test%20Successful')</script> HTTP/1.0
[攻击响应方案 A] HTTP/1.1 200 OK Server: SomeServer Date: Sun, 01 Jan 2002 00:31:19 GMT Content-Type: text/html Accept-Ranges: bytes Content-Length: 83
1 <HTML> 2 Hello >"'><script>alert('Watchfire XSS Test Successful')</script> 3 </HTML>
在这种情况下，浏览器会执行 JavaScript 代码（>"'> 部分在这里不相关）。
示例 2 - 方案 B 使用与示例 1 相同的脚本和输入来引起攻击：
[攻击响应方案 B] HTTP/1.1 200 OK Server: SomeServer Date: Sun, 01 Jan 2002 00:31:19 GMT Content-Type: text/html Accept-Ranges: bytes Content-Length: 310
1 <HTML> 2 Please fill in your zip code: 3 <FORM METHOD=GET ACTION="/cgi-bin/script.pl"> 4 <INPUT TYPE=text NAME="name" value=">"'><script>alert('Watchfire XSS Test Successful')</script>"> <br> 5 <INPUT TYPE=text NAME="zip" value="Enter zip code here"> <br> 6 <INPUT TYPE=submit value="Submit"> 7 </FORM> 8 </HTML>
>"'> 前缀用来跳出参数值的上下文。 先关闭参数字字段 ( "'> )，再关闭 <INPUT> 标记 ( > )，会导致浏览器执行 JavaScript，但不会视为已当作 JavaScript 代码来解析或执行的参数值。
以下列出各种测试变体：
[1] >'><script>alert('Watchfire XSS Test Successful')</script>
[2] >"><script>alert("Watchfire XSS Test Successful")</script>
[3] </TextArea><script>alert('Watchfire XSS Test Successful')</script>
[4] >"'><img src="javascript:alert('Watchfire XSS Test Successful')">
[5] >"'><img src=javascript:alert("Watchfire XSS Test Successful")>
[6] " style="background:url(javascript:alert('Watchfire XSS Test Successful'))" OA="
[7] --><script>alert('Watchfire XSS Test Successful')</script>
[8] '+alert('Watchfire XSS Test Successful')+'
[9] "+alert('Watchfire XSS Test Successful')+"
[10] >'><%00script>alert('Watchfire XSS Test Successful')</script> (.NET 1.1 specific variant)
[11] >"><%00script>alert("Watchfire XSS Test Successful")</script> (.NET 1.1 specific variant)
[12] >+ACI-+AD4-+ADw-SCRIPT+AD4-alert(1234)+ADw-/SCRIPT+AD4-
[13] %A7%A2%BE%Bc%F3%E3%F2%E9%F0%F4%Be%E1%Ec%E5%F2%F4%A8%A7Watchfire%20XSS%20Test%20Successful%A7%A9%Bc%Af%F3%E3%F2%E9%F0%F4%Be
变体详细信息：
测试变体 [1] 和 [2]：这些都是最基本的跨站点脚本编制变体。 两个变体之间的差异是在 JavaScript 代码中对引号或单引号的使用。 部分 Web 应用程序程序员只清理用户输入中的单引号或引号，未同时清理两者。 运行这两个变体都会检测到该漏洞。
测试变体 [3]：此测试变体是专为嵌入在 <TEXTAREA> 参数中返回的用户输入而设计的。 在测试期间，试图跳出参数值（文本区域）来强制浏览器执行 JavaScript。
测试变体 [4]：部分 Web 应用程序程序员会清理用户输入中的 <SCRIPT> 标记，但忘了清理 HTML 链接中所能使用的 "javascript:" 说明符。 在这项测试期间，试图利用以 JavaScript 链接为来源 <img> 标记来嵌入恶意的 JavaScript 代码。
测试变体 [5]：这个变体非常类似于 4 号变体。它利用 HTML 实体来绕过清理用户输入中的 <、>、引号和 “javascript:”说明符的安全手段。
测试变体 [6]：这个变体使用的非标准字符最少。 它不像先前的变体，并不使用 &、>、<、# 或 ; 等字符。 假设用户输入嵌入在 HTML 表单参数值中（在 <INPUT> 标记内），恶意字符串先从参数值上下文中转义，然后继续将 STYLE 属性加到 <INPUT> 标记，使恶意的 JavaScript 代码嵌入在其中。 注意：只有在方案 B 中，或用户输入嵌入在其他 HTML 元素的属性内时，这个变体才能成功。
测试变体 [7]：某些 Web 应用程序将用户输入嵌入到 HTML 注释内。 为了测试应用程序的这个漏洞，首先是关闭 HTML 注释 ( --> )，然后嵌入恶意的 JavaScript 代码。
测试变体 [8] 和 [9]：某些 Web 应用程序将用户输入嵌入到 JavaScript 字符串字面值中，例如： <HTML> <SCRIPT LANGUAGE="JavaScript"> var str = 'Hello $user_input'; ... </SCRIPT> </HTML>
如果我们发送下列参数值：'+alert('Watchfire XSS Test Successful')+'，产生的响应页面将类似于以下内容：<HTML> <SCRIPT LANGUAGE="JavaScript"> var str = 'Hello ' + alert('Watchfire XSS Test Successful') + ''; ... </SCRIPT> </HTML>
应用程序遭受欺骗而将恶意的 JavaScript 代码并置在原始字符串字面值的中间，导致浏览器执行我们的 JavaScript 代码。 8 号和 9 号变体之间的差异是使用引号或单引号，它们用来定制这两种字符串终止字符的攻击。
测试变体 [10] 和 [11]：在 Microsoft .NET 1.1 中，HttpRequest.ValidateInput 方法会验证客户端浏览器提交的数据，如果有潜在危险数据，便抛出异常。
MSDN 提供：“如果页面伪指令或配置启用了验证功能部件，在页面的 ProcessRequest 处理阶段中，会调用这个方法。 如果未启用验证功能部件，您的代码可以调用 ValidateInput。 请求验证的运作方式是利用硬编码的潜在危险数据列表来检查所有输入数据。”
会在请求验证的过程中检查下列成员中的输入数据： - HttpRequest.Form， - HttpRequest.QueryString， - HttpRequest.Cookies
** 注意：缺省情况下，在 ASP.NET 1.1 中，会启用 HttpRequest.ValidateInput
ASP.NET 1.1 会阻止含有 '<'，且后面接着字母数字字符或惊叹号的输入（例如：<script>、<img、<!--，等等）。 如果 '<' 字符后面先接着 NULL 字节，然后才是字母数字字符，模式便不匹配，输入可以进入 Web 应用程序。 例如：[*] ASP.NET 1.1 会阻止 '<script>' 字符串 [*] ASP.NET 1.1 会接受 '<%00script>' 字符串
此外，大部分 Web 浏览器（包括 Microsoft Internet Explorer 的所有版本）的 HTML 解析器都会忽略 NULL 字节，并将 <%00script> 解析为 <script>。 将这一点与上述安全问题相结合，便可以通过 ASP.NET 1.1 HttpRequest.ValidateInput 安全机制来注入任何 HTML 标记，让其容易受到跨站点脚本编制及其他恶意 HTML 标记的攻击。
测试变体 [12]：许多输入验证功能都能正确地将 XSS 的常用字符（如尖括号 <>）过滤出或转义，但只有少数能够处理危险的 UTF-7 编码字符串。
因此，在许多情况下，当发送以 UTF-7 来编码的 XSS 攻击有效内容时，有效内容会在响应中原封不动返回。
攻击若要成功，受害者的浏览器应该将 XSS 有效内容当作 UTF-7 来处理，否则脚本不会得到执行。
如果“编码”设为“自动检测”，且 Internet Explorer 在响应主体的前 4096 个字符中找到 UTF-7 字符串，除非已强制使用另一个字符集编码，否则，它会将字符集编码自动设为 UTF-7。
这个自动编码功能部件可帮助恶意的用户开展 UTF-7 XSS 攻击。
该变体要能成功进行攻击，需要如下条件： [*] 受害者使用 Internet Explorer 客户端，且“编码”设为“自动检测”。
[*] 未在下列位置实施字符集编码（除非实施 utf-7）： [*] 响应头 ("Content-Type: text/html; charset=[encoding]")。
[*] 在响应 html 中的 <meta http-equiv="Content-Type" (...) charset=[encoding]/> 标记。
[*] 注入的文本出现在 html 文本的前 4096 个字符中。
测试变体 [13]：这个变体的用途是利用 Internet-Explorer 对含有 'us-ascii' Content-Type 的响应的处理方式（它会废弃每个字符的“最高有效位”）。
AppScan 可以更改 XSS 有效内容的各字符最高有效位，以避开标准输入清理函数。
例如：%3C 是“<”的 URL 编码说明，在这个攻击中，会转换成 %BC。 服务器端清理函数不会将它视为危险字符，因此，完全不会更改，但 Internet Explorer 会将它读成“<”，这让“跨站点脚本编制”攻击成为可能。