处理与降价（下页）

我打赌我使用错误的东西在这里...处理与降价（下页）

我MVC3应用程序使用Pagedown提供一个javascript文本编辑器，降价转换器，并且实时预览代码块。我使用它的“santizer”对象去除潜在的危险代码，正如指令中所建议的那样 - 您可以在demo的工作中看到它。

的JavaScript代码如下所示：

(function() { 
    var converter1 = Markdown.getSanitizingConverter(); 
    var editor1 = new Markdown.Editor(converter1); 
    editor1.run(); 
})();

此代码转换的明显textarea标签到编辑器，并使用santizing转换剥离坏的东西。在某些方面，它似乎在起作用。示例：

marquee标签在演示中它被正确地剥离。
<p style="font-size:40em;">Super Big Text</p>被剥离到Super Big Text

但有些事情是不正确的......当我插入一个假的JavaScript像这样：

TEXT `<script type="text/javascript">alert("gotcha!");</script>` MORE TEXT

和发布形式，它炸弹了一个黄色屏幕死亡：

Request Validation has detected a potentially dangerous client input value, and processing of the request has been aborted.

这是字符串不是已经安全等编码&lgt;script ...等等？

问：我缺少什么，以确保使它们可以发布到服务器作为安全的字符串代码块和内联代码是否正确转化？

来源

2012-01-30 one.beat.consumer

我错过了什么以确保代码块和内联代码被正确转换，以便它们可以作为安全字符串发布到服务器？

什么都没有。或者至少可能没有什么，假设你正在创建带有正确输出转义的textarea，如果使用例如Web窗体或MVC控件，则会出现这种情况。

对于任何和所有看起来像元素标记的输入内容，，不管是否应用程序处理输出转义正确或易受攻击，YSOD都会显示。这并不代表XSS问题，它始终在发生。

如果您希望允许包含类似元素标记的数据的用户输入（并且没有任何内在危险 - 您只需要使输出正确转义），请关闭请求验证。它完全是假的作为一个真正的安全功能，只有真正给你一个错误的安全感;微软推动它是令人失望的，因为它揭示了HTML注入的一个致命的误解。

不幸的是，禁用它会让ASP.NET 4变得更加恼人。您必须使用<httpRuntime requestValidationMode="2.0" />重置旧模型，然后将ValidateRequest="false"添加到页面。

来源

2012-01-31 10:38:23 bobince

谢谢。几个问题。如何确保在使用@ Html.TextAreaFor（）助手时我的文本能够正确转义？其次，您是否有任何文档/参考资料可以阅读有关请求验证的虚假内容？它表现得相当稳固，但我很乐意学习内脏，也许会推出我自己的内脏。除非绝对必要，否则不想关闭它。 – 2012-02-01 01:02:46

默认情况下，MVC HTML助手都会转义它们的属性，虽然是的，但这并没有出色的文档记录（并且在开发过程中并不总是这种情况！）。如果您使用的是ASPX并且希望确定，那么使用自动转义的<％：'输出语法来编写HTML助手以及一般转义文本是安全的。帮助器输出不会被双重转义，因为它被包装成一个'HtmlString'，这会缩短额外的转义步骤。在剃刀中，@输出表现相同。 – bobince 2012-02-01 16:29:12

至于在ASP.NET的RV上特别提到的参考资料，我很难找到不仅仅是我咆哮的Google结果。 ;-) OWASP的[XSS备忘单]（https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet）概述了理解的背景，具体参见“然而，输入验证不是一个很好的注射攻击解决方案......“的解释。 – bobince 2012-02-01 16:33:36

处理与降价（下页）

回答

相关问题