TypeNameHandling осторожность в Newtonsoft Json

Question

По этой ссылке в разделе замечаний упоминается, что "TypeNameHandling should be used with caution when your application deserializes JSON from an external source. Incoming types should be validated with a custom SerializationBinder when deserializing with a value other than TypeNameHandling.None.Msgstr "В каких случаях JSON из внешнего источника будет вредным, если сериализовать / десериализовать с помощью TypeNameHandling.All? Рабочий пример был бы оценен.

Answer 1

Когда десериализовать с TypeNameHandling.All и без проверок SerializationBinder json.net попытается создать объект типа, который поставляется в виде метаданных в JSON.

public class Car
{
    public string Maker { get; set; }
    public string Model { get; set; }
}

{
   "$type": "Car",
   "Maker": "Ford",
   "Model": "Explorer"
} //create a Car and set property values

Но злоумышленник может отправить вам опасные типы, которые существуют в вашем коде или в фреймворке.

т.е. отсюда System.CodeDom.Compiler.TempFileCollection это сериализуемый класс, целью которого является сохранение списка временных файлов, полученных в результате процесса компиляции, и удаление их, когда они больше не нужны. Чтобы гарантировать удаление файлов, класс реализует финализатор, который будет вызываться при очистке объекта сборщиком мусора. Злоумышленник сможет создать сериализованную версию этого класса, которая указывает его внутреннюю коллекцию файлов на любой файл в системе жертвы. Это будет удалено в какой-то момент после десериализации без какого-либо взаимодействия с приложением десериализации.

    [Serializable]
    public class TempFileCollection
    {
       private Hashtable files;
       // Other stuff...

       ~TempFileCollection()
       {
         if (KeepFiles) {return}
         foreach (string file in files.Keys)
         {
            File.Delete(file);
         }
       }
    }

   {
       "$type": "System.CodeDom.Compiler.TempFileCollection",
       "BasePath": "%SYSTEMDRIVE",
       "KeepFiles": "False",
       "TempDir": "%SYSTEMROOT%"
    } // or something like this, I just guessing but you got the idea

Answer 2

Некоторые дополнительные атакующие гаджеты были обнаружены в газете Альваро Муньоса и Александра Мироша о черной шляпе https://www.blackhat.com/docs/us-17/thursday/us-17-Munoz-Friday-The-13th-JSON-Attacks-wp.pdf. Это:

• System.Configuration.Install.AssemblyInstaller - Вектор атаки: выполнить полезную нагрузку при сборке.

• System.Activities.Presentation.WorkflowDesigner - Вектор атаки: выполнить статический метод во время анализа полезной нагрузки Xaml.

• System.Windows.ResourceDictionary - Вектор атаки: злоумышленник отправляет полезную нагрузку с URL на контролируемый сервер, этот сервер отвечает полезной нагрузкой Xaml и ContentType = application/xaml+xml и целевой сервер будет выполнять желаемый статический метод во время анализа полезной нагрузки Xaml.

• System.Windows.Data.ObjectDataProvider - Вектор атаки: 1) вызов любого метода немаршалированного объекта; 2) Мы можем вызвать параметризованный конструктор нужного типа с контролируемыми параметрами; 3) вызывать любые общедоступные методы, в том числе статические с контролируемыми параметрами.

• System.Windows.Forms.BindingSource - Вектор атаки: произвольный вызов геттера.

• Microsoft.Exchange.Management.SystemManager.WinForms.ExchangeSettingsProvider - Вектор атаки: позволяет переходить от сеттеров к десериализации вложенного BinaryFormatter.

Однако обратите внимание, что тип гаджета атаки должен быть совместим с (назначаемым) ожидаемым типом, десериализованным для успешной атаки. Это всегда верно, когда ожидаемый тип object или же dynamic и может быть правдой в других ситуациях. Видите Внешний json уязвимым из-за Json.Net TypeNameHandling auto? для деталей.