Недавно, когда мы запустили проверку безопасности в нашем приложении, мы обнаружили несколько серьезных дефектов, связанных с десериализацией, когда пользователь вводил уязвимую полезную нагрузку.Наше приложение разработано в стандартных ASP.NET и .Net framework 4.5 - мы не используем какие-либо преобразователи типов, созданные нами для сериализации или десериализации, и мы не храним никаких пользовательских / сложных объектов через нашу собственную логику приложения в viewstate. У нас естьтолько типы объектов, которые поддерживаются losformatter, когда дело доходит до viewstate.Приложение размещено на одном сервере и не является хостингом веб-фермы.
Проблема десериализации, о которой сообщает средство безопасности, перечисленное ниже.
Ответ HTTP указывает, что приложение может десериализовать данные с использованием ObjectStateFormatter библиотека / API.Злоумышленник может предоставить приложению произвольные сериализованные объекты, которые при десериализации без надлежащей предварительной проверки могут привести к выполнению произвольного кода.Подумайте о том, чтобы выполнить активное сканирование или атаку вторжений с использованием средства анализа полезных данных Freddy для сериализованных данных в данном запросе, чтобы проверить, уязвимо ли приложение для RCE.Обратите внимание, что LosFormatter использует ObjectStateFormatter под капотом, и этот модуль поддерживает использование обоих API десериализации.
Ответ на запрос внедренной полезной нагрузки заканчивается 500 внутренним сервером, недопустимое исключение состояния просмотра и трассировка ниже стека была выделена из ответа об ошибке ошибки(пропущен полный ответ для выделения только основной точки).
invalid view state exception
System.Web.UI.ViewStateException.ThrowError(Exception inner, String persistedState, String errorPageMessage, Boolean macValidationError) +118
System.Web.UI.ObjectStateFormatter.Deserialize(String inputString, Purpose purpose) +525
System.Web.UI.ObjectStateFormatter.System.Web.UI.IStateFormatter2.Deserialize(String serializedState, Purpose purpose) +13
System.Web.UI.Util.DeserializeWithAssert(IStateFormatter2 formatter, String serializedState, Purpose purpose) +40
System.Web.UI.HiddenFieldPageStatePersister.Load() +222
System.Web.UI.Page.LoadPageStateFromPersistenceMedium() +224
У нас уже была логика для проверки неверных данных или состояния несанкционированного просмотра.
- Принимать только доверенные данные -(комбинация белого списка и проверок длины для каждого поля).
- Проверка ключа компьютера генерируется, и она является статической для одного сайта.Состояние просмотра всегда зашифровано, а тег config страниц в system.web файла web.config выглядит ниже.
страниц enableViewState = "true" enableViewStateMac = "true" validateRequest = "true"viewStateEncryptionMode = "Always"
Являются ли вышеуказанные 2 пункта хорошими для снижения этого риска?Пожалуйста, сообщите.
Можем ли мы решить эту проблему, поскольку LOSformatter проверяет подпись с помощью проверки MAC, а ObjectStateformatter выполняет задачи подписи, шифрования и проверки.Предполагая, что если хакер не заполнил сведения о MAC (ключ проверки, ключ дешифрования, алгоритм проверки и дешифрования, используемые в теге machinekey), он не может подготовить успешную полезную нагрузку для внедрения уязвимых команд для выполнения в операционной системе хоста приложения.
Пожалуйстадайте мне знать, если есть какой-либо способ проверить состояние представления перед его десериализацией в .net framework и устранить какие-либо уязвимые данные по некоторому шаблону?Пожалуйста, сообщите.