Para facilitar el desarrollo y aumento de la productividad, la mayoría de las estructuras modernas permiten que se pueda crear una instancia de un objeto automáticamente y rellenar con los parámetros de solicitud HTTP aquellos nombres que coincidan con un atributo de la clase para enlazarlos. Crear instancias y rellenar objetos automáticamente acelera el desarrollo pero puede ocasionar problemas graves si se implementa sin cuidado. Cualquier atributo de las clases enlazadas o clases anidadas se enlazará automáticamente a los parámetros de solicitud HTTP. Por lo tanto, los usuarios malintencionados podrán asignar un valor a cualquier atributo de las clases enlazadas o anidadas, incluso aunque no estén expuestas al cliente a través de formularios web o contratos API.

Ejemplo 1: sin configuración adicional, el siguiente método de controlador ASP.NET MVC enlazará los parámetros de solicitud HTTP a cualquier atributo de las clases RegisterModel o Details:

public ActionResult Register(RegisterModel model)
{
    if (ModelState.IsValid)
    {
        try
        {
            return RedirectToAction("Index", "Home");
        }
        catch (MembershipCreateUserException e)
        {
            ModelState.AddModelError("", "");
        }
    }
    return View(model);
}

Donde la clase RegisterModel se define como:

public class RegisterModel
{
    [BindRequired]
    [Display(Name = "User name")]
    public string UserName { get; set; }

    [BindRequired]
    [DataType(DataType.Password)]
    [Display(Name = "Password")]
    public string Password { get; set; }

    [DataType(DataType.Password)]
    [Display(Name = "Confirm password")]
    public string ConfirmPassword { get; set; }

    public Details Details { get; set; }

    public RegisterModel()
    {
        Details = new Details();
    }
}

y la clase Details se define como:

public class Details
{
    public bool IsAdmin { get; set; }
    ...
}

Ejemplo 2: al utilizar TryUpdateModel() o UpdateModel() en ASP.NET MVC o aplicaciones web API, el enlazador de modelos intentará enlazar automáticamente todos los parámetros de solicitud HTTP de forma predeterminada:

public ViewResult Register()
{
    var model = new RegisterModel();
    TryUpdateModel<RegisterModel>(model);
    return View("detail", model);
}

Ejemplo 3: En aplicaciones ASP.NET Web API, el enlazador de modelos intentará enlazar automáticamente todos los parámetros de solicitud HTTP de forma predeterminada utilizando el serializador/deserializador JSON o XML configurado. De forma predeterminada, el enlazador intentará enlazar todos los atributos posibles de los parámetros o el cuerpo de solicitud HTTP:

public class ProductsController : ApiController
{
  public string SaveProduct([FromBody] Product p)
  {
      return p.Name;
  }
  ...
}

Ejemplo 4: en aplicaciones de formularios web de ASP.NET, el enlazador de modelos intentará enlazar automáticamente todos los parámetros de solicitud HTTP de forma predeterminada utilizando TryUpdateModel() o UpdateModel() con la interfaz IValueProvider.

Employee emp = new Employee();
TryUpdateModel(emp, new System.Web.ModelBinding.FormValueProvider(ModelBindingExecutionContext)); 
if (ModelState.IsValid)
{
    db.SaveChanges();
}

y la clase Employee se define como:

 public class Employee
    {
        public Employee()
        {
            IsAdmin = false;
            IsManager = false;
        }
        public string Name { get; set; }
        public string Email { get; set; }
        public bool IsManager { get; set; }
        public bool IsAdmin { get; set; }
    }

Los objetos modelo son una representación orientada a objetos de entidades de base de datos. Proporcionan los métodos adecuados para cargar, almacenar, actualizar y eliminar entidades de base de datos asociadas.
Hibernate, Microsoft .NET Entity Framework y LINQ son ejemplos de marcos de trabajo de asignación relacional de objetos (ORM) que le ayudan a crear objetos modelo respaldados por bases de datos.

Many web frameworks strive to make life easier for developers by Muchos marcos de trabajo web tratan de facilitarles la vida a los desarrolladores proporcionando un mecanismo de enlace para los parámetros de solicitudes en objetos enlazados con solicitudes basado en la asociación de nombres de parámetros de solicitud con nombres de atributos de objeto modelo (basado en métodos públicos de asociación de getter y setter).

Si una aplicación utiliza clases ORM como objetos enlazados con solicitudes, es probable que un parámetro de solicitud pueda modificar cualquier campo en los objetos modelo correspondientes y cualquier campo anidado de un atributo de objeto.

Ejemplo 1: el Order, Customer y Profile son clases persistentes de Microsoft .NET Entity.

public class Order {
	public string ordered { get; set; }
	public List<LineItem> LineItems { get; set; }
	pubilc virtual Customer Customer { get; set; }
...
}
public class Customer {
	public int CustomerId { get; set; }
	...
	public virtual Profile Profile { get; set; }
...
}
public class Profile {
	public int profileId { get; set; }
	public string username { get; set; }
	public string password { get; set; }
	...
}

OrderController es la clase controlador MVC de ASP.NET que trata la solicitud:

public class OrderController : Controller{
	StoreEntities db = new StoreEntities();
...

	public String updateOrder(Order order) {
		...
		db.Orders.Add(order);
		db.SaveChanges();
	}
}

Dado que las clases de entidades modelo se enlazan de forma automática a las solicitudes, un atacante podría valerse de esta vulnerabilidad para actualizar la contraseña de otro usuario agregando los siguientes parámetros a la solicitud: "http://www.yourcorp.com/webApp/updateOrder?order.customer.profile.profileId=1234&order.customer.profile.password=urpowned"

Prácticamente cada ataque grave a un sistema de software comienza con la infracción de los supuestos del programador. Después del ataque, las suposiciones del programador parecen débiles y mal fundadas, pero antes de un ataque muchos programadores defenderían sus suposiciones mucho más allá del final de la hora del almuerzo.

Dos supuestos dudosos fácilmente detectables en el código son "la llamada a esta función no presentará nunca errores" y "no importa si presenta errores la función a esta llamada". Si un programador omite el valor de devolución de una función, indican de forma implícita que están trabajando baso una de estas suposiciones.
Ejemplo 1: el siguiente código no comprueba si la cadena devuelta por la propiedad Item es null antes de llamar a la función miembro Equals(), lo que podría provocar una eliminación de referencia de un valor null.

string itemName = request.Item(ITEM_NAME);
	if (itemName.Equals(IMPORTANT_ITEM)) {
		...
	}
	...

La defensa tradicional de este código de error es la siguiente:

"Sé que el valor solicitado siempre existirá porque... Si no existe, el programa no puede presentar el comportamiento deseado, por lo que no importa si gestiono el error o solo permito que el programa se anule mediante la eliminación de la referencia de un valor null".

Sin embargo, los usuarios malintencionados son expertos en buscar rutas inesperadas a través de programas, sobre todo, cuando se producen excepciones.

Prácticamente cada ataque grave a un sistema de software comienza con la infracción de los supuestos del programador. Después del ataque, las suposiciones del programador parecen débiles y mal fundadas, pero antes de un ataque muchos programadores defenderían sus suposiciones mucho más allá del final de la hora del almuerzo.

Dos supuestos dudosos fácilmente detectables en el código son "la llamada a esta función no presentará nunca errores" y "no importa si presenta errores la función a esta llamada". Si un programador omite el valor de devolución de una función, indican de forma implícita que están trabajando baso una de estas suposiciones.
Ejemplo 1: el siguiente código no comprueba si la asignación de memoria se realizó correctamente antes de intentar usar el puntero devuelto por malloc().

    buf = (char*) malloc(req_size);
    strncpy(buf, xfer, req_size);

La defensa tradicional de este código de error es la siguiente:

"Si se agota la memoria del programa, este presentará errores. No importa si administro el error o simplemente dejo que el programa finalice con un error de segmentación cuando intenta eliminar la referencia del puntero nulo".

Este argumento pasa por alto tres consideraciones importantes:

- En función del tipo y el tamaño de la aplicación, puede que sea posible liberar la memoria que se está utilizando en otra ubicación para que la ejecución pueda continuar.

- Es imposible que el programa realice una salida de manera hábil si es necesario. Si el programa realiza una operación atómica, puede dejar el sistema en un estado inconsistente.

- El programador ha perdido la oportunidad de registrar la información de diagnóstico. ¿La llamada a malloc() presentó errores debido a que req_size era demasiado grande o a que se estaban administrando demasiadas solicitudes al mismo tiempo? ¿O el error lo provocó una pérdida de memoria que se acumuló a lo largo de un periodo? Si no se administra el error, es imposible saberlo.