为便于开发和提高生产率，现代框架允许自动实例化一个对象，并使用名称与要绑定的类的属性相匹配的 HTTP 请求参数填充该对象。对象的自动实例化和填充加快了开发速度，但如果不谨慎实施，会导致严重的问题。绑定类或嵌套类中的任何属性都将自动绑定到 HTTP 请求参数。因此，恶意用户能够将值分配给绑定类或嵌套类中的任意属性，即使这些属性未通过 Web 表单或 API 合约暴露给客户端也是如此。

示例 1：无需进行额外配置，以下 ASP.NET MVC 控制器方法便会将 HTTP 请求参数绑定到 RegisterModel 或 Details 类中的任何属性：

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

其中，RegisterModel 类定义为：

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();
    }
}

Details 类定义为：

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

示例 2：在 ASP.NET MVC、Web API 应用程序中使用 TryUpdateModel() 或 UpdateModel() 时，默认情况下，模型绑定器将自动尝试绑定所有 HTTP 请求参数：

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

示例 3：在 ASP.NET Web API 应用程序中，默认情况下，模型绑定器将使用已配置的 JSON 或 XML 序列化程序/反序列化程序自动尝试绑定所有 HTTP 请求参数。默认情况下，该绑定器将尝试绑定 HTTP 参数或正文的所有可能属性。

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

示例 4：在 ASP.NET Web 表单应用程序中，当通过 IValueProvider 界面使用 TryUpdateModel() 或 UpdateModel() 时，模型绑定器将自动尝试绑定所有的 HTTP 请求参数。

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

Employee 类定义为：

 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; }
    }

模型对象是数据库实体面向对象的表示。它们为加载、存储、更新和删除相关数据库实体提供了简便的方法。
例如，Hibernate、Microsoft .NET 实体框架和 LINQ 都是对象关系映射 (ORM) 框架，可以帮助您构建基于数据库的模型对象。

为了减轻开发人员的压力，许多 Web 框架都在努力提供相应的机制，即根据将请求参数名称与模型对象属性名称相匹配的方法将请求参数绑定到请求绑定对象（根据匹配的公共 getter 和 setter 方法）。

如果应用程序将 ORM 类作为请求绑定对象，请求参数就能够修改模型对象中的任何字段以及对象属性中的任何嵌入字段。

示例 1：Order、Customer 和 Profile 都是 Microsoft .NET 实体持久类。

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 是处理该请求的 ASP.NET MVC 控制器类：

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

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

由于模型实体类会自动绑定到该请求，因此攻击者可以利用这一漏洞，通过在该请求中添加下列请求参数来更新其他用户的密码："http://www.yourcorp.com/webApp/updateOrder?order.customer.profile.profileId=1234&order.customer.profile.password=urpowned"

几乎每一个对软件系统的严重攻击都是从违反程序员的假设开始的。攻击后，程序员的假设看起来既脆弱又拙劣，但攻击前，许多程序员会在午休时间为自己的种种假设做很好的辩护。

在代码中很容易发现的两个可疑的假设是：一是这个函数调用不可能出错；二是即使出错了，也不会对系统造成什么重要影响。当程序员忽略函数返回值时，就暗示着自己是基于上述任一假设来执行操作。
示例 1： 以下代码不会在调用成员函数 Equals() 之前检查 Item 属性返回的字符串是否为 null，从而可能会导致 null dereference。

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

对于这种编码错误的一贯辩解是：

“我知道请求的值肯定会存在，因为....如果不存在，程序就无法执行所需的行为，因此是处理该错误还是允许程序自行崩溃而间接引用 null 也就无关紧要了。”

但是，攻击者对于发现程序中的意外情况十分在行，特别是发生异常时。

几乎每一个对软件系统的严重攻击都是从违反程序员的假设开始的。攻击后，程序员的假设看起来既脆弱又拙劣，但攻击前，许多程序员会在午休时间为自己的种种假设做很好的辩护。

在代码中很容易发现的两个可疑的假设是：一是这个函数调用不可能出错；二是即使出错了，也不会对系统造成什么重要影响。当程序员忽略函数返回值时，就暗示着自己是基于上述任一假设来执行操作。
例 1：以下代码在使用由 malloc() 返回的指针之前，并没有检查内存是否分配成功。

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

对于这种编码错误的一贯辩解是：

“如果我的程序耗尽了所有内存，则会失败。无论是在程序尝试间接引用 null 指针时处理相关错误，还是允许程序自行崩溃并出现分段故障，都无关紧要。”

但是这个解释忽略了以下三个重要的因素：

— 根据应用程序的类型和大小，可能会释放由其他程序使用的内存，从而使程序继续运行。

- 程序不可能执行正常退出（如果需要）。如果程序执行原子操作，则会使系统处于不一致的状态。

— 程序员失去了记下诊断信息的机会。对 malloc() 的调用失败是不是因为 req_size 太大，还是因为在同一时刻处理的请求太多。或者是由于已累计超时的 memory leak 引起的。如果不对错误进行处理，就不会知道是什么原因。