По этой ссылке в разделе замечаний упоминается, что:
TypeNameHandlingследует использовать с осторожностью, когда ваше приложение десериализует JSON из внешнего источника. Входящие типы должны проверяться с помощью настраиваемогоSerializationBinderпри десериализации со значением, отличным отTypeNameHandling.None.
В каких случаях JSON из внешнего источника будет вредным, если сериализовать/десериализовать с помощью TypeNameHandling.All? Рабочий пример был бы оценен.
При десериализации с 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
В Альваро Муньосе и в газете Александра Мироша черная бумага были обнаружены некоторые дополнительные агитационные гаджеты 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? для деталей.