Styjun

Is it possible to pass into the ModelBinder which implementation you want to use inline?

Given the following definitions:

public interface ISomeInterface

 string MyStringget;set;


public class SomeInterfaceImplementation_One : ISomeInterface

 private string _MyString;

 public string MyString
 
 get return "This is implementation One " + _MyString ; 
 set _MyString = value; 
 


public class SomeInterfaceImplementation_Two : ISomeInterface

 private string _MyString;

 public string MyString
 
 get return "This is implementation Two" + _MyString ; 
 set _MyString = value; 
 

Given this route in asp.net mvc core:

public ActionResult InterfaceWithInlineImplementation([ModelBinder(typeof(SomeBinder))]ISomeInterface SomeInterface)

 //Return actionresult

I do not want a different ModelBinder class for each implementation rather I would like each route to specify which implementation inline.

So something like:

[UseImplementation(SomeInterfaceImplementation_One)]
public ActionResult InterfaceWithInlineImplementation([ModelBinder(typeof(SomeBinder))]ISomeInterface SomeInterface)

Or:

 public ActionResult InterfaceWithInlineImplementation([ModelBinder(typeof(SomeBinder), ConcreteType = SomeInterfaceImplementation_Two )]ISomeInterface SomeInterface)
 

 

This way the SomeBinder class can access which implementation is being requested in the BindModelAsync method of SomeBinder : IModelBinder class.

public class SomeBinder : Microsoft.AspNetCore.Mvc.ModelBinding.IModelBinder
 {

 public Task BindModelAsync(Microsoft.AspNetCore.Mvc.ModelBinding.ModelBindingContext bindingContext)
 
 if (bindingContext == null)
 throw new ArgumentNullException(nameof(bindingContext));

 string valueFromBody = string.Empty;

 using (var sr = new StreamReader(bindingContext.HttpContext.Request.Body))
 
 valueFromBody = sr.ReadToEnd();
 

 if (string.IsNullOrEmpty(valueFromBody))
 
 return Task.CompletedTask;
 

 var settings = new JsonSerializerSettings()
 
 ContractResolver = new InterfaceContractResolver(), // Need requested implementation from InterfaceWithInlineImplementation() method

 ; 

 var obj = JsonConvert.DeserializeObject(valueFromBody, [**Need Requested Implementation from Method**], settings);
 bindingContext.Model = obj;


 bindingContext.Result = ModelBindingResult.Success(obj);


 return Task.CompletedTask;
 

Use generics.

public class SomeBinder<TConcreteType> : IModelBinder

Then your signature becomes

public ActionResult InterfaceWithInlineImplementation(
 [ModelBinder(typeof(SomeBinder<SomeInterfaceImpelemtation_One>))]ISomeInterface SomeInterface)

Then deserialization is:

JsonConvert.DeserializeObject<TConcreteType>(json)

However based on your last comment it sounds like you just need to Prevent overposting instead of this convoluted model binding.

So lets say the client knows that the server implementation has security methods and tries to match the signature hoping everything get deseriazled for example. Its being explicit as to what you're expecting. And you're explicitly expecting only the contract definition and nothing more.

Excerpt:

Mass assignment typically occurs during model binding as part of MVC. A simple example would be where you have a form on your website in which you are editing some data. You also have some properties on your model which are not editable as part of the form, but instead are used to control the display of the form, or may not be used at all.

public class UserModel

 public string Name get; set; 
 public bool IsAdmin get; set; 

So the idea here is that you only render a single input tag to the markup, but you post this to a method that uses the same model as you used for rendering:

[HttpPost]
public IActionResult Vulnerable(UserModel model)

 return View("Index", model);

However, with a simple bit of HTML manipulation, or by using Postman/Fiddler , a malicious user can set the IsAdmin field to true. The model binder will dutifully bind the value, and you have just fallen victim to mass assignment/over posting:

So how can you prevent this attack? Luckily there's a whole host of different ways, and they are generally the same as the approaches you could use in the previous version of ASP.NET. I'll run through a number of your options here.

Continue to article...