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 ASP.NET Web Form, o associador do modelo tentará vincular automaticamente todos os parâmetros de solicitação HTTP ao usar TryUpdateModel() ouUpdateModel() 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.

Muitos servidores DNS são suscetíveis a ataques de falsificação e, portanto, você deve partir do princípio de que algum dia o seu software será executado em um ambiente com um servidor DNS comprometido. Se os invasores tiverem permissão para fazer atualizações de DNS (processo às vezes chamado de envenenamento de cache de DNS), eles poderão rotear seu tráfego de rede através das máquinas deles ou causar a impressão de que os endereços IP deles fazem parte do seu domínio. Não baseie a segurança do seu sistema em nomes DNS.
Exemplo 1: A amostra de código a seguir usa uma pesquisa de DNS para decidir se uma solicitação de entrada é ou não proveniente de um host confiável. Se um invasor puder envenenar o cache de DNS, ele poderá obter um status confiável.

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

Endereços IP são mais confiáveis que nomes DNS, mas também podem ser falsificados. Os invasores podem facilmente falsificar o endereço IP de origem dos pacotes que eles enviam, mas os pacotes de resposta retornarão ao endereço IP falsificado. Para ver os pacotes de resposta, o invasor precisa realizar o sniffing do tráfego entre a máquina da vítima e o endereço IP falsificado. Para realizar o sniffing necessário, os invasores normalmente tentam se localizar na mesma sub-rede que a máquina da vítima. Os invasores podem ser capazes de se esquivar dessa exigência usando o roteamento de origem, mas esse roteamento não está habilitado em uma grande extensão da Internet hoje em dia. Em resumo, a verificação de endereços IP pode ser uma parte útil de um esquema de autenticação, mas não deve ser o único fator necessário para a autenticação.

A função getlogin() deve retornar uma string contendo o nome do usuário atualmente conectado ao terminal, mas um invasor pode fazer com que getlogin() retorne o nome de qualquer usuário conectado à máquina. Não confie no nome retornado por getlogin() ao tomar decisões de segurança.
Exemplo 1: O código a seguir se baseia em getlogin() para determinar se um usuário é ou não confiável. Isso é facilmente contestado.

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

Independentemente da linguagem na qual um programa está escrito, os ataques mais devastadores muitas vezes envolvem a execução de código remoto, por meio da qual um invasor consegue executar código mal-intencionado com sucesso no contexto do programa. O método GetChars nas classes Decoder & Encoding, e o método GetBytes nas classes Encoder & Encoding no .NET Framework executam internamente a aritmética de ponteiro nas matrizes char e byte para converter o intervalo de caracteres em um intervalo de bytes e vice-versa.
Durante a execução de operações de aritmética de ponteiro, os desenvolvedores muitas vezes substituem os métodos precedentes de uma maneira ruim e introduzem vulnerabilidades, como execução de código arbitrário, abuso da lógica do aplicativo e negação de serviço.

Quando conjuntos de caracteres são incompatíveis entre o sistema operacional e os aplicativos em execução no sistema operacional, os caracteres não suportados passados para os métodos de API padrão podem ser mapeados com um melhor ajuste para caracteres perigosos.

Exemplo 1: Em Objective-C, o seguinte exemplo converte um objeto NSString que contém um caractere UTF-8 em dados ASCII e depois o converte de volta:

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

Se você observar a saída com cuidado, o caractere "..." foi traduzido para três pontos consecutivos. Se você tinha dimensionado o buffer de saída com base no buffer de entrada, o aplicativo poderia estar vulnerável a um buffer overflow. Outros caracteres podem ser mapeados de um caractere para dois. O caractere grego "fi" será mapeado como um "f" seguido por um "i". Ao fazer o carregamento frontal do buffer com esses caracteres, um invasor obtém o controle completo sobre o número de caracteres usados para estourar o buffer.

Quando conjuntos de caracteres são incompatíveis entre o sistema operacional e os aplicativos em execução no sistema operacional, os caracteres não suportados passados para os métodos de API padrão podem ser mapeados com um melhor ajuste para caracteres perigosos.

Exemplo 1: Em Swift, o seguinte exemplo converte um objeto NSString que contém um caractere UTF-8 em dados ASCII e depois o converte de volta:

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

Se você observar a saída com cuidado, o caractere "..." foi traduzido para três pontos consecutivos. Se você tinha dimensionado o buffer de saída com base no buffer de entrada, o aplicativo poderia estar vulnerável a um buffer overflow. Outros caracteres podem ser mapeados de um caractere para dois. O caractere grego "fi" será mapeado como um "f" seguido por um "i". Ao fazer o carregamento frontal do buffer com esses caracteres, um invasor obtém o controle completo sobre o número de caracteres usados para estourar o buffer.