从客户端检测到有潜在危险的Request的值（安培） [英] A potentially dangerous Request.Path value was detected from the client (&)
问题描述
我明白为什么发生这种情况，但我需要一个解决方法。我看着计算器上的其他一些问题，但他们都不是有益的。我不希望在整个网站禁用输入验证，因为这绝对是危险的。我只有一个（至少目前如此）的地方，我需要禁用输入验证。
我饰[ValidateInput（假）]属性操作方法，而且我用的编码Html.En code中的字符串。不过，我仍然得到同样的错误。这是我的看法：
＆LT; DIV ID =sharwe类别＆GT;
＆LT; UL类=菜单菜单垂直菜单手风琴＆GT;
@foreach（以型号VAR的顶层）
{
VAR topLevelName = Html.En code（topLevel.Name）;
＆LT;李班=顶层的＆GT;
＆LT; H3＆GT;
@ Html.ActionLink（topLevel.Name，索引，项，新的{类= topLevelName}，{新@class =主}）
＆LT; A HREF =＃类=下拉＆GT;＆LT; / A＆GT;
＆LT; / H3 GT＆;
＆LT; UL＆GT;
@foreach（在topLevel.Children VAR childCategory）
{
VAR childcategoryName = Html.En code（childCategory.Name）;
＆LT;李＆GT; @ Html.ActionLink（childCategory.Name，索引，项，新RouteValueDictionary {{类别，topLevelName}，{子类别，childcategoryName}}，NULL）LT; /李＆GT;
}
＆LT; / UL＆GT;
＆LT; /李＆GT;
} ＆LT; / UL＆GT;＆LT; / DIV＆GT;
正如你所看到的，没有用户输入。但一些类别名称中都有一些危险人物...任何解决方案？
虽然达林的答案是完全可行的，我不会推荐使用逐步转向这一切验证了一步斯科特Hanselman的技术。你迟早会在深结束了...
使用IDS与虚拟字符串（这是伟大的搜索引擎优化和人）沿第二个建议是很长的路要走，但有时他们是不可行无论是。想象一下，这个请求网址：
/ 111 /电子/ 222 /计算机/ 333 /苹果
虽然我们不得不这些ID，我们可以依靠和人/搜索引擎友好的类别名称为好，这肯定是不希望的。当我们需要重新present单个项目的ID +虚拟字符串是可行的。在其他情况下它不是。既然你要显示的类别和子类别，这是一个问题。
所以，你能做什么？
两种可能的解决方案：
-
清理类别名称，只具有有效的字符 - 这是可以做到的，但如果这些都不是静态的，特权用户可编辑的，你的运气在这里，因为即使你现在他们清理，有人会输入一些无效后
-
清理你的字符串在旅途 - 当您使用的类别名称，清理和阅读它，使用它时，（获得实际的类ID），你可以比较提供（previously清洗）类别名称在DB你清理在飞行值之一：
- 现在，而过滤类别
- 生成类别名称前时
我建议你把2.2的方法。扩展你的数据库表有两列：
- 类别显示名称
- 分类URL友好名称
您还可以设置在第二列的唯一约束，所以不会发生，你的两个类别（即使他们不得不不同的显示名称）将有相同的URL友好的名字。
如何清洁
所想到的第一件事情是去掉无效字符，但是这是非常繁琐的，你会最有可能留下一些东西。它更容易，更聪明，从你的类别的显示名称得到有效的字符。我已经做了相同的生成时的虚拟的URL类别名称。只要看看什么是有效的和bin休息。它通常工作得很好。这种定期的前pressions的两个例子：
-
（\\ w {2}）- 只能使用字母，数字和下划线和至少两个人（所以我们离开了的 A 或单号码和不添加任何意义和不必要的延长我们的网址 -
（[A-ZA-Z0-9] {2}）- 只有字母和数字（也2 +）
获取所有比赛在您的类别的显示名称，并用空格/破折号加入他们的行列，并沿保存与原始显示名称。矿山的不同问题正是这一点。
为什么一个附加列？因为你不能运行在SQL服务器定期EX pression。如果你使用MySQL，你可以使用一个列上DB使用常规的前pression为好。
I understand why this is happening but I need a work-around. I looked into some other questions on StackOverflow but none of them was helpful. I do not want disable input validation throughout the whole website because that is definitely dangerous. I have only one (at least for now) place where I need to disable input validation.
I decorated the Action Method with [ValidateInput(false)] attribute, and I'm encoding the strings with Html.Encode. But still, I get the same error. Here's my view:
<div id="sharwe-categories">
<ul class="menu menu-vertical menu-accordion">
@foreach(var topLevel in Model)
{
var topLevelName = Html.Encode(topLevel.Name);
<li class="topLevel">
<h3>
@Html.ActionLink(topLevel.Name, "Index", "Item", new { category = topLevelName }, new {@class = "main"} )
<a href="#" class="drop-down"></a>
</h3>
<ul>
@foreach (var childCategory in topLevel.Children)
{
var childcategoryName = Html.Encode(childCategory.Name);
<li>@Html.ActionLink(childCategory.Name, "Index", "Item", new RouteValueDictionary { { "category", topLevelName }, { "subcategory", childcategoryName } }, null)</li>
}
</ul>
</li>
}
</ul>
</div>
As you can see, there's no user input. But some of the category names have some "dangerous" characters in them... Any solutions?
Although Darin's answer is perfectly feasible, I wouldn't recommend using Scott Hanselman's technique of turning all this validation off step by step. You will sooner or later end up in deep...
Second suggestion of using IDs along with dummy strings (which are great for SEO and people) is a way to go, but sometimes they're not feasible either. Imagine this request URL:
/111/Electronics/222/Computers/333/Apple
Although we'd have these IDs we can rely on and human/SEO friendly category names as well, this is definitely not desired. ID + Dummy string is feasible when we need to represent one single item. In other cases it's not. And since you have to display category and subcategory, this is a problem.
So what can you do?
Two possible solutions:
Cleanup category names to only have valid characters - this can be done but if these are not static and editable by privileged users, you're out of luck here, because even if you've cleaned them up now, someone will enter something invalid later
Cleanup your string on the go - When you use category name, clean it up and when reading it and using it (to get the actual category ID) you can compare provided (previously cleaned) category name with value in DB that you clean up on the fly either:
- now while filtering categories
- before when generating category names
I'd suggest you take the 2.2 approach. Extend your DB table to have two columns:
- Category display name
- Category URL friendly name
you can also set a unique constraint on the second column, so it won't happen that two of your categories (even though they'd have different display names) would have same URL friendly names.
How to clean
The first thing that comes to mind is to strip out invalid characters, but that's very tedious and you'll most probably leave something out. It's much easier and wiser to get valid characters from your category display name. I've done the same when generating dummy URL category names. Just take out what is valid and bin the rest. It usually works just fine. Two examples of such regular expressions:
(\w{2,})- only use letters, digits and underscores and at least two of them (so we leave out a or single numbers and similar that doesn't add any meaning and unnecessarily lengthens our URL([a-zA-Z0-9]{2,})- only letters and digits (also 2+)
Get all matches in your category display name and join them with a space/dash and save along with original display name. A different question of mine was exactly about this.
Why an additional column? Because you can't run regular expression in SQL server. If you're using MySql you can use one column and use regular expression on DB as well.
这篇关于从客户端检测到有潜在危险的Request的值（安培）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
