我打算制作一个网络应用程序，允许用户在我的网站上发布整个网页。我正在考虑使用HTML Purifier，但我不确定，因为HTML Purifier会编辑HTLM，并且HTML的维护方式非常重要，因为它是如何发布的。所以我正在考虑制作一些正则表达式来摆脱所有脚本标记和所有JavaScript属性，如onload，onclick等。我应该采取什么预防措施来阻止用户提交的HTML上的XSS？
前段时间我看到一个Google视频提供了一个解决方案。他们的解决方案是使用另一个网站发布javascript，因此原始网站无法访问它。但我不想为此购买新的域名。
如果您可以找到任何其他让用户发布内容的方式，即不涉及HTML的内容，请执行此操作。有许多可用于生成HTML的用户端光标记系统。
所以我想作出一些正则表达式来摆脱所有的脚本代码和所有的JavaScript属性像onload事件，的onclick等
算了。您无法以任何有用的方式使用正则表达式处理HTML。更不用说当涉及安全问题时，攻击者可能会故意向您发送格式错误的标记。
如果您可以说服您的用户输入XHTML，那么解析起来就容易多了。你仍然不能用正则表达式来实现，但是你可以把它放到一个简单的XML解析器中，并遍历结果节点树来检查每个元素和属性是否是已知的，并且删除那些不是的，然后重新-serialise。
HTML Purifier编辑HTLM，重要的是HTML保持它的发布方式。
为什么？
如果是这样他们就可以在他们的原始形式编辑它，那么答案很简单，就是净化它出要显示在浏览器的方式，不的方式在提交时间。
如果必须让用户输入自己的自由形式的HTML - 和一般我会建议反对 - 然后HTML过滤，用白名单的方式（禁止/属性，它们不知道安全的所有元素）大致如此。这是非常非常复杂的，你可能需要在发现黑客时保持它的最新状态，但是在任何你想用正则表达式来破解自己的东西之前，它都是街道。
但我不想为此购买新域名。
只要任何身份验证令牌（特别是Cookie）不能在子域之间交叉，就可以使用子域名。 （这对于饼干他们不能被默认为域参数设置为只在当前的主机名。）
你的脚本功能信任你的用户？如果不这样做不能让他们拥有了它，否则你会得到攻击脚本和iframe中的俄罗斯开发/恶意软件网站所有的地方...
确保用户内容不包含任何可能导致Javascript在您的页面上运行的内容。
您可以通过使用HTML清除功能来清除所有HTML标记（如PHP中的strip_tags）或使用其他类似工具。实际上，除了XSS之外，其实有很多原因。如果您有用户提交的内容，则需要确保它不会破坏网站布局。
我相信您可以简单地使用您当前域的子域来托管Javascript，并且您将获得与AJAX相同的安全优势。但不是饼干。
在特定情况下，过滤掉<script>标签和Javascript的行动可能会是你最好的选择。
一定要删除<样式>标签和样式属性，因为IE会在其中执行CSS表达式。 – scunliffe 2009-08-23 02:55:58
也删除任何内联事件处理程序（onclick，onmouseover，ondblclick，onmouseenter，...）所有正常事件以及任何专有的IE事件处理程序。 – scunliffe 2009-08-23 02:58:16
你能确认一个子域名可以用吗？因为如果是这样，我宁愿使用它，并允许使用Javascript，而无需访问cookie。此外，style标签和属性是我所做的事情所必需的。 – fent 2009-08-23 04:28:30
小心为这种事情自制的正则表达式
像
s/(<.*?)onClick=['"].*?['"](.*?>)/$1 $3/
一个正则表达式看起来似乎摆脱的onclick事件的，但你可以绕过它
<a onClick<a onClick="malicious()">="malicious()">
运行正则表达式就会得到类似于
<a onClick ="malicious()">
你可以通过在该字符串上重复运行正则表达式直到它不匹配来解决它，但这只是一个例子，它是简单的正则表达式消毒器。
1）使用干净简单的基于目录的URI来提供用户提要数据。 确保在动态创建URI以解决用户上传的数据，服务帐户或其他域名的任何问题时，请确保不要将信息作为参数发布到URI。这是一个非常简单的操作点，可以用来暴露服务器安全漏洞，甚至可能将代码注入到服务器上。
2）修补你的服务器。 确保您的服务器保持最新的所有服务器上运行的所有服务的最新安全修补程序。
3）采取所有可能的服务器端防止SQL注入。 如果有人可以将代码注入到您的SQL数据库中，该数据库可以从您的盒子上的服务执行，该人员将拥有您的盒子。此时，他们可以将恶意软件安装到您的网络服务器上，并将其反馈给用户或从服务器获取简单的记录数据，并将其发送给恶意方。
4）强制所有新上传到受保护的沙箱区域以测试脚本执行。 无论您如何尝试从提交的代码中删除脚本标记，都会有一种方法来绕过您的安全措施来执行脚本。浏览器是草率的，做各种他们不应该做的愚蠢的废话。在您公开发布之前，请在安全区域测试您的提交内容。
5）检查提交的代码中的信标。 这一步需要上一步并且可能会非常复杂，因为它可能发生在需要执行浏览器插件的脚本代码中，例如Action Script，但这同样允许JavaScript从用户提交的代码执行。如果用户可以提交可以将信号发送给第三方的代码，那么您的用户以及可能的服务器将完全暴露给恶意第三方的数据丢失。
我并不十分关注＃1 ...你能否提供一个可以针对URI参数进行攻击的（假设的）例子，它可以通过使用pathinfo-style（“基于目录”）的URI来阻止？ – 2009-08-23 10:55:26
让我们下面的URI：“？” http://domain.com/page.html?login=name&query=term&ordernum=1234&account=5678&dest=cart&status=vip 如果您的应用程序产生的URI用性格，那么你可能有一些反思。将所有数据保留在服务器上，并仅向用户提供他们真正需要的页面内容。 – 2009-08-23 13:36:48
是的，但我仍然没有看到这是如何比domain.com/page/login/name/query/term/ordernum/1234/account/5678/dest/cart/status/vip更容易受到攻击。问题在于URL中包含的信息量，而不是该信息是作为参数传递还是作为pathinfo传递。抛开SEO和丑陋，我不知道任何方式，domain.com/?action=login比domain.com/login/更糟 - 除非我错过了一些东西，它不是“？”那就是问题所在。 – 2009-08-23 14:49:54
在执行此操作时，人们犯的最严重的错误是验证输入上的东西。
相反，您应该验证在显示。
当确定什么是XSS而什么不是时，上下文很重要。因此，只要您在显示时通过适当的清洁功能，就可以高兴地接受任何输入。
考虑到当输入被放置在'<a href="HERE">而不是<a>here!</a>时，构成'XSS'的东西将会不同。因此，所有您需要做的事情就是确保您在任何时候编写用户数据时，都非常仔细地考虑显示它的位置，并确保它无法摆脱您正在编写用户数据的上下文至。
您应该过滤所有的HTML和白名单只标记和属性是安全且语义上有用。 WordPress很棒，我假设你会发现WordPress使用的正则表达式，如果你搜索他们的源代码。
谢谢你提出这个问题。如果每个创建Web应用程序的人都在开始之前就问过这个问题，那么Web将会更好（更安全！）。 – 2009-08-23 10:57:32