为便于开发和提高生产率，现代框架允许自动实例化一个对象，并使用名称与要绑定的类的属性相匹配的 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 Form 应用程序中，将 TryUpdateModel() 或 UpdateModel() 与 IValueProvider 接口结合使用时，模型绑定器将自动尝试绑定所有 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 引起的。如果不对错误进行处理，就不会知道是什么原因。

许多 DNS 服务器都很容易被攻击者欺骗，所以应考虑到某天软件有可能会在有问题的 DNS 服务器环境下运行。如果允许攻击者进行 DNS 更新（有时称为 DNS 缓存中毒），则他们会通过自己的机器路由您的网络流量，或者让他们的 IP 地址看上去就在您的域中。勿将系统安全寄托在 DNS 名称上。
示例 1：以下代码示例使用 DNS 进行查找，以确定传入的请求是否来自可信主机。如果攻击者可以攻击 DNS 缓存，那么他们就会获得信任。

 IPAddress hostIPAddress = IPAddress.Parse(RemoteIpAddress);
 IPHostEntry hostInfo = Dns.GetHostByAddress(hostIPAddress);
 if (hostInfo.HostName.EndsWith("trustme.com")) {
   trusted = true;
 }

IP 地址相比 DNS 名称而言更为可靠，但也还是可以被欺骗的。攻击者可以轻易修改要发送的数据包的源 IP 地址，但是响应数据包会返回到修改后的 IP 地址。为了看到响应的数据包，攻击者需要在受害者机器与修改的 IP 地址之间截取网络数据流。为实现这个目的，攻击者通常会尝试把自己的机器和受害者的机器部署在同一子网内。攻击者可能会巧妙地采取源地址路由的方法来回避这一要求，但是在今天的互联网上通常会禁止源地址路由。总而言之，核实 IP 地址是一种有用的 authentication 方式，但不应仅使用这一种方法进行 authentication。

getlogin() 函数应该返回一个包含当前在终端登陆的用户名的字符串，但是攻击者可使 getlogin() 返回一个任意在本机登录的用户名。不要依赖 getlogin() 返回的名称来确定是否安全。
示例 1：以下代码靠 getlogin() 来确定用户是否可以信赖。但它很容易被人暗中破坏。

 pwd = getpwnam(getlogin());
 if (isTrustedGroup(pwd->pw_gid)) {
 allow();
 } else {
 deny();
 }

无论编写程序所用的语言是什么，最具破坏性的攻击通常都会涉及执行远程代码，攻击者借此可在程序上下文中成功执行恶意代码。在 .NET Framework 中，Decoder 和 Encoding 类中的 GetChars 方法以及 Encoder 和 Encoding 类中的 GetBytes 方法在内部对字符数组和字节数组执行指针运算，以将字符范围转换为字节数范围，反之亦然。
在执行指针算术运算时，开发人员通常会以错误的方式覆盖上述方法，进而引入诸如任意代码执行、应用程序逻辑滥用和拒绝服务等漏洞。

当操作系统及其上运行的应用程序之间的字符集不匹配时，传递给默认 API 方法的不受支持的字符可通过最佳适应算法映射到危险字符。

例 1：在 Objective-C 中，以下代码示例会将包含 UTF-8 字符的 NSString 对象转换成 ASCII 数据然后返回：

...
unichar ellipsis = 0x2026;
NSString *myString = [NSString stringWithFormat:@"My Test String%C", ellipsis];
NSData *asciiData = [myString dataUsingEncoding:NSASCIIStringEncoding allowLossyConversion:YES];
NSString *asciiString = [[NSString alloc] initWithData:asciiData encoding:NSASCIIStringEncoding];
NSLog(@"Original: %@ (length %d)", myString, [myString length]);
NSLog(@"Best-fit-mapped: %@ (length %d)", asciiString, [asciiString length]);
// output:
// Original: My Test String... (length 15)
// Best-fit-mapped: My Test String... (length 17)
...

如果仔细查看输出，您会发现“...”字符已转换成三个连续的句号。如果根据输出缓冲区调整了输出缓冲区大小，则应用程序易受缓冲区溢出攻击。其他字符可从一个字符映射到两个。希腊字符“fi”会映射到“f”，后跟“i”。通过前期加载包含这些字符的缓冲区，攻击者可完全控制用于实施缓冲区溢出攻击的字符数量。

当操作系统及其上运行的应用程序之间的字符集不匹配时，传递给默认 API 方法的不受支持的字符可通过最佳适应算法映射到危险字符。

例 1：在 Swift 中，以下代码示例会将包含 UTF-8 字符的 NSString 对象转换成 ASCII 数据然后返回：

...
let ellipsis = 0x2026;
let myString = NSString(format:"My Test String %C", ellipsis)
let asciiData = myString.dataUsingEncoding(NSASCIIStringEncoding, allowLossyConversion:true)
let asciiString = NSString(data:asciiData!, encoding:NSASCIIStringEncoding)
NSLog("Original: %@ (length %d)", myString, myString.length)
NSLog("Best-fit-mapped: %@ (length %d)", asciiString!, asciiString!.length)

// output:
// Original: My Test String ... (length 16)
// Best-fit-mapped: My Test String ... (length 18)
...

如果仔细查看输出，您会发现“...”字符已转换成三个连续的句号。如果根据输出缓冲区调整了输出缓冲区大小，则应用程序易受缓冲区溢出攻击。其他字符可从一个字符映射到两个。希腊字符“fi”会映射到“f”，后跟“i”。通过前期加载包含这些字符的缓冲区，攻击者可完全控制用于实施缓冲区溢出攻击的字符数量。