Руководство по устранению угроз для отрисовки на стороне статического сервера ASP.NET Core Blazor

Статья
11/06/2024

Примечание.

Это не последняя версия этой статьи. В текущем выпуске см . версию .NET 9 этой статьи.

Внимание

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

В текущем выпуске см . версию .NET 9 этой статьи.

В этой статье описываются вопросы безопасности, которые разработчики должны учитывать при разработке Blazor Web Appс помощью статической отрисовки на стороне сервера.

Blazor объединяет три разные модели в одном для написания интерактивных веб-приложений. Традиционная отрисовка на стороне сервера, которая является моделью запроса и ответа на основе HTTP. Интерактивная отрисовка на стороне сервера, которая является моделью отрисовки на SignalRоснове . Наконец, клиентская отрисовка, которая является моделью отрисовки на основе WebAssembly.

Все общие рекомендации по обеспечению безопасности, определенные для режимов интерактивной отрисовки, применяются к Blazor Web Apps при наличии интерактивных компонентов отрисовки в одном из поддерживаемых режимов отрисовки. В следующих разделах описываются вопросы безопасности, относящиеся к неинтерактивной отрисовке на стороне сервера, Blazor Web Appа также конкретные аспекты, которые применяются при взаимодействии режимов отрисовки друг с другом.

Общие рекомендации по отрисовке на стороне сервера

Модель отрисовки на стороне сервера (SSR) основана на традиционной модели запроса и ответа HTTP. Таким образом, существуют распространенные проблемы между SSR и HTTP-запросом и ответом. Общие вопросы безопасности и конкретные угрозы должны быть успешно устранены. Платформа предоставляет встроенные механизмы управления некоторыми из этих угроз, но другие угрозы относятся к коду приложения и должны обрабатываться приложением. Эти угрозы можно классифицировать следующим образом:

Проверка подлинности и авторизация. Приложение должно убедиться, что пользователь прошел проверку подлинности и авторизован для доступа к приложению и ресурсам, предоставляемым им. Платформа предоставляет встроенные механизмы проверки подлинности и авторизации, но приложение должно убедиться, что механизмы правильно настроены и используются. Встроенные механизмы проверки подлинности и авторизации рассматриваются в Blazor узле безопасности сервера документации и в узле ASP.NET Основной документацииIdentity, поэтому они не будут рассмотрены здесь.
Проверка и очистка входных данных: перед использованием необходимо проверить и очистить все входные данные, поступающие от клиента. В противном случае приложение может быть подвержено атакам, таким как внедрение SQL, межсайтовый скрипт, подделка межсайтовых запросов, открытый перенаправление и другие формы атак. Входные данные могут поступать из любого места запроса.
Управление сеансами. Правильное управление сеансами пользователей имеет решающее значение для обеспечения того, чтобы приложение не подвергалось атакам, таким как фиксация сеансов, перехват сеансов и другие атаки. Сведения, хранящиеся в сеансе, должны быть должным образом защищены и зашифрованы, а код приложения должен предотвратить угадывание или манипулирование сеансами злоумышленника.
Обработка ошибок и ведение журнала. Приложение должно убедиться, что ошибки правильно обрабатываются и регистрируются. В противном случае приложение может быть подвержено атакам, таким как раскрытие информации. Это может произойти, когда приложение возвращает конфиденциальную информацию в ответе или когда приложение возвращает подробные сообщения об ошибках с данными, которые можно использовать для атаки на приложение.
Защита данных: конфиденциальные данные должны быть должным образом защищены, включая логику приложения при запуске в WebAssembly, так как она может быть легко перепроектирована.
Отказ в обслуживании: приложение должно гарантировать, что он не подвергается атакам, таким как отказ в обслуживании. Это происходит, например, если приложение не защищено должным образом от атак подбора или когда действие может привести к тому, что приложение будет потреблять слишком много ресурсов.

Проверка и очистка входных данных

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

Входные данные обычно доступны приложению через процесс привязки, например с помощью атрибута или атрибута [SupplyParameterFromQuery].[SupplyParameterFromForm] Перед обработкой этих входных данных приложение должно убедиться, что данные действительны. Например, приложение должно подтвердить отсутствие ошибок привязки при сопоставлении данных формы со свойством компонента. В противном случае приложение может обрабатывать недопустимые данные.

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

Если входные данные используются для выполнения запроса базы данных, приложение должно подтвердить, что входные данные допустимы, и что оно не представляет приложения атакам на внедрение SQL. В противном случае злоумышленник может создать вредоносный запрос, который можно использовать для извлечения информации из базы данных или изменения базы данных.

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

Платформа предоставляет следующие механизмы, помогающие в проверке и очистке входных данных:

Все привязанные данные формы проверяются для базовой правильности. Если входные данные не удается проанализировать, процесс привязки сообщает об ошибке, которую приложение может обнаружить перед выполнением каких-либо действий с данными. Встроенный EditForm компонент учитывает это перед вызовом обратного OnValidSubmit вызова формы. Blazor избегает выполнения обратного вызова при наличии одной или нескольких ошибок привязки.
Платформа использует маркер защиты от межсайтовых атак. Дополнительные сведения см. в статье ASP.NET Проверка подлинности и авторизация Core Blazor и обзор ASP.NET основных Blazor форм.

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

Управление сеансом

Управление сеансами обрабатывается платформой. Платформа использует сеанс cookie для идентификации сеанса пользователя. Сеанс cookie защищен с помощью API-интерфейсов защиты основных данных ASP.NET. Сеанс cookie недоступен для кода JavaScript, запущенного в браузере, и его невозможно легко угадать или манипулировать пользователем.

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

Когда дело доходит до SSR, в большинстве случаев существует не много различий между областями и временными службами, так как время существования службы ограничено одним запросом. Существует разница в двух сценариях:

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

Обработка ошибок и ведение журнала

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

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

Ошибки, возникающие во время потоковой отрисовки после начала отправки ответа клиенту, отображаются в окончательном ответе в виде универсального сообщения об ошибке. Сведения о причине ошибки включаются только во время разработки.

защита основных данных ASP.NET

Платформа предлагает механизмы защиты конфиденциальной информации для данного сеанса пользователя и гарантирует, что встроенные компоненты используют эти механизмы для защиты конфиденциальной информации, например защиты пользователя identity при использовании cookie проверки подлинности. За пределами сценариев, обрабатываемых платформой, код разработчика отвечает за защиту других сведений, относящихся к приложению. Наиболее распространенным способом этого является использование API-интерфейсов ASP.NET Core Data Protection (DP) или любой другой формы шифрования. Как правило, приложение отвечает за:

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

Что касается DP, необходимо четко понять, где выполняется код. Для отрисовки на стороне статического сервера (статический SSR) и интерактивной отрисовки на стороне сервера (интерактивный SSR) код хранится на сервере и никогда не достигает клиента. В режиме интерактивной отрисовки WebAssembly код приложения всегда достигает клиента, что означает, что любая конфиденциальная информация, хранящуюся в коде приложения, доступна любому пользователю с доступом к приложению. Обфускация и другие аналогичные методы защиты кода не эффективны. После того как код достигнет клиента, он может быть перепроектирован для извлечения конфиденциальной информации.

Отказ в обслуживании

На уровне сервера платформа предоставляет ограничения для параметров запроса и ответа, таких как максимальный размер запроса и размер заголовка. В отношении кода Blazorприложения система сопоставления форм определяет ограничения, аналогичные тем, которые определены системой привязки модели MVC:

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

Кроме того, для формы определены ограничения, такие как максимальный размер ключа формы и размер значения, а также максимальное количество записей.

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

Этот аспект больше связан с разницей в росте между работой, выполняемой клиентом, и работой, выполняемой сервером, чем с определенным сравнением 1→N. Например, клиент может отправить рабочий элемент (вставка элементов в список), который занимает N единиц времени для выполнения, но серверу требуется N² для обработки (потому что это может делать что-то очень наивное). Это разница между N и N² , что имеет значение.

Таким образом, существует ограничение на то, сколько работ должен быть готов сделать сервер, который зависит от приложения. Этот аспект относится к рабочим нагрузкам на стороне сервера, так как ресурсы находятся на сервере, но не обязательно применяются к рабочим нагрузкам WebAssembly на клиенте в большинстве случаев.

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

Для рабочих нагрузок WebAssembly обычно мало проблем с объемом работы, выполняемой клиентом, так как клиент обычно ограничен ресурсами, доступными на клиенте. Однако существуют некоторые сценарии, когда клиент может повлиять, например, приложение отображает данные от других пользователей, и один пользователь может добавлять данные в систему, которая заставляет клиентов, отображающих данные, выполнять объем работы, которая не пропорциональна объему данных, добавленному пользователем.

Поделиться через