Строковый параметр HTTP GET, заканчивающийся выбранными ключевыми словами, не разрешен в ядре .net.

Visual Studio: 2019 .NET Core: 2.2 Язык: C#

Проблема: я создал .NET Core API с конечной точкой GET, украшенной маршрутизацией атрибутов, которая принимает строковый параметр, и здесь я получаю ответ 404.7 для некоторых ключевых слов, например. ".master", ".cs", ".mdf" и т. д.

Неработающий код:

Путь доступа: http://baseUrl/api/test/test.master

[HttpGet("{userName}")] 
public ActionResult<string> Get(string userName) 
{ 
    return userName; 
}

Рабочий код:

Принятие имени пользователя в качестве строки запроса работает отлично. Это лучшая практика?

Путь доступа: http://baseUrl/api/test?userName=test.master

[HttpGet] 
public ActionResult<string> Get(string userName) 
{ 
    return userName; 
}

Я знаю, что это расширения файлов, к которым не разрешен доступ в качестве ресурсов. Но есть ли другой способ заставить его работать, кроме принятия параметра в качестве строки запроса. Могу ли я заставить его работать с маршрутизацией атрибутов?

Я попытался воспроизвести эту проблему и в .NET Framework, но с той же ошибкой.

Любое руководство будет оценено.


person Mahesh More    schedule 13.09.2019    source источник
comment
В вашем втором примере URL не используется строка запроса?   -  person Nkosi    schedule 13.09.2019
comment
Ознакомьтесь со следующими документами. .microsoft.com/en-us/aspnet/core/fundamentals/   -  person Nkosi    schedule 13.09.2019
comment
Если бы я видел успешные запросы на вещи, которые заканчивались на .mdf или .cs в журналах веб-сервера, я бы сходил с ума и бежал, чтобы проверить, не взломан ли он. Рабочие веб-серверы, такие как IIS, отклоняют запросы на определенные типы файлов еще до того, как они перенаправят запрос в приложение. Как и брандмауэры. Как вы размещаете свое веб-приложение и почему такие пути разрешены или ожидаемы в первую очередь?   -  person Panagiotis Kanavos    schedule 13.09.2019
comment
Как вы размещаете свое приложение? IIS определенно блокирует эти расширения. Если вы действительно хотите их разрешить (почему?), вам придется настроить сам сервер.   -  person Panagiotis Kanavos    schedule 13.09.2019
comment
@Nkosi Второй момент - принять параметр в качестве строки запроса. Я исправил свою опечатку. Спасибо за быстрый ответ.   -  person Mahesh More    schedule 14.09.2019
comment
@PanagiotisKanavos Я использую сервер IIS для размещения веб-API. На самом деле я действительно не хочу добавлять эти расширения в мои разрешенные расширения IIS, но моя конечная точка возвращает данные, принимая имя пользователя в качестве параметра, и пользователь может выбрать любое имя, какое захочет. Недавно мы обнаружили проблему в рабочей среде, из-за которой некоторые пользователи получают 404.7, и, покопавшись в ней, обнаружили, что имена этих пользователей заканчиваются этими расширениями, поэтому я пытаюсь найти решение вместо того, чтобы слепо менять конечную точку, которая работает на prod.   -  person Mahesh More    schedule 14.09.2019
comment
@MaheshMore, вы уверены, что это настоящие пользователи, а не шутники (в лучшем случае)? Кто будет использовать имя пользователя, оканчивающееся на .mdf или .cs? Если вы хотите поддерживать такие имена без ущерба для безопасности, вам придется изменить API, например, принять POST для этой операции, использовать идентификатор пользователя/токен вместо имени пользователя (в конце концов, разрешение имени подвергает вас анализу учетной записи), получить имя пользователя из заголовка и т. д.   -  person Panagiotis Kanavos    schedule 16.09.2019
comment
@MaheshMore в любом случае вы не должны разрешать http или неавторизованные/неавторизованные вызовы такого API.   -  person Panagiotis Kanavos    schedule 16.09.2019
comment
@PanagiotisKanavos Фактические имена пользователей не заканчиваются на .mdf или .cs, но есть несколько реальных пользователей, имена которых заканчиваются на .master, что вызывало проблему, а test.master является допустимым именем, потому что у этого пользователя есть некоторые права администратора, и они хотят различать Это. И да, мне не нужно делать эту конечную точку POST, поскольку я могу решить эту проблему, приняв параметр userName из строки запроса. Спасибо за вашу помощь.   -  person Mahesh More    schedule 17.09.2019