关于Javascript注入的问题

Question

我一直在阅读关于JavaScript注入的asp.net mvc学习网站，这让人大开眼界。

我甚至从未意识到/想过某人使用JavaScript来做一些奇怪的屁股注射攻击。

但它给我留下了一些没有答案的问题。

第一个

什么时候使用html.encode？只有当您要显示该用户或其他用户提交的信息时才使用它？

还是我用它来做任何事情。就像说我有用户提交的表单，这些信息将永远不会显示给任何用户，如果我仍然使用html.encode？

我该怎么做，因为我不知道如何把里面说和Html.TextBox（）html.encode标记。

二

会发生什么事说，我有我的网站上丰富的HTML编辑器。用户被允许使用它并使事情变得更加大胆。现在我想通过标签向用户显示信息。我不能Html.Encode它，因为所有的大胆和东西不会呈现。

然而，我不能像它那样离开它，因为什么会阻止用户添加一些JavaScript攻击？

那么我该怎么办？使用正则表达式来过滤掉所有的标签？

三

还有，你可以使用一个叫做“AntiforgeryToken”的时候，你会使用这个彼此标签？

感谢

编辑

几乎所有人都表示，使用“白名单”和“黑名单”我怎么会写这个名单，并将其与传入值（在C＃示例将是很好的）？

Answer 1

好问题！

1. 对于第一个答案，我会考虑在先前提出的问题中寻找here。正如答案所讨论的，使用HTML编码并不能完全保护您免受所有XSS攻击。为了解决这个问题，你应该考虑使用微软提供的Microsoft Web Protection Library（特别是AntiXSS）。

2. 正如已经提到的那样，使用允许标记列表是最好的做法，而将其他人剥离出来。

3. AntiforgeryToken令牌用于防止请求伪造（CSRF），因为它会为用户提供一个在发布页面时针对呈现的表单字段进行验证的cookie。我没有理由意识到这意味着你不能在你的所有表格中使用它。

Answer 2

使用HTML编码显示用户提交的任何正在显示的数据。当提交到数据库中时，您不需要使用它，否则您将得到如下所示的奇怪数据：Simon'&'Sons。真的，我没有看到使用它动态地写入页面的任何内容的危害。

使用允许标记的列表并放弃HTML编辑器的其他所有内容。正如人们所说，使用白名单。

第三个是为了防止发起攻击。你使用这个来阻止人们使用来自用户的'偷来的'cookie进行POST。因此，在接受帖子之前，您可能需要经过身份验证的cookie，但恶意用户可能会在用户访问他们的网站时接受该cookie，然后向您的网站提交声明为他们的网站。

在这里看到更多： http://haacked.com/archive/2009/04/02/anatomy-of-csrf-attack.aspx

如何使用它： http://blog.codeville.net/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/

Answer 3

始终验证对一个白名单接收到的输入。如果你使用黑名单，你可能并可能会遇到编码问题。验证输入时始终使用白名单。

不要依赖客户端验证来验证用户输入。客户端验证非常适合帮助用户输入正确的数据。但是恶意用户不会使用它并可能绕过客户端验证。客户端验证不应被视为安全修补程序。不应该使用javascript来验证输入。正如你可以看到JavaScript是很容易改变和修改任何HTML页面。另外，JavaScript可以在浏览器中禁用。因此，在你的代码背后进行额外的检查。

此外每次验证输入，而不仅仅是数据初始接受时。例如，如果您设置了一个cookie，请确保该cookie是相同的值，并且对每个请求都是正确的。恶意用户可以在会话期间随时修改和更改该值。

Answer 4

根据您的应用程序的设计考虑，可以实现各种级别的安全性。

我会去的下列基本规则：

1. 消毒所有输入，（在一个丰富的HTML编辑器，例如，<script>标签）除去已知的恶意部分。基于正则表达式的模式匹配通常用于这种消毒。

2. 删除所有不在允许值白名单中的输入。

3. 在存储到数据库中之前对任何HTML进行编码，并在检索显示时对其进行解码。

编辑：在这种情况下有关验证@Phoenix谈判，所以我想我要补充这一点。我之前曾经说过，我重申：我不反对基于脚本的验证。我只提醒人们不要明确依赖它。一种常见的设计模式是使用基于脚本的验证来验证基本标准，并在数据提交时在服务器端应用严格的验证。