ASP.NET MVC XSS输入字段剥离HTML /脚本或清理(ASP.NET MVC XSS Input Field strip HTML/Scripts or Sanitize)

我正在使用ASP.NET MVC AntiXssEncoder来防止再生表单上的INPUT字段的XSS

但是，在更新页面上，用户会看到以下内容：

Input Test <b>abc</b>

这种情况的最佳做法是什么？ 1.清理或删除所有HTML和脚本标记

谢谢。

I'm using ASP.NET MVC AntiXssEncoder to prevent XSS for INPUT fields on Regeneration Form

However, when on Update page user sees below:

Input Test <b>abc</b>

What's the best practice for this scenario? 1. Sanitize or Remove all HTML and Script Tags

Thanks.

最满意答案

当您为正在处理的应用程序建立威胁模型或构建威胁配置文件时，您将在与您进行接口连接和通信的系统（应用程序，网页）上清楚显示。您将了解您收到输入的地点，您将了解您输出的地点。你可以决定是否

您想要清理输入并将其存储在数据库中或者只是存储恶意输入（记住，即使<script>script('foo')</script>在数据库中，当它在数据库中反映出来时仍然是恶意的），然后阻止它在在浏览器或Web应用程序中显示的时间。

在数据库中将字符串输入之前应该清理输入（例如，如果用户输入字符串Alex <script>window.location='http://evil.com';</script>那么就不容易给出一个确定的答案Alex <script>window.location='http://evil.com';</script>然后你应该只存储Alex并从输入的字符串中清除恶意输入，然后将其存储在数据库中）或者不要担心输入清理，这取决于输出编码。

但最佳实践是在多个层次中实现深度安全性。理想情况下，您还应该进行输入清理和输出编码。因为您可能永远不知道如果您不进行输入清理，数据库中的恶意脚本可能会反映在您提供数据的其他应用程序中。

说完所有的故事，在你的情况下，我认为你想在输出中看到的是Input Test <b>abc</b> 你想看<b>abc</b>. 当你查看页面的响应（html源代码）时，你应该Input Test <b>abc</b> 它将在浏览器中显示为abc 。

但是，如果您看到Input Test <b>abc</b> 在浏览器中，我认为您的响应（使用fiddler捕获的视图源选项）是&lt;b&gt;abc&lt;/b&gt; 。如果是这种情况，那么你正在遇到双重编码的问题（实际上是双html输出编码）。如果你正在使用剃刀视图引擎，那么除非你做一个Html.Raw ...默认情况下，你输出的每个字符串都将使用Razor视图引擎的@语法进行编码输出。如果您使用的是aspx视图引擎，那么您在脚本块<%: %>放置的任何内容都将被输出编码。

我认为你的最佳实践问题已得到解答。如果您想了解其他任何内容（与此问题相关），请评论编辑问题。

When you threat model or build a threat profile for the application you are dealing with, it will come clear on the systems (apps, web pages) that you are interfacing and communicating with. You will get to know the places you are receiving the input from, you will get to know the places you are outputting. You can make the decision of whether

you want to sanitize the input and store it in a database or just store malicious input (remember even if <script>script('foo')</script> is in the database it is still malicious when it gets reflected on the page) in the database, and then prevent it from being executed at the time of display in the browser or web application.

It would not be very apt to give a conclusive answer that you should sanitize the input before string it in a database (such as if the user inputs the string Alex <script>window.location='http://evil.com';</script> then you should store only Alex and purge the malice input from the entered string, and then store it in the database) or do not worry about input sanitization, depend on output encoding.

But the best practice is to implement security in depth, in multiple layers. Ideally, you should be doing input sanitization and output encoding as well. Because you may never know that if you do not do input sanitization, your malicious script in the database may get reflected in some other application that you feed your data too.

Having said all that story, In your case I think what you want to see in the output is instead of Input Test <b>abc</b> you want to see <b>abc</b>. When you look at the response (html source) of the page then you should have Input Test <b>abc</b> which would be displayed in the browser as abc.

However if you see Input Test <b>abc</b> in the browser then I think your response (use the view source option of capture with fiddler) is &lt;b&gt;abc&lt;/b&gt; . If this is the case then you are running in to the problem of double encoding (actually double html output encoding). If you are using razor view engine, then unless you do a Html.Raw ... by default every string you output would be output encoded with the Razor view engine's @ syntax. If you are using aspx view engine, then anything you put inside the script block <%: %> would be output encoded.

Your question about best practice is answered in my opinion. Please comment of edit the question if you want to know anything else (related to this question).

更多推荐