Para facilitar o desenvolvimento e aumentar a produtividade, a maioria das estruturas moderna permite que um objeto seja instanciado automaticamente e preenchido com os parâmetros de solicitações HTTP cujos nomes correspondem a um atributo da classe a ser associada. A instanciação e o preenchimento automáticos de objetos acelera o desenvolvimento, mas podem provocar sérios problemas se forem implementados sem precauções. Qualquer atributo nas classes associadas, ou classes aninhadas, será automaticamente associado aos parâmetros de solicitações HTTP. Portanto, usuários mal-intencionados poderão atribuir um valor a qualquer atributo em classes vinculadas ou aninhadas, mesmo se que estas não estejam expostas ao cliente por meio de formulários da Web ou contratos de API.

Exemplo 1: Sem configuração adicional, o seguinte método de controlador MVC ASP.NET associará os parâmetros de solicitações HTTP a qualquer atributo nas classes RegisterModel ou Details:

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

Em que a classe RegisterModel é definida 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();
    }
}

e a classe Details é definida como:

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

Exemplo 2: Ao usar TryUpdateModel() ou UpdateModel() em aplicativos ASP.NET MVC ou Web API, o associador de modelo tentará vincular automaticamente todos os parâmetros de solicitações HTTP por padrão:

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

Exemplo 3: Em aplicativos de API Web ASP.NET, o associador de modelo tentará associar automaticamente todos os parâmetros de solicitações HTTP usando o serializador/desserializador JSON ou XML configurado. Por padrão, o associador tentará associar todos os possíveis atributos do corpo ou dos parâmetros de solicitações HTTP:

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

Exemplo 4: Em aplicativos de Formulário da Web ASP.NET, o associador de modelo tentará associar automaticamente todos os parâmetros de solicitações HTTP ao usar TryUpdateModel() ou UpdateModel() com a interface IValueProvider.

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

e a classe Employee é definida 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; }
    }

Objetos de modelo são uma representação orientada a objetos de entidades de banco de dados. Eles fornecem métodos de conveniência para carregar, armazenar, atualizar e excluir entidades de banco de dados associadas.
O Hibernate, a estrutura Microsoft .NET Entity e o LINQ são exemplos de estruturas Object Relational Mapping (ORM) que ajudam você a construir objetos de modelo reforçados por banco de dados.

Muitas estruturas da Web se esforçam para facilitar a vida dos desenvolvedores fornecendo um mecanismo de associação de parâmetros de solicitação a objetos associados a solicitações com base em nomes de parâmetro de solicitação correspondentes a nomes de atributo de objetos de modelo (com base em métodos "getter" e "setter" públicos correspondentes).

Se um aplicativo usar classes ORM como objetos associados a solicitações, é provável que um parâmetro de solicitação possa modificar qualquer campo em objetos de modelo correspondentes e em qualquer campo aninhado de um atributo de objeto.

Exemplo 1: As classes Order, Customer e Profile são classes do Microsoft .NET Entity mantidas como persistentes.

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 é uma de classe de controlador MVC ASP.NET que lida com a solicitação:

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

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

Como classes de entidades de modelo são automaticamente associadas a solicitações, um invasor pode usar essa vulnerabilidade para atualizar a senha de outro usuário adicionando os seguintes parâmetros de solicitação à solicitação: "http://www.yourcorp.com/webApp/updateOrder?order.customer.profile.profileId=1234&order.customer.profile.password=urpowned"

Quase todos os ataques sérios em um sistema de software começam com a violação das premissas de um programador. Depois do ataque, essas premissas parecem frágeis e infundadas, mas, antes dele, muitos programadores as defenderiam com grande veemência.

Duas suposições duvidosas que são fáceis de detectar no código são "essa chamada de função nunca pode falhar" e "não importa se essa chamada de função falhar". Quando um programador ignora o valor de retorno de uma função, ele afirma implicitamente estar operando de acordo com uma dessas suposições.
Exemplo 1: O código a seguir não verifica se a string retornada pela propriedade Item é null antes de chamar a função membro Equals(), causando possivelmente um cancelamento de referência null

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

A defesa tradicional desse erro de codificação é:

"Sei que o valor solicitado sempre existirá porque... Se não existir, o programa não poderá executar o comportamento desejado e, portanto, não importa se eu manipular o erro ou simplesmente permitir que o programa se torne inativo ao tentar desfazer a referência a um valor null."

Porém, os invasores são hábeis em encontrar caminhos inesperados através de programas, particularmente quando exceções estão envolvidas.

Quase todos os ataques sérios em um sistema de software começam com a violação das premissas de um programador. Depois do ataque, essas premissas parecem frágeis e infundadas, mas, antes dele, muitos programadores as defenderiam com grande veemência.

Duas suposições duvidosas que são fáceis de detectar no código são "essa chamada de função nunca pode falhar" e "não importa se essa chamada de função falhar". Quando um programador ignora o valor de retorno de uma função, ele afirma implicitamente estar operando de acordo com uma dessas suposições.
Exemplo 1: O código a seguir não verifica se a alocação de memória foi bem-sucedida antes de tentar usar o ponteiro retornado por malloc().

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

A defesa tradicional desse erro de codificação é:

"Se meu programa ficar sem memória, ele falhará. Não importa se eu tratar o erro ou simplesmente permitir que o programa se torne inativo com uma falha de segmentação ao tentar desreferenciar o ponteiro nulo."

Esse argumento ignora três considerações importantes:

- Dependendo do tipo e do tamanho do aplicativo, pode ser possível liberar a memória que está sendo usada em outro local para que a execução possa continuar.

- É impossível para o programa realizar uma saída normal, se necessário. Se o programa realizar uma operação atômica, ele poderá deixar o sistema em estado inconsistente.

- O programador perdeu a oportunidade de registrar informações de diagnóstico. A chamada para malloc() falhou por que req_size era grande demais ou por que muitas solicitações estavam sendo tratadas ao mesmo tempo? Ou ela foi causada por um vazamento de memória que se acumulou com o passar do tempo? Sem realizar o tratamento do erro, não há como saber.