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 las aplicaciones de formulario web ASP.NET, el enlazador de modelos intentará enlazar automáticamente todos los parámetros de solicitud HTTP cuando se utilice 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.

Muchos servidores DNS son susceptibles de sufrir ataques, por eso debe suponer que su software se ejecutará alguna vez en un entorno con un servidor DNS afectado. Si los atacantes están autorizados a hacer actualizaciones de DNS (a veces denominado envenenamiento de la caché del DNS), pueden redirigir su tráfico de red a través de sus equipos o hacer que parezca que sus direcciones IP forman parte de su dominio. No base la seguridad de su sistema en nombres DNS.
Ejemplo 1: El siguiente ejemplo de código utiliza una búsqueda DNS para determinar si una solicitud entrante es de un host de confianza o no. Si un atacante es capaz de dañar la caché DNS, puede obtener un estatus de confianza.

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

Las direcciones IP son más confiables que los nombres DNS, pero también se pueden reemplazar. Los atacantes pueden falsificar fácilmente las direcciones IP de origen de los paquetes que envían, aunque los paquetes de respuesta volverán a la dirección IP falsificada. Para ver los paquetes de respuesta, el atacante tiene que examinar el tráfico entre el equipo víctima y la dirección IP falsificada. A fin de completar el examen necesario, los atacantes normalmente intentan ubicarse en la misma subred que el equipo víctima. Los atacantes podrían ser capaces de evitar este requisito empleando enrutamiento de origen, aunque el enrutamiento de origen esté deshabilitado actualmente en gran parte de Internet. En resumen, la verificación de las direcciones IP puede ser una parte útil de un esquema de autenticación, pero no debe ser el único factor necesario para la autenticación.

Se supone que la función getlogin() devuelve una cadena que contiene el nombre del usuario registrado actualmente en el terminal. Sin embargo, un atacante podría hacer que getlogin() devuelva el nombre de todos los usuarios registrado en el equipo. No confíe en el nombre devuelto por getlogin() cuando tome decisiones relacionadas con la seguridad.
Ejemplo 1: el código siguiente se basa en getlogin() para determinar si un usuario es de confianza o no. Es fácil de subvertir.

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

Independientemente del lenguaje en el que esté escrito un programa, los ataques más devastadores normalmente incluyen la ejecución remota de código, con la cual un atacante consigue ejecutar código malintencionado en el contexto del programa. El método GetChars en las clases Decoder y Encoding, y el método GetBytes en las clases Encoder y Encoding de .NET Framework llevan a cabo aritmética de puntero de forma interna en las matrices de caracteres y bytes para convertir un intervalo de caracteres en un intervalo de bytes y viceversa.
Cuando se realizan operaciones de aritmética de puntero, los desarrolladores suelen sustituir los métodos anteriores incorrectamente e introducen vulnerabilidades como la ejecución de código arbitrario, el abuso de la lógica de la aplicación y la denegación del servicio.

Cuando los juegos de caracteres entre el sistema operativo y las aplicaciones que se ejecutan en este no coinciden, los caracteres no admitidos que se pasan a los métodos de la API de forma predeterminada pueden asignarse con ajuste perfecto a caracteres peligrosos.

Ejemplo 1:en Objective-C, el ejemplo siguiente convierte un objeto NSString que contiene un carácter UTF-8 a datos ASCII de nuevo:

...
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)
...

Si examina cuidadosamente el resultado, el carácter "..." se tradujo por tres puntos consecutivos. Si ha medido el búfer de salida basándose en el búfer de entrada, la aplicación podría ser vulnerable al buffer overflow. Se pueden asignar otros caracteres de un carácter a dos. El carácter griego "fi" se asignará a una "f" seguida de una letra "i". Al cargar el búfer con estos caracteres de carga frontal, un usuario malintencionado obtiene un control completo sobre el número de caracteres que se utilizan para provocar el buffer overflow.

Cuando los juegos de caracteres entre el sistema operativo y las aplicaciones que se ejecutan en este no coinciden, los caracteres no admitidos que se pasan a los métodos de la API de forma predeterminada pueden asignarse con ajuste perfecto a caracteres peligrosos.

Ejemplo 1: En Swift, el ejemplo siguiente convierte un objeto NSString que contiene un carácter UTF-8 a datos ASCII de nuevo:

...
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)
...

Si examina cuidadosamente el resultado, el carácter "..." se tradujo por tres puntos consecutivos. Si ha medido el búfer de salida basándose en el búfer de entrada, la aplicación podría ser vulnerable al buffer overflow. Se pueden asignar otros caracteres de un carácter a dos. El carácter griego "fi" se asignará a una "f" seguida de una letra "i". Al cargar el búfer con estos caracteres de carga frontal, un usuario malintencionado obtiene un control completo sobre el número de caracteres que se utilizan para provocar el buffer overflow.