Самостоятельная проблема безопасности?

Question

При использовании selfhost .Net Core 2.x все артефакты сборки статически обслуживаются по умолчанию, поскольку каталог по умолчанию находится в том же месте, что и двоичный файл / exe.

Это означает, что если кто-то знает имена DLL, они могут просто запросить их в /Whwhat.dll, или они также могут получить любые файлы конфигурации по имени, то есть appSettings.

Если вы измените положение так, чтобы корневой каталог отличался или этот каталог не был в VFS, / metadata перестает работать.

Можно ли работать с / метаданными, но не разрешать статическое обслуживание dll и т. Д. Службы?

Я пытался ограничить пути. Это будет препятствовать выполнению настроек / dlls / exes, но страница / метаданных будет полностью пустой.

Answer 1

Страница /metadata не связана со статическим каталогом файлов, возможно, вы вызвали исключение при запуске, которое повлияло на его работу.Если вы можете собрать автономный проект на GitHub, который показывает проблему, которую я могу исследовать.

Можно обслуживать только расширения в Config.AllowFileExtensions, вы можете удалить .dll из обслуживаемых с:

Config.AllowFileExtensions.Remove("dll");

.exe по умолчанию не обслуживаются, если вы можете загрузить их, вы можете загружать их с помощью статического обработчика файлов .NET Core.

Обычной практикой является использование WebRoot внекорень проекта, который для .NET Core обычно /wwwroot.

Answer 2

edit: Обновлено предложение по устранению зла.

Сначала я добавил .UseWebRoot() на строитель, затем позже переключился с шаблона ServiceStack selfhost на веб-шаблон в соответствии с предложением Mythz. Веб-шаблон был настроить таким образом, чтобы решить мою проблему.

Еще раз спасибо.