По фреймворкам
Безопасность ASP.NET Core — ошибки в проде, секреты и авторизация
ASP.NET Core надёжен, но инциденты приходят из настроек: подробные ошибки, раскрытые в проде, секреты, зашитые в appsettings, и отсутствие [Authorize]. Скройте ошибки прода, загружайте секреты вне конфигурации, авторизуйте явно. Защитно, без шагов атаки.
Для: всех, кто ведёт приложение или API на ASP.NET Core. Здесь нет шагов атаки — только как сохранить работу надёжной основы, закрывая пробелы, которые открывают настройки. Полную картину смотрите на хабе безопасности по фреймворкам.
Большая тройка ловушек (открываются в настройках)
Механизмы ASP.NET Core превосходны, но эти три вещи вам защищать в настройках и коде.
① Подробные ошибки в проде
Developer Exception Page и др. раскрывают внутренности. Извлекается намеренными ошибками.
② Секреты в appsettings
Строки подключения/ключи зашиты. Утечка через случайный коммит или экспозицию.
③ Отсутствие [Authorize]
Забудьте — и до него доберётся любой. Проверки владельца тоже нет.
Также следите за небезопасной десериализацией (BinaryFormatter и др.), over-posting в model binding и незакрытыми CVE зависимостей NuGet.
Как их закрыть (3 шага)
Скройте подробные ошибки в проде
Загружайте секреты вне конфигурации
Сделайте авторизацию явной и обрежьте опасные пути ввода
[Authorize] и проверки владельца на эндпоинты (склоняйте значение по умолчанию к запрету). Ограничивайте over-posting через DTO или [Bind] и не десериализуйте недоверенные данные небезопасными форматами. Держите зависимости NuGet под мониторингом CVE + быстро закрытыми (→ что такое IDOR).Частое (опасное)
- Developer Exception Page раскрыта в проде
- секреты зашиты в
appsettings.json [Authorize]забыт, нет проверки владельца- модели принимают каждое поле (over-posting)
Правильно
- в проде скрыты подробные ошибки
- секреты из User Secrets/окружения/Key Vault
- явная авторизация (запрет по умолчанию, проверки владельца)
- DTO/[Bind] для ограничения binding
Взгляд этого сайта: даже на надёжной основе настройки и авторизация на вас
У ASP.NET Core надёжные механизмы аутентификации, авторизации и защиты данных, но настройки прода и применение авторизации вы должны выстроить верно под каждое окружение и эндпоинт. Наш сайт на другом стеке, но принцип тот же: не раскрывайте внутренности в проде, держите секреты вне конфигурации, всегда пишите авторизацию на публичных точках входа и мониторьте зависимости на CVE. Надёжная основа окупается лишь при корректных настройках и явной авторизации.
Читать дальше
- Хаб: безопасность по фреймворкам · безопасность Spring Boot (тоже enterprise, похожая форма зависимостей/авторизации)
- Секреты: держите секреты вне публичных каталогов · Практика: плейбук реагирования на уязвимости
- Глоссарий: что такое IDOR · что такое RCE
FAQ
QASP.NET Core безопасен?
ASP.NET Core — зрелая, надёжная основа с сильными механизмами аутентификации, авторизации и Data Protection. При корректном использовании он мощен, но инциденты приходят не из ядра, а из настроек. Раскрытие подробных ошибок в проде, зашивание секретов в appsettings и забытые атрибуты авторизации повторяются не столько как специфичные для фреймворка проблемы, сколько как проблемы настроек/эксплуатации.
QГде должны храниться секреты (строки подключения, ключи API)?
Правило: не зашиты в appsettings.json. В разработке используйте User Secrets; в проде загружайте из переменных окружения или облачного менеджера секретов (например, Key Vault). appsettings.json склонен попадать в репозиторий и легко утекает через публичный каталог или случайный коммит. Если что-то утекло, оперативно ротируйте строку подключения или ключ.
QКак не забыть атрибуты авторизации?
Забудьте [Authorize] на контроллере или эндпоинте — и до него сможет добраться любой без аутентификации. Склоните значение по умолчанию к «запрету» (fallback-политика, отклоняющая неаутентифицированные запросы), делайте права явными через ролевую/политиковую авторизацию и пишите проверки владельца ресурса. Не останавливайтесь на «залогинен = можно» — проверяйте и владельца объекта.