двойная escape-последовательность внутри url-адреса: модуль фильтрации запросов настроен на отклонение запроса, содержащего двойную escape-последовательность

на моем ASP.NET приложение MVC, я пытаюсь реализовать URL-адрес, как показано ниже:




/ product / tags / for + families




когда я пытаюсь запустить приложение с конфигурациями по умолчанию, я получаю это сообщение с кодом ответа 404.11:




ошибка HTTP 404.11-не найдено



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




Я могу обойти эту ошибку, реализовав приведенный ниже код внутри моей сети.config:



  <system.webServer>

    <security>

      <requestFiltering allowDoubleEscaping="true" />

    </security>

  </system.webServer>


Итак, теперь я не получаю никаких 404.11.



мне интересно, какие дыры в безопасности я открываю с помощью этой реализации.



кстати, мое приложение находится под .Net Framework 4.0 и под управлением IIS 7.5.

773   2  

2 ответов:

дыры в безопасности, которые вы можете открыть, связаны с инъекцией кода - инъекцией HTML, инъекцией JavaScript или инъекцией SQL.

настройки по умолчанию защищают вас от атак полуфабрикатами, эффективно, не допуская распространенных стратегий впрыскивания для работы. Чем больше безопасности по умолчанию вы удаляете, тем больше вам нужно думать о том, что вы делаете с входными данными, предоставляемыми через URL-адреса, получить запрос querystrings, данные запроса POST, заголовки HTTP и так далее...

например, если вы создаете динамические SQL-запросы на основе id параметр вашего метода действий, например:

public ActionResult Tags(string id)
{
    var sql = "SELECT * FROM Tags Where tagName = '" + id + "'";
    // DO STUFF...
}

(...а это не хорошая идея), защита по умолчанию, поставленная на место .NET framework, может остановить некоторые из более опасных сценариев, таких как пользователь, запрашивающий этот URL:

/product/tags/1%27;drop%20table%20Tags;%20--

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

Я предполагаю, что вы не строите SQL запросы таким образом. Но более подлый материал приходит, когда вы храните пользовательский ввод в своей базе данных, а затем отображаете их. Злонамеренный пользователь может хранить JavaScript или HTML в вашей базе данных, которые выходят некодированными, что, в свою очередь, угрожает другим пользователям вашей системы.

47  
2018-09-11 17:59:24

поэтому я столкнулся с этим, когда я вызывал API из приложения MVC. Вместо того чтобы открыть дыру в системе безопасности, я изменил свой путь.

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

хотя это более старый пост, я подумал, что поделюсь, как вы можете решить эту ошибку, если вы получаете это от вызова API используя HttpUtility.UrlPathEncode метод

0  
2018-08-09 21:50:20

Comments

    Ничего не найдено.
Click here to cancel reply.