От клиента было обнаружено потенциально опасное значение Request.Path (&)

Question

Я понимаю, почему это происходит, но мне нужен обходной путь. Я изучил некоторые другие вопросы о StackOverflow, но ни один из них не помог. Я не хочу отключать проверку ввода по всему сайту, потому что это определенно опасно. У меня есть только одно (по крайней мере, пока) место, где мне нужно отключить проверку ввода.

Я украсил метод действия атрибутом [ValidateInput (false)], и я кодирую строки с помощью Html.Encode. Но все равно я получаю ту же ошибку. Вот мой взгляд:

<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>

Как видите, пользовательский ввод отсутствует. Но в некоторых именах категорий есть некоторые «опасные» символы ... Какие-нибудь решения?

Answer 1

Хотя ответ Дарина вполне выполним, я бы не рекомендовал использовать технику Скотта Хансельмана, чтобы шаг за шагом отключить всю эту проверку.Вы рано или поздно окажетесь в глубоком ...

Второе предложение об использовании идентификаторов вместе с фиктивными строками (которые отлично подходят для SEO и людей) - это путь, но иногда они также неосуществимы,Представьте себе URL-адрес этого запроса:

/111/Electronics/222/Computers/333/Apple

Хотя у нас были бы эти идентификаторы, на которые можно было бы положиться, а также имена категорий, дружественные человеку / SEO, это определенно нежелательно.ID + фиктивная строка возможна, когда нам нужно представить один элемент.В других случаях это не так.И поскольку вам нужно отобразить категорию и подкатегорию, это проблема.

Так что вы можете сделать?

Два возможных решения:

1. Очистить имена категорий, чтобы в них были только допустимые символы - это можно сделать, но если они не являются статичными и доступны для редактирования привилегированными пользователями, вам не повезло, потому что даже если вы их уже очистили, кто-топозже введите что-то недействительное

2. Очистите строку на ходу - Когда вы используете название категории, очищайте его, а при чтении и использовании (чтобы получить действительный идентификатор категории) вы можетеСравните предоставленное (ранее очищенное) имя категории со значением в БД, которое вы очищаете на лету, либо:

   1. сейчас при фильтрации категорий
   2. ранее при генерации имен категорий

Я бы посоветовал вам воспользоваться подходом 2.2.Расширьте таблицу БД, добавив в нее два столбца:

• Отображаемое имя категории
• Дружественное имя категории URL

Вы также можете установить уникальное ограничение для второгостолбца, так что не случится, что две из ваших категорий (даже если они будут иметь разные отображаемые имена) будут иметь одинаковые URL-адреса.

Как очистить

Первое, чтона ум приходит лишить недопустимых символов, но это очень утомительно, и вы, скорее всего, что-то упустите.Намного проще и разумнее получить действительные символы из отображаемого имени вашей категории.Я сделал то же самое при генерации фиктивных названий категорий URL.Просто возьмите то, что является действительным, и скопируйте все остальное.Обычно это работает просто отлично.Два примера таких регулярных выражений:

1. (\w{2,}) - используйте только буквы, цифры и символы подчеркивания и по крайней мере два из них (поэтому мы пропускаем a или отдельные числа и аналогичныеэто не добавляет никакого смысла и излишне удлиняет наш URL
2. ([a-zA-Z0-9]{2,}) - только буквы и цифры (также 2 +)

Получить все совпадения в отображаемом имени вашей категории и присоединитьсяих с пробелом / тире и сохраните вместе с исходным отображаемым именем. Другой мой вопрос был именно об этом.

Почему дополнительный столбец? Потому что вы можетене запускайте регулярные выражения на SQL-сервере. Если вы используете MySql, вы можете использовать один столбец и регулярное выражение для БД.

Answer 2

Даже если вы не должны делать это таким образом ... иногда нет простого способа обойти это.requestPathInvalidCharacters для тега httpRuntime в web.Config - это то, что вы ищете.Просто введите следующее враздел:

<httpRuntime requestPathInvalidCharacters="&lt;,&gt;,*,%,:,\" />

Я бы настоятельно рекомендовал заблокировать это, используя следующее:

<location path="the/path/you/need/to/lock/down">
    <system.web>
        <httpRuntime requestPathInvalidCharacters="&lt;,&gt;,*,%,:,\"/>
    </system.web>
</location>

Просто добавьте это в корневой тег .Таким образом ... вы не открываете весь свой сайт, чтобы допустить наличие амперсанда в пути ... и потенциально подвергаете весь сайт непредвиденной атаке.

Answer 3

Вы можете найти следующую запись в блоге полезной для использования специальных символов в URL.Но в целом, лучше всего заменить эти заголовки на слагы так же, как это делает StackOverflow с заголовками вопросов в URL для улучшения SEO и использовать идентификаторы для их идентификации.