Impact
LiteDB use a special field in JSON documents to cast diferent types from BsonDocument
do POCO classes. When instance of an object are not the same of class, BsonMapper
use a special field _type
string info with full class name with assembly to be loaded and fit in your model.
If your end-user can send to your app a plain JSON string, deserialization can load an unsafe object to fit in your model.
Patches
Version >= 5.0.13 add some basic fixes to avoid this, but is not 100% guaranteed when using Object
type
Next major version will contains a allow-list to select what king of Assembly can be loaded
Workarounds
- Avoid users send to your app a JSON string to be direct insert/update into database
- Avoid use classes with
Object
type - try use an interface when possible
If your app send a plain JSON string to be insert/update into database, prefer this:
// Bad
public class Customer {
public int Id { get; set; }
public string Name { get; set; }
public Object AnyData { get; set; } // <= Avoid use `Object` base type
}
// Good
public class Customer {
public int Id { get; set; }
public string Name { get; set; }
public IDictionary<string, string> AnyData { get; set; } // Will accept only key/value strings
}
References
See this workaround fix on this commit:
litedb-org/LiteDB@4382ff4
References
Impact
LiteDB use a special field in JSON documents to cast diferent types from
BsonDocument
do POCO classes. When instance of an object are not the same of class,BsonMapper
use a special field_type
string info with full class name with assembly to be loaded and fit in your model.If your end-user can send to your app a plain JSON string, deserialization can load an unsafe object to fit in your model.
Patches
Version >= 5.0.13 add some basic fixes to avoid this, but is not 100% guaranteed when using
Object
typeNext major version will contains a allow-list to select what king of Assembly can be loaded
Workarounds
Object
type - try use an interface when possibleIf your app send a plain JSON string to be insert/update into database, prefer this:
References
See this workaround fix on this commit:
litedb-org/LiteDB@4382ff4
References