No .NET, você pode usar a classe BinaryFormatter para transformar um objeto em um fluxo binário que contém o objeto em si e os metadados necessários para reconstruí-lo durante a desserialização.

O uso da classe BinaryFormatter pode levar a cenários de desserialização inseguros, onde invasores podem executar código arbitrário, abusar da lógica do aplicativo ou acionar uma condição de negação de serviço.

O uso do tipo BinaryFormatter é perigoso e não é recomendado para processamento de dados, pois não pode ser tornado seguro.

Exemplo 1: O aplicativo permite o uso da classe BinaryFormatter insegura definindo a propriedade de configuração EnableUnsafeBinaryFormatterSerialization como true no arquivo runtimeConfig.json.

...
AppContext.SetSwitch("System.Runtime.Serialization.EnableUnsafeBinaryFormatterSerialization", true);
...

A API AccessibleObject permite que o programador contorne as verificações de controle de acesso fornecidas por especificadores de acesso Java. Em particular, ela possibilita que o programador permita que um objeto refletido contorne controles de acesso Java e, por sua vez, altere o valor de campos particulares ou invoque métodos privados, comportamentos que são normalmente proibidos.

Em um aplicativo JSF regular, os valores são convertidos e validados usando conversores e validadores especificados pelos componentes de IU. A conversão e validação em si acontecem quando a página é enviada. Uma visualização favoritável de um aplicativo Fusion resulta no não envio da página e, portanto, nenhuma conversão ou validação semelhante é realizada por padrão.

Exemplo 1: O seguinte trecho de um arquivo de configuração mostra uma amostra de visualização favoritável, configurada para não realizar conversão ou validação do parâmetro do URL paramName.

...
    <bookmark>
        <method>#{paramHandler.handleParams}</method>
        <url-parameter>
            <name>paramName</name>
            <value>#{requestScope.paramName}</value>
        </url-parameter>
    </bookmark>
...

Os valores de atributos para componentes do Oracle ADF Faces podem ser definidos normalmente apenas no servidor. No entanto, vários componentes permitem que o desenvolvedor defina uma lista de atributos que podem ser definidos no cliente. O atributo unsecure desses componentes pode especificar uma lista como essa.

Atualmente, o único atributo que pode aparecer dentro do atributo unsecure é disabled e permite que o cliente defina quais componentes estão habilitados e quais não estão. Nunca é uma boa ideia deixar que o cliente controle os valores de atributos que só devem ser configuráveis no servidor.

Exemplo 1: O código a seguir demonstra um componente inputText que coleta informações de senha do usuário e usa o atributo unsecure.

...
    <af:inputText id="pwdBox"
                  label="#{resources.PWD}"
                  value=""#{userBean.password}
                  unsecure="disabled"
                  secret="true"
                  required="true"/>
...

Os cookies são estritamente um mecanismo HTTP, de acordo com a RFC 2109. Não deve haver expectativa razoável de que eles trabalhem para protocolos que não sejam HTTP, incluindo file://. Não está claro qual deve ser seu comportamento e quais regras de compartimentalização de segurança devem ser aplicadas. Por exemplo, os arquivos HTML baixados para o disco local da Internet compartilham os mesmos cookies que qualquer código HTML instalado localmente?

Vulnerabilidades de Sequestro de Carregamento de Classe Android assumem duas formas:

- Um invasor pode alterar o nome dos diretórios pesquisados pelo programa para carregar classes, apontando o caminho para um diretório sobre o qual ele tem controle: o invasor controla explicitamente os caminhos que devem ser pesquisados em busca de classes.

- Um invasor pode alterar o ambiente no qual a classe é carregada: o invasor controla implicitamente o que o nome do caminho significa.

Nesse caso, estamos preocupados principalmente com o primeiro cenário, com a possibilidade de que um invasor seja capaz de controlar os diretórios pesquisados por classes a serem carregadas. Vulnerabilidades de Sequestro de Carregamento de Classe Android desse tipo ocorrem quando:

1. Os dados entram em um aplicativo por uma fonte não confiável.



2. Os dados são usados como uma string, ou parte de uma string, que representa um diretório de biblioteca para procurar classes a serem carregadas.



3. Ao executar o código no caminho da biblioteca, o aplicativo concede ao invasor um privilégio ou uma capacidade que ele não teria de outra forma.

Exemplo 1: O código a seguir usa o userClassPath alterável pelo usuário para determinar o diretório no qual procurar classes a serem carregadas.

...
  productCategory = this.getIntent().getExtras().getString("userClassPath");
  DexClassLoader dexClassLoader = new DexClassLoader(productCategory, optimizedDexOutputPath.getAbsolutePath(), null, getClassLoader());
  ...

Esse código permite que um invasor carregue uma biblioteca e execute possivelmente um código arbitrário com o privilégio elevado do aplicativo, sendo capaz de modificar o resultado de userClassPath de forma que ele aponte para um caminho diferente que o invasor pode controlar. Como o programa não valida o valor lido do ambiente, se um invasor puder controlar o valor de userClassPath, ele poderá enganar o aplicativo de forma com que este aponte para um diretório controlado pelo invasor e, portanto, poderá carregar as classes que ele definiu usando os mesmos privilégios que o aplicativo original.

Exemplo 2: O código a seguir usa a userOutput modificável pelo usuário para determinar o diretório em que os arquivos DEX otimizados devem ser escritos.

...
  productCategory = this.getIntent().getExtras().getString("userOutput");
  DexClassLoader dexClassLoader = new DexClassLoader(sanitizedPath, productCategory, null, getClassLoader());
...

Esse código permite que um invasor especifique o diretório de saída para arquivos DEX otimizados (ODEX). Isso então permite que um usuário mal-intencionado altere o valor de userOutput para um diretório que ele pode controlar, como um armazenamento externo. Quando isso for conseguido, será simplesmente uma questão de substituir o arquivo ODEX processado por um arquivo ODEX mal-intencionado para que este seja executado com os mesmos privilégios do aplicativo original.

Vulnerabilidades de travessia de caminho de Zip ocorrem quando um agente malicioso consegue especificar nomes de entrada de arquivo Zip em um determinado arquivo Zip. Quando um nome de entrada de arquivo Zip é especificado maliciosamente, um invasor pode substituir o conteúdo dos principais arquivos do sistema quando o arquivo Zip correspondente é expandido. Os invasores podem usar expressões idiomáticas de travessia de caminho, como ../ e / para acessar arquivos do sistema que de outra forma estariam fora do escopo do programa. Os aplicativos Android que têm como alvo o Android 14 e versões posteriores podem, por padrão, lançar uma exceção quando expressões idiomáticas como ../ e/ são detectadas durante a extração do arquivo Zip. Esse recurso de segurança pode ser substituído ou desabilitado completamente.

Exemplo 1: O código a seguir desabilita a proteção contra Zip Entry Overwrite.

...
dalvik.system.ZipPathValidator.clearCallback();
...

Entradas não verificadas são a principal causa de vulnerabilidades em serviços de API da Web ASP.NET. Entradas não verificadas podem resultar em muitas vulnerabilidades, incluindo cross-site scripting, process control, access control e SQL injection. Embora serviços de API da Web ASP.NET geralmente não sejam suscetíveis a ataques de memory corruption, se esse tipo de serviço for chamado em um código nativo que não realiza a verificação de limites de array, um invasor talvez seja capaz de usar uma fraqueza de validação de entrada no serviço de API da Web ASP.NET para lançar um ataque de buffer overflow.

Para impedir esses ataques:
1. use os atributos de validação para anotar programaticamente verificações de validação em parâmetros ou membros de parâmetros de objeto de associação de modelos a ações de serviços de API da Web ASP.NET.
2. use ModelState.IsValid para verificar se a validação de modelo é aprovada.

O middleware ASP.NET Core que não é adicionado ao pipeline de middleware na ordem correta não funcionará conforme o esperado, deixando um aplicativo aberto a vários problemas de segurança.

Exemplo 1: O método UseCookiePolicy() adiciona o middleware de política de cookie ao pipeline de middleware, permitindo políticas de cookie personalizadas. Quando especificado na ordem errada, como mostrado, qualquer política de cookie indicada pelo programador será ignorada.

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseCookiePolicy();
...

O middleware ASP.NET Core que não é adicionado ao pipeline de middleware na ordem correta não funcionará conforme o esperado, deixando um aplicativo aberto a vários problemas de segurança.

Exemplo 1: O método UseHttpsRedirection() adiciona o middleware de redirecionamento HTTPS ao pipeline de middleware, que permite o redirecionamento de solicitações HTTP não seguras para uma solicitação HTTPS segura. Quando especificado na ordem errada, conforme mostrado, nenhum redirecionamento HTTPS significativo ocorrerá antes de processar a solicitação por meio do middleware listado antes do redirecionamento. Isso permitirá que as solicitações HTTP sejam processadas pelo aplicativo antes de serem redirecionadas para a conexão HTTPS segura.

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseHttpsRedirection();
...

O middleware ASP.NET Core que não é adicionado ao pipeline de middleware na ordem correta não funcionará conforme o esperado, deixando um aplicativo aberto a vários problemas de segurança.

Exemplo 1: O método UseHttpLogging() adiciona middleware de registro em log HTTP ao pipeline de middleware que permite que os componentes de middleware sejam registrados em log. Quando especificado na ordem errada, conforme mostrado, nenhum middleware adicionado ao pipeline antes da chamada para UseHttpLogging() será registrado em log.

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseHttpLogging();
...

Exemplo 2: O método UseWC3Logging() adiciona o middleware de registro em log do W3C ao pipeline de middleware que permite que os componentes de middleware sejam registrados em log. Quando especificado na ordem errada, conforme mostrado, nenhum middleware adicionado ao pipeline antes da chamada para UseWC3Logging() será registrado em log.

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseWC3Logging();
...

As ações do controlador ASP.NET MVC que modificam dados gravando, atualizando ou excluindo podem se beneficiar da restrição de aceitar um dos seguintes verbos HTTP: Post, Put, Patch ou Delete. Isso aumenta a dificuldade de falsificação de solicitação entre sites, pois o clique acidental de links não fará com que a ação seja executada.

A ação de controlador a seguir aceita qualquer verbo por padrão e pode ser suscetível a falsificação de solicitações entre sites:

public ActionResult UpdateWidget(Model model)
{
  // ... controller logic
}

Usar uma classe de modelo que possui propriedades obrigatórias (marcadas com o atributo [Required]) e propriedades opcionais (não marcadas com o atributo [Required]) pode provocar problemas quando um invasor comunica uma solicitação que contém mais dados que o esperado.

A estrutura MVC ASP.NET tentará associar parâmetros de solicitação a propriedades de modelo.

O fato de haver níveis combinados de exigência sem a comunicação explícita de quais parâmetros devem ser associados a modelos pode indicar que existem propriedades de modelo para uso interno, mas que essas propriedades podem ser controladas por um invasor.

O código a seguir define uma possível classe de modelo que tem propriedades com [Required] e propriedades sem [Required]:

public class MyModel
{
    [Required]
    public String UserName { get; set; }

    [Required]
    public String Password { get; set; }

    public Boolean IsAdmin { get; set; }
}

Se qualquer parâmetro opcional puder alterar o comportamento de um aplicativo, talvez um invasor seja capaz de realmente mudar esse comportamento comunicando um parâmetro opcional em uma solicitação.

Usar uma classe de modelo que possui propriedades obrigatórias não anuláveis (marcadas com o atributo [Required]) pode provocar problemas quando um invasor comunica uma solicitação que contém menos dados do que o esperado.

A estrutura MVC ASP.NET tentará associar parâmetros de solicitação a propriedades de modelo.

Se um modelo tiver um parâmetro obrigatório não anulável e um invasor não comunicar esse parâmetro em uma solicitação -- ou seja, se o invasor usar um ataque under-posting --, a propriedade terá o valor padrão (geralmente zero), que atenderá ao atributo de validação [Required]. Isso pode provocar o comportamento inesperado do aplicativo.

O código a seguir define uma classe de modelo possível que possui uma enumeração obrigatória não anulável:

public enum ArgumentOptions
{
    OptionA = 1,
    OptionB = 2
}

public class Model
{
    [Required]
    public String Argument { get; set; }

    [Required]
    public ArgumentOptions Rounding { get; set; }
}

Se uma classe de modelo tiver a propriedade obrigatória e for do tipo de um membro opcional de uma classe de modelo pai, ela poderá ser suscetível a ataques under-posting se um invasor comunicar uma solicitação contendo menos dados que o esperado.

A estrutura MVC ASP.NET tentará associar parâmetros de solicitação a propriedades de modelo, incluindo submodelos.

Se um submodelo for opcional -- ou seja, se o modelo pai tiver uma propriedade sem o atributo [Required] -- e se um invasor não comunicar esse submodelo, então a propriedade pai terá um valor null, e os campos obrigatórios do modelo filho não serão confirmados pela validação de modelo. Essa é uma das formas de ataque under-posting.

Considere as seguintes definições de classe de modelo:

public class ChildModel
{
    public ChildModel()
    {
    }

    [Required]
    public String RequiredProperty { get; set; }
}

public class ParentModel
{
    public ParentModel()
    {
    }

    public ChildModel Child { get; set; }
}

Se um invasor não comunicar um valor para a propriedade ParentModel.Child, a propriedade ChildModel.RequiredProperty terá um [Required] não confirmado. Isso pode produzir resultados inesperados e indesejáveis.

Nomes e valores de propriedades de bean precisam ser validados antes do preenchimento de qualquer bean. Funções de preenchimento de beans permitem que os desenvolvedores definam uma propriedade de bean ou uma propriedade aninhada. Os invasores podem utilizar essa funcionalidade para acessar propriedades especiais de beans, como class.classLoader, o que permitirá que ele substitua as propriedades do sistema e potencialmente execute código arbitrário.

Exemplo 1: O código a seguir define uma propriedade de bean controlada pelo usuário sem a devida validação do nome da propriedade ou do valor:

String prop = request.getParameter('prop');
String value = request.getParameter('value');
HashMap properties = new HashMap();
properties.put(prop, value);
BeanUtils.populate(user, properties);

De acordo com a política da Apple, o aplicativo deve sempre explicar aos usuários por que suas impressões digitais são necessárias. Não fazer isso pode confundir o usuário ou mesmo fazer com que o aplicativo seja rejeitado na AppStore.

Exemplo 1: O código a seguir usa a ID de toque para autenticar o usuário, mas não fornece um motivo localizado que explique porque a autenticação é necessária:

    [context evaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics localizedReason:nil
        reply:^(BOOL success, NSError *error) {
            if (success) {
                NSLog(@"Auth was OK");
            } 
    }];

O buffer overflow é provavelmente a forma mais conhecida de vulnerabilidade de segurança de software. A maioria dos desenvolvedores de software sabe o que é uma vulnerabilidade de buffer overflow, mas ataques de buffer overflow contra aplicativos legados e recém-desenvolvidos ainda são bastante comuns. Uma parte do problema deve-se à grande variedade de maneiras de como estouros de buffer podem ocorrer, enquanto outra parte deve-se às técnicas propensas a erros frequentemente utilizadas para impedir esses estouros.

Em uma exploração de buffer overflow clássica, o invasor envia dados a um programa, que ele armazena em um buffer de pilha de tamanho menor do que o normal. O resultado é que as informações na pilha de chamadas são substituídas, incluindo o apontador de retorno da função. Os dados definem o valor do apontador de retorno de forma que, quando a função é retornada, ela transfere o controle para o código mal-intencionado contido nos dados do invasor.

Embora esse tipo de buffer overflow de pilha ainda seja comum em algumas plataformas e comunidades de desenvolvimento, há vários outros tipos de buffer overflow, incluindo estouros de buffer de heap e erros "off-by-one", entre outros. Existem diversos livros excelentes que fornecem informações detalhadas sobre como ataques de buffer overflow funcionam, entre eles Building Secure Software [1], Writing Secure Code [2] e The Shellcoder's Handbook [3].

Em nível de código, vulnerabilidades de buffer overflow geralmente envolvem a violação das premissas do programador. Muitas funções de manipulação de memória em C e C++ não realizam verificações de limites e podem facilmente substituir os limites alocados dos buffers sob os quais elas operam. Até mesmo funções limitadas, como strncpy(), podem causar vulnerabilidades quando usadas incorretamente. A combinação entre manipulação de memória e suposições equivocadas sobre o tamanho ou a composição de um determinado dado é a causa raiz da maioria dos estouros de buffer.

Em geral, vulnerabilidades de buffer overflow ocorrem em um código que:

- Baseia-se em dados externos para controlar seu comportamento.

- Depende de propriedades dos dados que são aplicados fora do escopo imediato do código.

- É tão complexo que um programador não consegue prever seu comportamento com precisão.



Os exemplos a seguir demonstram todos esses três cenários.

Exemplo 1.a: O exemplo de código a seguir demonstra um buffer overflow simples que muitas vezes é causado pelo primeiro cenário, em que o código se baseia em dados externos para controlar seu comportamento. O código usa a função gets() para ler uma quantidade arbitrária de dados em um buffer de pilha. Como não há nenhuma maneira de limitar a quantidade de dados lida por essa função, a segurança do código depende de o usuário sempre inserir menos de BUFSIZE caracteres.

	...
	char buf[BUFSIZE];
	gets(buf);
	...

Exemplo 1.b: Este exemplo mostra como é fácil imitar o comportamento não seguro da função gets() em C++ usando o operador >> para ler a entrada em uma string char[].

	...
	char buf[BUFSIZE];
	cin >> (buf);
	...

Exemplo 2: O código neste exemplo também se baseia na entrada do usuário para controlar seu comportamento, mas adiciona um certo nível de desvio com o uso da função de cópia de memória limitada memcpy(). Essa função aceita um buffer de destino, um buffer de origem e o número de bytes a serem copiados. O buffer de entrada é preenchido por uma chamada limitada para read(), mas o usuário especifica o número de bytes que são copiados por memcpy().

	...
char buf[64], in[MAX_SIZE];
printf("Enter buffer contents:\n");
read(0, in, MAX_SIZE-1);
printf("Bytes to copy:\n");
scanf("%d", &bytes);
memcpy(buf, in, bytes);
	...

Observação: Esse tipo de vulnerabilidade de buffer overflow (em que um programa lê os dados e depois confia em um valor desses dados em operações de memória subsequentes nos dados restantes) apareceu com uma determinada frequência em bibliotecas de imagem e áudio e também em outras bibliotecas de processamento de arquivos.

Exemplo 3: Este é um exemplo do segundo cenário, no qual o código depende de propriedades dos dados que não são verificadas localmente. Neste exemplo, uma função denominada lccopy() usa uma string como seu argumento e retorna uma cópia alocada por heap dessa string com letras maiúsculas convertidas em minúsculas. A função não realiza verificações de limites em sua entrada, pois espera que str sempre seja menor que BUFSIZE. Se um invasor ignorar as verificações no código que chama lccopy() ou se uma mudança nesse código tornar inválida a suposição sobre o tamanho de str, lccopy() fará o estouro de buf com a chamada ilimitada para strcpy().

char *lccopy(const char *str) {
	char buf[BUFSIZE];
	char *p;

	strcpy(buf, str);
	for (p = buf; *p; p++) {
		if (isupper(*p)) {
			*p = tolower(*p);
		}
	}
	return strdup(buf);
}

Exemplo 4: O código a seguir demonstra o terceiro cenário em que o código é tão complexo que seu comportamento não pode ser facilmente previsto. Esse código vem do popular decodificador de imagens libPNG, que é usado por uma ampla variedade de aplicativos.

O código parece realizar a verificação de limites com segurança, pois verifica o tamanho do comprimento de variáveis, que ele utiliza mais tarde para controlar a quantidade de dados copiada por png_crc_read(). No entanto, logo antes de testar o comprimento, o código realiza uma verificação em png_ptr->mode e, se essa verificação falhar, um aviso será emitido e o processamento continuará. Como length é testado em um bloco else if, length não poderá ser testado se a primeira verificação falhar e será usado às cegas na chamada para png_crc_read(), possivelmente permitindo um buffer overflow de pilha.

Embora o código nesse exemplo não seja o mais complexo que vimos até agora, ele demonstra por que a complexidade deve ser minimizada no código que realiza operações de memória.

if (!(png_ptr->mode & PNG_HAVE_PLTE)) {
	/* Should be an error, but we can cope with it */
png_warning(png_ptr, "Missing PLTE before tRNS");
}
else if (length > (png_uint_32)png_ptr->num_palette) {
png_warning(png_ptr, "Incorrect tRNS chunk length");
png_crc_finish(png_ptr, length);
return;
}
...
png_crc_read(png_ptr, readbuf, (png_size_t)length);

Exemplo 5: Este exemplo também demonstra o terceiro cenário, no qual a complexidade do programa o expõe a estouros de buffer. Nesse caso, a exposição é decorrente da interface ambígua de uma das funções, e não da estrutura do código (como foi o caso no exemplo anterior).

A função getUserInfo() usa um nome de usuário especificado como uma string de vários bytes e um apontador para uma estrutura de informações do usuário e preenche essa estrutura com informações sobre o usuário. Como a autenticação do Windows usa Unicode para nomes de usuário, o argumento username é primeiro convertido de uma string de vários bytes em uma string Unicode. Em seguida, essa função transmite incorretamente o tamanho de unicodeUser em bytes em vez de em caracteres. Portanto, a chamada para MultiByteToWideChar() pode gravar caracteres com um comprimento de até (UNLEN+1)*sizeof(WCHAR), ou
(UNLEN+1)*sizeof(WCHAR)*sizeof(WCHAR) bytes, na matriz unicodeUser, que tem apenas (UNLEN+1)*sizeof(WCHAR) bytes alocados. Se a string username contiver mais de UNLEN caracteres, a chamada para MultiByteToWideChar() causará um estouro no buffer unicodeUser.

void getUserInfo(char *username, struct _USER_INFO_2 info){
WCHAR unicodeUser[UNLEN+1];
	MultiByteToWideChar(CP_ACP, 0, username, -1,
    	      			unicodeUser, sizeof(unicodeUser));
NetUserGetInfo(NULL, unicodeUser, 2, (LPBYTE *)&info);
}

O buffer overflow é provavelmente a forma mais conhecida de vulnerabilidade de segurança de software. A maioria dos desenvolvedores de software sabe o que é uma vulnerabilidade de buffer overflow, mas ataques de buffer overflow contra aplicativos legados e recém-desenvolvidos ainda são bastante comuns. Uma parte do problema deve-se à grande variedade de maneiras de como estouros de buffer podem ocorrer, enquanto outra parte deve-se às técnicas propensas a erros frequentemente utilizadas para impedir esses estouros.

Em uma exploração de buffer overflow clássica, o invasor envia dados a um programa, que ele armazena em um buffer de pilha de tamanho menor do que o normal. O resultado é que as informações na pilha de chamadas são substituídas, incluindo o apontador de retorno da função. Os dados definem o valor do apontador de retorno de forma que, quando a função é retornada, ela transfere o controle para o código mal-intencionado contido nos dados do invasor.

Embora esse tipo de buffer overflow de pilha ainda seja comum em algumas plataformas e comunidades de desenvolvimento, há vários outros tipos de buffer overflow, incluindo estouros de buffer de heap e erros "off-by-one", entre outros. Existem diversos livros excelentes que fornecem informações detalhadas sobre como ataques de buffer overflow funcionam, entre eles Building Secure Software [1], Writing Secure Code [2] e The Shellcoder's Handbook [3].

Em nível de código, vulnerabilidades de buffer overflow geralmente envolvem a violação das premissas do programador. Muitas funções de manipulação de memória em C e C++ não realizam verificações de limites e podem facilmente exceder os limites alocados dos buffers sob os quais elas operam. Até mesmo funções limitadas, como strncpy(), podem causar vulnerabilidades quando usadas incorretamente. A combinação entre manipulação de memória e suposições equivocadas sobre o tamanho ou a composição de um determinado dado é a causa raiz da maioria dos estouros de buffer.

Nesse caso, uma cadeia de formato indevidamente construída faz com que o programa grave além dos limites da memória alocada.

Exemplo 1: Exemplo: O código a seguir estoura c porque o tipo double requer mais espaço do que está alocado para c.

void formatString(double d) {
    char c;

    scanf("%d", &c)
}

O buffer overflow é provavelmente a forma mais conhecida de vulnerabilidade de segurança de software. A maioria dos desenvolvedores de software sabe o que é uma vulnerabilidade de buffer overflow, mas ataques de buffer overflow contra aplicativos legados e recém-desenvolvidos ainda são bastante comuns. Uma parte do problema deve-se à grande variedade de maneiras de como estouros de buffer podem ocorrer, enquanto outra parte deve-se às técnicas propensas a erros frequentemente utilizadas para impedir esses estouros.

Em uma exploração de buffer overflow clássica, o invasor envia dados a um programa, que ele armazena em um buffer de pilha de tamanho menor do que o normal. O resultado é que as informações na pilha de chamadas são substituídas, incluindo o apontador de retorno da função. Os dados definem o valor do apontador de retorno de forma que, quando a função é retornada, ela transfere o controle para o código mal-intencionado contido nos dados do invasor.

Embora esse tipo de buffer overflow de pilha ainda seja comum em algumas plataformas e comunidades de desenvolvimento, há vários outros tipos de buffer overflow, incluindo estouros de buffer de heap e erros "off-by-one", entre outros. Existem diversos livros excelentes que fornecem informações detalhadas sobre como ataques de buffer overflow funcionam, entre eles Building Secure Software [1], Writing Secure Code [2] e The Shellcoder's Handbook [3].

Em nível de código, vulnerabilidades de buffer overflow geralmente envolvem a violação das premissas do programador. Muitas funções de manipulação de memória em C e C++ não realizam verificações de limites e podem facilmente exceder os limites alocados dos buffers sob os quais elas operam. Até mesmo funções limitadas, como strncpy(), podem causar vulnerabilidades quando usadas incorretamente. A combinação entre manipulação de memória e suposições equivocadas sobre o tamanho ou a composição de um determinado dado é a causa raiz da maioria dos estouros de buffer.

Nesse caso, uma cadeia de formato indevidamente construída faz com que o programa grave além dos limites da memória alocada.

Exemplo 1: O código a seguir estoura buf porque, dependendo do tamanho de f, o especificador de string de formato"%d %.1f ... " pode exceder a quantidade de memória alocada.

void formatString(int x, float f) {
   char buf[40];
   sprintf(buf, "%d %.1f ... ", x, f);
}