我认为“跨站点”这个名称令人困惑。很容易听到它并认为它涉及一个网站上的代码攻击另一个网站上的代码。事实并非如此。更不用说它不幸的“真正”首字母缩写了。
它仅仅意味着：**在页面上执行任意 JavaScript 代码。**
这可能是插入 URL 中的 JavaScript 代码，也可能是通过表单提交的代码。如果这两种接受信息的方式在再次输出到页面上之前没有“清理”它获取的信息，那么任意 JavaScript 代码就可以在该页面上运行，这就是 XSS 漏洞。
如果 JavaScript 代码可以在页面上运行，那么它就可以访问 Cookie。
如果它可以访问 Cookie，那么它就可以访问活动会话。
如果它可以访问活动会话，它就可以以您的身份登录您已登录的网站，至少可以更改密码或造成其他破坏。
赛门铁克表示，80% 的互联网漏洞是由于 XSS 造成的。
XSS 与 SQL 注入不同，但精神相似。SQL 注入是指 SQL 命令未从输入中清除，因此能够对数据库执行恶意操作。使用 HTTPS 无法解决 XSS 或 SQL 注入问题。HTTPS 仅保护网络上传输的数据。
我不是安全专家，我只是在帮助传播信息：让我们擦除这些人们的输入！这是一个开始。
如果您有更多内容要添加，或者认为我完全错了，请告诉我！
这里有 XSS 攻击的描述和示例
非常感谢将这些内容提炼出来！我确实发现这个术语令人困惑，并且陷入了认为 XSS 是一种恶意站点向另一个站点发送数据或类似东西的阵营。
耶，我学到了一些东西！ :)
这 对我来说是一个很好的入门介绍
非常有益，感谢 Chris！
这正是我使用 PHP 框架而不是自己创建（辛苦！:|）的原因。它们提供额外的安全性来清理数据，以防止 XSS 和 SQL 注入攻击。
您仍然需要注意选择哪个框架 - 仅仅因为它已发布（甚至已购买）并不意味着它是安全的。
我不是 PHP 开发人员，我对这句话很感兴趣。当然，这取决于方法的创建方式以及 HTML 输入/隐藏值/查询字符串如何由开发人员处理，而不是 PHP 框架本身？
最终，开发人员的代码将“决定成败”，是的。
但是框架也是由某人开发的。有些是由真正了解他们在做什么的人设计的，有些则是由自以为了解的人编写的。
许多使用它们的人对安全问题知之甚少，或者无法真正检查代码，以自行确定框架的“万无一失”程度。我的意思是，您不能仅仅因为某些东西可供下载并且似乎可以满足您的需求，就假设它可以使用。
@Traq：是的，我完全同意你的观点。从我的评论来看，我并不是说应该盲目相信现有的 PHP 框架。我的意思是，以我目前的经验水平，最好使用框架，因为它会为我提供“更好”的安全性，而不是从头开始。
@Philp：这一切都归结于方法以及您操作对象的方式。但是 PHP 框架提供了预构建的方法来帮助您清理输入。如果您从头开始，您必须编写所有这些内容，并且还必须拥有关于 Web 安全性的丰富知识才能开始。但正如 Traq 所说，人们不应盲目信任框架，而应学习 Web 安全性。 :)
我也认为，如果一个人从头开始，在一个个人项目上，那么一个人可以在整个过程中学到很多东西。
简单的字符串替换远不够好，很容易绕过。我最喜欢的输入清理器是 htmlpurifier：http://htmlpurifier.org/ 人们可能会尝试的各种事情的一个很好的参考是 http://ha.ckers.org/xss.html
感谢 Chris。那真是一个很好的提醒！
你好，
您在很大程度上抓住了要点，在非安全网站上看到这类内容真是太好了。
但是，正如您所提到的，XSS 是一种在站点上嵌入任何代码的方式。它可能是任何代码才能被归类为 XSS。它可能像将背景更改为原始所有者不一定希望的内容一样无害，也可能像任何其他内容一样。许多 XSS 代码用于在广告上创建虚假点击、重定向，甚至“恶意”搜索引擎优化 (SEO)。
您文章的第二部分实际上是一种特定类型的 XSS，称为跨站点请求伪造 (CSRF)，这也是一个愚蠢的名称，它基本上只是使用注入的 Javascript（或在极少数情况下使用其他恶意方法）来窃取 Cookie 并劫持会话。
基本上，不允许第三方在您的页面上放置代码可以阻止第一次攻击并限制第二次攻击。
嗨，Allen，CSRF 与 XSS 并没有直接关系。即使您没有 XSS 漏洞，您仍然可能容易受到 CSRF 的攻击。它也不需要 JavaScript。如果漏洞通过 HTTP GET 公开，则简单的图像/css/iframe 请求（或一系列请求）可以利用它。
CSRF 基本上利用了用户很有可能已经通过目标站点授权，并在用户不知情的情况下在该站点上执行操作的可能性。我认为 Twitter 最近受到此问题的困扰（谷歌：csrf twitter goats）。
——
关于 XSS，您应该理想地验证您的输入（但不要“清理” - 无效输入根本不应该被接受）。相反，每当输出数据（用户生成的数据或其他数据）时，都应对其进行转义。
我不喜欢清理输入，因为这会扭曲数据，此外，一个支持自由文本输入的完善系统应该能够支持任何输入。
@Lee…
这实际上是我的观点。这篇文章（非常棒）错误地将两者混为一谈。它们通常是相辅相成的，但正如您提到的，CSRF 可以完全无需 Javascript 或 XSS 即可实现。
转义是一种防御措施，但您必须确保在以后的某个阶段输入不会“取消转义”。
非常感谢您介绍安全性的这一方面！WordPress 中的 AJAX 请求怎么样？我的意思是，来自前端的请求？我最近开发了一个精简的插件，用户可以使用 AJAX 方法将商品添加到购物车以写入会话。有人了解这些安全问题吗？
我想您可以使用某种“令牌”（就像在表单提交中一样）来验证 AJAX 请求是否来自有效的（且当前的）会话。
我不了解 WP 的具体情况，但我现在正在开发一个网站，它将使用大量 AJAX 来访问 PHP 函数调用，因此这是一个我需要解决的问题。
几个月前，我做了一些关于修复 SQL 和 XSS 注入的研究，并找到了这个使用 .htaccess 的简单方法
我认为它有效，是吗？
我建议阅读以下文章并查看开放 Web 应用程序安全项目网站。
http://owasp.blogspot.com/2010/11/preventing-xss-with-content-security.html
:)
很好的解释，并且始终尽可能清理代码，尤其是在它会增强网站安全性时。LT
XSS 也是 HTML5 的一部分吗？
它仍然是一个风险，是的。
最终，风险主要来自用户（编码人员）而不是语言（代码）本身。制作“有效”的东西相当容易，但确保它不被滥用则更加困难。有时人们会忘记第二部分
感谢您的帖子，但是 Web 设计师真的需要学习这个吗？假设他们不懂 PHP？
（附注 - 我是一名正在学习设计的 PHP 开发人员，所以我在此）
不错的帖子。Web 设计师在设计 Web 应用程序时应该考虑这一点。
学习 SQL 注入及示例。