Erros de controle de acesso ao banco de dados ocorrem quando:

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


2. Os dados são utilizados para especificar o valor de uma chave primária em uma consulta SQL.
Exemplo 1: O código a seguir usa uma instrução que depende de um número inteiro e que, portanto, não é sensível a vulnerabilidades de SQL Injection, para construir e executar uma consulta SQL que procura uma fatura correspondente ao identificador especificado [1]. O identificador é selecionado de uma lista de todas as faturas associadas ao usuário autenticado atual.

DATA: id TYPE i.
...
id = request->get_form_field( 'invoiceID' ).

CONCATENATE `INVOICEID = '` id `'` INTO cl_where.
SELECT *
    FROM invoices
    INTO CORRESPONDING FIELDS OF TABLE itab_invoices
    WHERE (cl_where).
ENDSELECT.
...

O problema é que o desenvolvedor não considerou todos os valores possíveis de ID. Embora a interface gere uma lista de identificadores de fatura que pertencem ao usuário atual, um invasor pode ignorar essa interface para solicitar qualquer fatura desejada. Como o código neste exemplo não faz nenhuma verificação para garantir que o usuário tem permissão para acessar a fatura solicitada, ele exibirá qualquer fatura, mesmo que ela não pertença ao usuário atual.

Erros de controle de acesso ao banco de dados ocorrem quando:

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


2. Os dados são utilizados para especificar o valor de uma chave primária em uma consulta SQL.
Exemplo 1: O código a seguir usa uma instrução parametrizada, que escapa metacaracteres e impede vulnerabilidades de SQL Injection, para construir e executar uma consulta SQL que procura uma fatura correspondente ao identificador especificado [1]. O identificador é selecionado de uma lista de todas as faturas associadas ao usuário autenticado atual.

        ...
        var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
        var id:int = int(Number(params["invoiceID"]));
        var query:String = "SELECT * FROM invoices WHERE id = :id";

        stmt.sqlConnection = conn;
        stmt.text = query;
        stmt.parameters[":id"] = id;
        stmt.execute();
        ...

O problema é que o desenvolvedor não considerou todos os valores possíveis de id. Embora a interface gere uma lista de identificadores de fatura que pertencem ao usuário atual, um invasor pode ignorar essa interface para solicitar qualquer fatura desejada. Como o código neste exemplo não faz nenhuma verificação para garantir que o usuário tem permissão para acessar a fatura solicitada, ele exibirá qualquer fatura, mesmo que ela não pertença ao usuário atual.

Erros de controle de acesso ao banco de dados ocorrem quando:

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


2. Os dados são utilizados para especificar o valor de uma chave primária em uma consulta SOQL/SOSL.
Exemplo 1: No seguinte exemplo de código, o valor inputID é originado de uma lista predefinida, e um variável de associação ajuda a prevenir a injeção de SOQL/SOSL.

...
result = [SELECT Name, Phone FROM Contact WHERE (IsDeleted = false AND Id=:inputID)];
...

O problema com o exemplo anterior é que o uso de uma lista predefinida de IDs é insuficiente para evitar que o usuário modifique o valor de inputID. Se o invasor for capaz de ignorar a interface e enviar uma solicitação com um valor diferente, ele terá acesso a outras informações de contato. Como o código neste exemplo não verifica se o usuário tem permissão para acessar o contato solicitado, ele exibirá qualquer contato, mesmo que o usuário não esteja autorizado a vê-lo.

Erros de controle de acesso ao banco de dados ocorrem quando:

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

2. Os dados são utilizados para especificar o valor de uma chave primária em uma consulta LINQ.
Exemplo 1: O código a seguir usa uma consulta LINQ que procura uma fatura correspondente ao identificador especificado [1]. O identificador é selecionado de uma lista de todas as faturas associadas ao usuário autenticado atual.

...

int16 id = System.Convert.ToInt16(invoiceID.Text);
var invoice = OrderSystem.getInvoices()
	.Where(new Invoice { invoiceID = id });
...

O problema é que o desenvolvedor não considerou todos os valores possíveis de id. Embora a interface gere uma lista de identificadores de fatura que pertencem ao usuário atual, um invasor pode ignorar essa interface para solicitar qualquer fatura desejada. Como o código neste exemplo não faz nenhuma verificação para garantir que o usuário tem permissão para acessar a fatura solicitada, ele exibirá qualquer fatura, mesmo que ela não pertença ao usuário atual.

Erros de controle de acesso ao banco de dados ocorrem quando:

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


2. Os dados são utilizados para especificar o valor de uma chave primária em uma consulta SQL.
Exemplo 1: O código a seguir usa uma instrução parametrizada, que escapa metacaracteres e impede vulnerabilidades de SQL Injection, para construir e executar uma consulta SQL que procura uma fatura correspondente ao identificador especificado [1]. O identificador é selecionado de uma lista de todas as faturas associadas ao usuário autenticado atual.

...
CMyRecordset rs(&dbms);
rs.PrepareSQL("SELECT * FROM invoices WHERE id = ?");
rs.SetParam_int(0,atoi(r.Lookup("invoiceID").c_str()));
rs.SafeExecuteSQL();
...

O problema é que o desenvolvedor não considerou todos os valores possíveis de id. Embora a interface gere uma lista de identificadores de fatura que pertencem ao usuário atual, um invasor pode ignorar essa interface para solicitar qualquer fatura desejada. Como o código neste exemplo não faz nenhuma verificação para garantir que o usuário tem permissão para acessar a fatura solicitada, ele exibirá qualquer fatura, mesmo que ela não pertença ao usuário atual.

Erros de controle de acesso ao banco de dados ocorrem quando:

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


2. Os dados são utilizados para especificar o valor de uma chave primária em uma consulta SQL.
Exemplo 1: O código a seguir usa uma instrução parametrizada, que escapa metacaracteres e impede vulnerabilidades de SQL Injection, para construir e executar uma consulta SQL que procura uma fatura correspondente ao identificador especificado [1]. O identificador é selecionado de uma lista de todas as faturas associadas ao usuário autenticado atual.

...
ACCEPT ID.
EXEC SQL
    DECLARE C1 CURSOR FOR
    SELECT INVNO, INVDATE, INVTOTAL
    FROM INVOICES
    WHERE INVOICEID = :ID
END-EXEC.
...

O problema é que o desenvolvedor não considerou todos os valores possíveis de ID. Embora a interface gere uma lista de identificadores de fatura que pertencem ao usuário atual, um invasor pode ignorar essa interface para solicitar qualquer fatura desejada. Como o código neste exemplo não faz nenhuma verificação para garantir que o usuário tem permissão para acessar a fatura solicitada, ele exibirá qualquer fatura, mesmo que ela não pertença ao usuário atual.

Erros de controle de acesso ao banco de dados ocorrem quando:

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


2. Os dados são utilizados para especificar o valor de um nome de banco de dados.

Erros de controle de acesso ao banco de dados ocorrem quando:

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


2. Os dados são utilizados para especificar o valor de uma chave primária em uma consulta SQL.
Exemplo 1: O código a seguir usa uma instrução parametrizada, que faz o escape de metacaracteres e impede vulnerabilidades de SQL Injection, para criar e executar uma consulta SQL que pesquisa uma fatura correspondente ao identificador especificado [1]. O identificador é selecionado de uma lista de todas as faturas associadas ao usuário autenticado atual.

...
id := request.FormValue("invoiceID")
query := "SELECT * FROM invoices WHERE id = ?";
rows, err := db.Query(query, id)
...

O problema é que o desenvolvedor não considerou todos os valores possíveis de id. Embora a interface gere uma lista de identificadores de fatura que pertencem ao usuário atual, um invasor pode ignorar essa interface para solicitar qualquer fatura desejada. Como o código neste exemplo não faz nenhuma verificação para garantir que o usuário tem permissão para acessar a fatura solicitada, ele exibirá qualquer fatura, mesmo que ela não pertença ao usuário atual.

Erros de controle de acesso ao banco de dados ocorrem quando:

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


2. Os dados são utilizados para especificar o valor de uma chave primária em uma consulta SQL.
Exemplo 1: O código a seguir usa uma instrução parametrizada, que escapa metacaracteres e impede vulnerabilidades de SQL Injection, para construir e executar uma consulta SQL que procura uma fatura correspondente ao identificador especificado [1]. O identificador é selecionado de uma lista de todas as faturas associadas ao usuário autenticado atual.

...
id = Integer.decode(request.getParameter("invoiceID"));
String query = "SELECT * FROM invoices WHERE id = ?";
PreparedStatement stmt = conn.prepareStatement(query);
stmt.setInt(1, id);
ResultSet results = stmt.execute();
...

O problema é que o desenvolvedor não considerou todos os valores possíveis de id. Embora a interface gere uma lista de identificadores de fatura que pertencem ao usuário atual, um invasor pode ignorar essa interface para solicitar qualquer fatura desejada. Como o código neste exemplo não faz nenhuma verificação para garantir que o usuário tem permissão para acessar a fatura solicitada, ele exibirá qualquer fatura, mesmo que ela não pertença ao usuário atual.

Algumas pessoas acham que, no mundo móvel, as vulnerabilidades clássicas de aplicativos Web, como erros de controle de acesso a bancos de dados, não fazem sentido -- por que um usuário atacaria a si mesmo? No entanto, lembre-se de que a essência das plataformas móveis são aplicativos que são baixados de várias fontes e executados lado a lado no mesmo dispositivo. A probabilidade de execução de um malware junto com um aplicativo de banco é alta, o que exige a expansão da superfície de ataque de aplicativos móveis de forma a incluir comunicações entre processos.

Exemplo 2: O código a seguir adapta o Example 1 à plataforma Android.

...
        String id = this.getIntent().getExtras().getString("invoiceID");
        String query = "SELECT * FROM invoices WHERE id = ?";
        SQLiteDatabase db = this.openOrCreateDatabase("DB", MODE_PRIVATE, null);
        Cursor c = db.rawQuery(query, new Object[]{id});
...

Várias estruturas modernas da Web fornecem mecanismos para realizar a validação de entradas do usuário (como o Struts e o Struts 2). Para destacar as fontes não validadas de entradas, os pacotes seguros de regras de codificação do Fortify estabelecem dinamicamente uma nova prioridade para os problemas que o Fortify Static Code Analyzer relata, diminuindo sua probabilidade de exploração e fornecendo ponteiros para as evidências sempre que o mecanismo de validação de estrutura estiver em uso. Chamamos esse recurso de Classificação Sensível ao Contexto. Para ajudar ainda mais o usuário do Fortify com o processo de auditoria, o Fortify Software Security Research Group disponibiliza o modelo de projeto de Validação de Dados, que agrupa os problemas em pastas com base no mecanismo de validação aplicado à respectiva fonte de entrada.

Erros de controle de acesso ao banco de dados ocorrem quando:

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


2. Os dados são utilizados para especificar o valor de uma chave primária em uma consulta SQL.
Exemplo 1: O código a seguir usa uma instrução parametrizada, que escapa metacaracteres e impede vulnerabilidades de SQL Injection, para construir e executar uma consulta SQL que procura uma fatura correspondente ao identificador especificado [1]. O identificador é selecionado de uma lista de todas as faturas associadas ao usuário autenticado atual.

	...
	var id = document.form.invoiceID.value;
	var query = "SELECT * FROM invoices WHERE id = ?";
	db.transaction(function (tx) {
		tx.executeSql(query,[id]);
		}
	)
	...

O problema é que o desenvolvedor não considerou todos os valores possíveis de id. Embora a interface gere uma lista de identificadores de fatura que pertencem ao usuário atual, um invasor pode ignorar essa interface para solicitar qualquer fatura desejada. Como o código neste exemplo não faz nenhuma verificação para garantir que o usuário tem permissão para acessar a fatura solicitada, ele exibirá qualquer fatura, mesmo que ela não pertença ao usuário atual.

Erros de controle de acesso ao banco de dados ocorrem quando:

1.Os dados entram em um programa de uma fonte não confiável.


2.Os dados são usados para especificar o valor de uma chave primária em uma consulta SQL.
Exemplo 1: O código a seguir usa uma instrução parametrizada, que escapa metacaracteres e impede vulnerabilidades de SQL Injection, para construir e executar uma consulta SQL que procura uma fatura correspondente ao identificador especificado. O identificador é selecionado de uma lista de todas as faturas associadas ao usuário autenticado atual.

...

        NSManagedObjectContext *context = [appDelegate managedObjectContext];
        NSEntityDescription *entityDesc = [NSEntityDescription entityForName:@"Invoices" inManagedObjectContext:context];
        NSFetchRequest *request = [[NSFetchRequest alloc] init];
        [request setEntity:entityDesc];
        NSPredicate *pred = [NSPredicate predicateWithFormat:@"(id = %@)", invoiceId.text];
        [request setPredicate:pred];

        NSManagedObject *matches = nil;
        NSError *error;
        NSArray *objects = [context executeFetchRequest:request error:&error];

        if ([objects count] == 0) {
                 status.text = @"No records found.";
        } else {
                matches = [objects objectAtIndex:0];
                invoiceReferenceNumber.text = [matches valueForKey:@"invRefNum"];
                orderNumber.text = [matches valueForKey:@"orderNumber"];
                status.text = [NSString stringWithFormat:@"%d records found", [objects count]];
        }
        [request release];
...

O problema é que o desenvolvedor não considerou todos os valores possíveis de id. Embora a interface gere uma lista de identificadores de fatura que pertencem ao usuário atual, um invasor pode ignorar essa interface para solicitar qualquer fatura desejada. Como o código neste exemplo não faz nenhuma verificação para garantir que o usuário tem permissão para acessar a fatura solicitada, ele exibirá qualquer fatura, mesmo que ela não pertença ao usuário atual.

Erros de controle de acesso ao banco de dados ocorrem quando:

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


2. Os dados são utilizados para especificar o valor de uma chave primária em uma consulta SQL.
Exemplo 1: O código a seguir usa uma instrução parametrizada, que escapa metacaracteres e impede vulnerabilidades de SQL Injection, para construir e executar uma consulta SQL que procura uma fatura correspondente ao identificador especificado [1]. O identificador é selecionado de uma lista de todas as faturas associadas ao usuário autenticado atual.

        ...
	$id = $_POST['id'];
	$query = "SELECT * FROM invoices WHERE id = ?";
	$stmt = $mysqli->prepare($query);
	$stmt->bind_param('ss',$id);
	$stmt->execute();
        ...

O problema é que o desenvolvedor não considerou todos os valores possíveis de id. Embora a interface gere uma lista de identificadores de fatura que pertencem ao usuário atual, um invasor pode ignorar essa interface para solicitar qualquer fatura desejada. Como o código neste exemplo não faz nenhuma verificação para garantir que o usuário tem permissão para acessar a fatura solicitada, ele exibirá qualquer fatura, mesmo que ela não pertença ao usuário atual.

Várias estruturas modernas da Web fornecem mecanismos para realizar a validação de entradas do usuário (como o Struts e o Struts 2). Para destacar as fontes não validadas de entradas, os pacotes seguros de regras de codificação do Fortify estabelecem dinamicamente uma nova prioridade para os problemas que o Fortify Static Code Analyzer relata, diminuindo sua probabilidade de exploração e fornecendo ponteiros para as evidências sempre que o mecanismo de validação de estrutura estiver em uso. Chamamos esse recurso de Classificação Sensível ao Contexto. Para ajudar ainda mais o usuário do Fortify com o processo de auditoria, o Fortify Software Security Research Group disponibiliza o modelo de projeto de Validação de Dados, que agrupa os problemas em pastas com base no mecanismo de validação aplicado à respectiva fonte de entrada.

Erros de controle de acesso ao banco de dados ocorrem quando:

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

2. Os dados são utilizados para especificar o valor de uma chave primária em uma consulta SQL.
Exemplo 1: O código a seguir usa uma instrução parametrizada, que escapa metacaracteres e impede vulnerabilidades de SQL Injection, para construir e executar uma consulta SQL que procura uma fatura correspondente ao identificador especificado [1]. O identificador é selecionado de uma lista de todas as faturas associadas ao usuário autenticado atual.

procedure get_item (
itm_cv IN OUT ItmCurTyp,
id in varchar2)
is
open itm_cv for ' SELECT * FROM items WHERE ' ||
'invoiceID = :invid' ||
     	using id;
end get_item;

O problema é que o desenvolvedor não considerou todos os valores possíveis de id. Embora a interface gere uma lista de identificadores de fatura que pertencem ao usuário atual, um invasor pode ignorar essa interface para solicitar qualquer fatura desejada. Como o código neste exemplo não faz nenhuma verificação para garantir que o usuário tem permissão para acessar a fatura solicitada, ele exibirá qualquer fatura, mesmo que ela não pertença ao usuário atual.

Erros de controle de acesso ao banco de dados ocorrem quando:

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


2. Os dados são utilizados para especificar o valor de uma chave primária em uma consulta SQL.
Exemplo 1: O código a seguir usa uma instrução parametrizada, que escapa metacaracteres e impede vulnerabilidades de SQL Injection, para construir e executar uma consulta SQL que procura uma fatura correspondente ao identificador especificado [1]. O identificador é selecionado de uma lista de todas as faturas associadas ao usuário autenticado atual.

...
id = request.POST['id']
c = db.cursor()
stmt = c.execute("SELECT * FROM invoices WHERE id = %s", (id,))
...

O problema é que o desenvolvedor não considerou todos os valores possíveis de id. Embora a interface gere uma lista de identificadores de fatura que pertencem ao usuário atual, um invasor pode ignorar essa interface para solicitar qualquer fatura desejada. Como o código neste exemplo não faz nenhuma verificação para garantir que o usuário tem permissão para acessar a fatura solicitada, ele exibirá qualquer fatura, mesmo que ela não pertença ao usuário atual.

Erros de controle de acesso ao banco de dados ocorrem quando:

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


2. Os dados são utilizados para especificar o valor de uma chave primária em uma consulta SQL.
Exemplo 1: O código a seguir usa uma instrução parametrizada, que escapa metacaracteres e impede vulnerabilidades de SQL Injection, para construir e executar uma consulta SQL que procura uma fatura correspondente ao identificador especificado [1]. O identificador é selecionado de uma lista de todas as faturas associadas ao usuário autenticado atual.

...
id = req['invoiceID'].respond_to(:to_int)
query = "SELECT * FROM invoices WHERE id=?"
stmt = conn.prepare(query)
stmt.execute(id)
...

O problema é que o desenvolvedor não considerou todos os valores possíveis de id. Embora a interface gere uma lista de identificadores de fatura que pertencem ao usuário atual, um invasor pode ignorar essa interface para solicitar qualquer fatura desejada. Como o código neste exemplo não faz nenhuma verificação para garantir que o usuário tem permissão para acessar a fatura solicitada, ele exibirá qualquer fatura, mesmo que ela não pertença ao usuário atual.

Erros de controle de acesso ao banco de dados ocorrem quando:

1.Os dados entram em um programa de uma fonte não confiável.


2.Os dados são usados para especificar o valor de uma chave primária em uma consulta SQL.
Exemplo 1: O código a seguir usa uma instrução parametrizada, que escapa metacaracteres e impede vulnerabilidades de SQL Injection, para construir e executar uma consulta SQL que procura uma fatura correspondente ao identificador especificado. O identificador é selecionado de uma lista de todas as faturas associadas ao usuário autenticado atual.

...
let fetchRequest = NSFetchRequest()
let entity = NSEntityDescription.entityForName("Invoices", inManagedObjectContext: managedContext)
fetchRequest.entity = entity
let pred : NSPredicate = NSPredicate(format:"(id = %@)", invoiceId.text)
fetchRequest.setPredicate = pred
do {
    let results = try managedContext.executeFetchRequest(fetchRequest)
    let result : NSManagedObject = results.first!
    invoiceReferenceNumber.text = result.valueForKey("invRefNum")
    orderNumber.text = result.valueForKey("orderNumber")
    status.text = "\(results.count) records found"
} catch let error as NSError {
    print("Error \(error)")
}
...

O problema é que o desenvolvedor não considerou todos os valores possíveis de id. Embora a interface gere uma lista de identificadores de fatura que pertencem ao usuário atual, um invasor pode ignorar essa interface para solicitar qualquer fatura desejada. Como o código neste exemplo não faz nenhuma verificação para garantir que o usuário tem permissão para acessar a fatura solicitada, ele exibirá qualquer fatura, mesmo que ela não pertença ao usuário atual.

Erros de controle de acesso ao banco de dados ocorrem quando:

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


2. Os dados são utilizados para especificar o valor de uma chave primária em uma consulta SQL.
Exemplo 1: O código a seguir usa uma instrução parametrizada, que escapa metacaracteres e impede vulnerabilidades de SQL Injection, para construir e executar uma consulta SQL que procura uma fatura correspondente ao identificador especificado [1]. O identificador é selecionado de uma lista de todas as faturas associadas ao usuário autenticado atual.

	...
	id = Request.Form("invoiceID")
	strSQL = "SELECT * FROM invoices WHERE id = ?"
	objADOCommand.CommandText = strSQL
	objADOCommand.CommandType = adCmdText
	set objADOParameter = objADOCommand.CreateParameter("id" , adString, adParamInput, 0, 0)
	objADOCommand.Parameters("id") = id
	...

O problema é que o desenvolvedor não considerou todos os valores possíveis de id. Embora a interface gere uma lista de identificadores de fatura que pertencem ao usuário atual, um invasor pode ignorar essa interface para solicitar qualquer fatura desejada. Como o código neste exemplo não faz nenhuma verificação para garantir que o usuário tem permissão para acessar a fatura solicitada, ele exibirá qualquer fatura, mesmo que ela não pertença ao usuário atual.

Vulnerabilidades de injeção de comandos assumem duas formas:

- Um invasor pode alterar o comando executado pelo programa: o invasor controla explicitamente qual é esse comando.

- Um invasor pode alterar o ambiente no qual o comando é executado: o invasor controla implicitamente o que esse comando significa.

Nesse caso, estamos preocupados principalmente com o primeiro cenário, com a possibilidade de que um invasor seja capaz de controlar o comando que é executado. Vulnerabilidades de injeção de comandos 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 comando executado pelo aplicativo.

3. Ao executar o comando, 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 de um utilitário do sistema usa a chave do registro APPHOME para determinar o diretório no qual ele está instalado e, em seguida, executa um script de inicialização com base em um caminho relativo a partir do diretório especificado.

...
CALL FUNCTION 'REGISTRY_GET'
  EXPORTING
     KEY   = 'APPHOME'
  IMPORTING
     VALUE = home.

CONCATENATE home INITCMD INTO cmd.
CALL 'SYSTEM' ID 'COMMAND' FIELD cmd ID 'TAB' FIELD TABL[].
...

O código no Example 1 permite que um invasor execute comandos arbitrários com o privilégio elevado do aplicativo, modificando a entrada do registro APPHOME de forma que ela aponte para um caminho diferente contendo uma versão mal-intencionada de INITCMD. Como o programa não valida o valor lido do registo, se um invasor puder controlar o valor da chave do registro APPHOME, ele poderá enganar o aplicativo, fazendo com que este execute o código mal-intencionado, e assumir o controle do sistema.

Exemplo 2: O código a seguir é de um aplicativo Web administrativo projetado para permitir que os usuários iniciem um backup de um banco de dados Oracle usando um wrapper de arquivos em lote em torno do utilitário rman e, em seguida, executem um script cleanup.bat para excluir alguns arquivos temporários. O script rmanDB.bat aceita um único parâmetro de linha de comando, que especifica o tipo de backup a ser realizado. Como o acesso ao banco de dados é restrito, o aplicativo executa o backup como um usuário privilegiado.

...
btype = request->get_form_field( 'backuptype' )
CONCATENATE `/K 'c:\\util\\rmanDB.bat ` btype `&&c:\\util\\cleanup.bat'` INTO cmd.

CALL FUNCTION 'SXPG_COMMAND_EXECUTE_LONG'
  EXPORTING
    commandname                   = cmd_exe
    long_params                   = cmd_string
  EXCEPTIONS
    no_permission                 = 1
    command_not_found             = 2
    parameters_too_long           = 3
    security_risk                 = 4
    OTHERS                        = 5.
...

O problema aqui é que o programa não realiza validações no parâmetro backuptype lido do usuário. Em geral, o módulo da função SXPG_COMMAND_EXECUTE_LONG não executará vários comandos, mas, nesse caso, o programa primeiro executa o shell cmd.exe para executar vários comandos com uma única chamada para CALL 'SYSTEM'. Uma vez invocado, o shell permitirá a execução de vários comandos separados por dois "Es" comerciais (símbolo &). Se um invasor transmitir uma string no formato "&& del c:\\dbms\\*.*", o aplicativo executará esse comando juntamente com os outros especificados pelo programa. Devido à natureza do aplicativo, ele é executado com os privilégios necessários para interagir com o banco de dados, o que significa que qualquer comando injetado pelo invasor também será executado com esses privilégios.

Exemplo 3: O código a seguir é de um aplicativo Web que fornece aos usuários uma interface através da qual eles podem atualizar suas senhas no sistema. Parte do processo de atualização de senhas em determinados ambientes de rede é executar um comando make no diretório /var/yp.

...
MOVE 'make' to cmd.
CALL 'SYSTEM' ID 'COMMAND' FIELD cmd ID 'TAB' FIELD TABL[].
...

O problema aqui é que o programa não especifica um caminho absoluto para make e não consegue limpar o ambiente antes de executar a chamada para CALL 'SYSTEM'. Se um invasor puder modificar a variável $PATH a fim de que aponte para um binário malicioso chamado make e fazer com que o programa seja executado no ambiente dele, o binário malicioso será carregado ao invés do binário pretendido. Por causa da natureza do aplicativo, ele é executado com os privilégios necessários para realizar operações do sistema, o que significa que, agora, o make do invasor será executado com esses privilégios, possivelmente concedendo a ele controle total sobre o sistema.

Vulnerabilidades de injeção de comandos assumem duas formas:

- Um invasor pode alterar o comando executado pelo programa: o invasor controla explicitamente qual é esse comando.

- Um invasor pode alterar o ambiente no qual o comando é executado: o invasor controla implicitamente o que esse comando significa.

Nesse caso, estamos preocupados principalmente com o primeiro cenário, com a possibilidade de que um invasor seja capaz de controlar o comando que é executado. Vulnerabilidades de injeção de comandos 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 comando executado pelo aplicativo.

3. Ao executar o comando, 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 uma entrada de arquivo de configuração para determinar o diretório no qual ele está instalado e, em seguida, executa um script de inicialização com base em um caminho relativo a partir do diretório especificado.

        ...
        var fs:FileStream = new FileStream();
        fs.open(new File(String(configStream.readObject())+".txt"), FileMode.READ);
        home = String(fs.readObject(home));
        var cmd:String = home + INITCMD;
        fscommand("exec", cmd);
        ...

O código no Example 1 permite que um invasor execute comandos arbitrários com o privilégio elevado do aplicativo, modificando o conteúdo do arquivo de configuração configStream de forma que ele aponte para um caminho diferente contendo uma versão mal-intencionada de INITCMD. Como o programa não valida o valor lido do arquivo, se um invasor puder controlar esse valor, ele poderá enganar o aplicativo, fazendo com que este execute o código mal-intencionado, e assumir o controle do sistema.

Exemplo 2: O código a seguir é de um aplicativo Web administrativo projetado para permitir que os usuários iniciem um backup de um banco de dados Oracle usando um wrapper de arquivos em lote em torno do utilitário rman e, em seguida, executem um script cleanup.bat para excluir alguns arquivos temporários. O script rmanDB.bat aceita um único parâmetro de linha de comando, que especifica o tipo de backup a ser realizado. Como o acesso ao banco de dados é restrito, o aplicativo executa o backup como um usuário privilegiado.

        ...
        var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
        var btype:String = String(params["backuptype"]);
        var cmd:String = "cmd.exe /K \"c:\\util\\rmanDB.bat " + btype + "&&c:\\util\\cleanup.bat\"";
        fscommand("exec", cmd);
        ...

O problema aqui é que o programa não realiza validações no parâmetro backuptype lido do usuário. Em geral, o módulo da função fscommand() não executará vários comandos, mas, nesse caso, o programa primeiro executa o shell cmd.exe para executar vários comandos com uma única chamada para fscommnd(). Uma vez invocado, o shell permitirá a execução de vários comandos separados por dois "Es" comerciais (símbolo &). Se um invasor transmitir uma string no formato "&& del c:\\dbms\\*.*", o aplicativo executará esse comando juntamente com os outros especificados pelo programa. Devido à natureza do aplicativo, ele é executado com os privilégios necessários para interagir com o banco de dados, o que significa que qualquer comando injetado pelo invasor também será executado com esses privilégios.

Exemplo 3: O código a seguir é de um aplicativo Web que fornece aos usuários uma interface através da qual eles podem atualizar suas senhas no sistema. Parte do processo de atualização de senhas em determinados ambientes de rede é executar um comando make no diretório /var/yp.

        ...
        fscommand("exec", "make");
        ...

O problema aqui é que o programa não especifica um caminho absoluto para make e não consegue limpar o ambiente antes de executar a chamada para fscommand(). Se um invasor puder modificar a variável $PATH a fim de que aponte para um binário malicioso chamado make e fazer com que o programa seja executado no ambiente dele, o binário malicioso será carregado ao invés do binário pretendido. Por causa da natureza do aplicativo, ele é executado com os privilégios necessários para realizar operações do sistema, o que significa que, agora, o make do invasor será executado com esses privilégios, possivelmente concedendo a ele controle total sobre o sistema.

Vulnerabilidades de injeção de comandos assumem duas formas:

- Um invasor pode alterar o comando executado pelo programa: o invasor controla explicitamente qual é esse comando.

- Um invasor pode alterar o ambiente no qual o comando é executado: o invasor controla implicitamente o que esse comando significa.

Nesse caso, estamos preocupados principalmente com o primeiro cenário, com a possibilidade de que um invasor seja capaz de controlar o comando que é executado. Vulnerabilidades de injeção de comandos 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 comando executado pelo aplicativo.

3. Ao executar o comando, 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 de um utilitário do sistema usa a propriedade do sistema APPHOME para determinar o diretório no qual ele está instalado e, em seguida, executa um script de inicialização com base em um caminho relativo a partir do diretório especificado.

...
string val = Environment.GetEnvironmentVariable("APPHOME");
string cmd = val + INITCMD;
ProcessStartInfo startInfo = new ProcessStartInfo(cmd);
Process.Start(startInfo);
...

O código no Example 1 permite que um invasor execute comandos arbitrários com o privilégio elevado do aplicativo, modificando a propriedade do sistema APPHOME de forma que ela aponte para um caminho diferente contendo uma versão mal-intencionada de INITCMD. Como o programa não valida o valor lido do ambiente, se um invasor puder controlar o valor da propriedade do sistema APPHOME, ele poderá enganar o aplicativo, fazendo com que este execute o código mal-intencionado, e assumir o controle do sistema.

Exemplo 2: O código a seguir é de um aplicativo Web administrativo projetado para permitir que os usuários iniciem um backup de um banco de dados Oracle usando um wrapper de arquivos em lote em torno do utilitário rman e, em seguida, executem um script cleanup.bat para excluir alguns arquivos temporários. O script rmanDB.bat aceita um único parâmetro de linha de comando, que especifica o tipo de backup a ser realizado. Como o acesso ao banco de dados é restrito, o aplicativo executa o backup como um usuário privilegiado.

...
string btype = BackupTypeField.Text;
string cmd = "cmd.exe /K \"c:\\util\\rmanDB.bat"
              + btype + "&&c:\\util\\cleanup.bat\""));
Process.Start(cmd);
...

O problema aqui é que o programa não realiza validações em BackupTypeField. Em geral, a função Process.Start() não executará vários comandos, mas, nesse caso, o programa primeiro executa o shell cmd.exe para executar vários comandos com uma única chamada para Process.Start(). Uma vez invocado, o shell permitirá a execução de vários comandos separados por dois "Es" comerciais (símbolo &). Se um invasor transmitir uma string no formato "&& del c:\\dbms\\*.*", o aplicativo executará esse comando juntamente com os outros especificados pelo programa. Devido à natureza do aplicativo, ele é executado com os privilégios necessários para interagir com o banco de dados, o que significa que qualquer comando injetado pelo invasor também será executado com esses privilégios.

Exemplo 3: O código a seguir é de um aplicativo Web que dá aos usuários acesso a uma interface através da qual eles podem atualizar suas senhas no sistema. Parte do processo de atualização de senhas nesse ambiente de rede é executar um comando update.exe, da seguinte forma:

...
Process.Start("update.exe");
...

O problema aqui é que o programa não especifica um caminho absoluto e não consegue limpar o respectivo ambiente antes de executar a chamada de Process.start(). Se um invasor puder modificar a variável $PATH a fim de que aponte para um binário malicioso chamado update.exe e fazer com que o programa seja executado no ambiente dele, o binário malicioso será carregado ao invés do binário pretendido. Por causa da natureza do aplicativo, ele é executado com os privilégios necessários para realizar operações do sistema, o que significa que, agora, o update.exe do invasor será executado com esses privilégios, possivelmente concedendo a ele controle total sobre o sistema.

Vulnerabilidades de injeção de comandos assumem duas formas:

- Um invasor pode alterar o comando executado pelo programa: o invasor controla explicitamente qual é esse comando.

- Um invasor pode alterar o ambiente no qual o comando é executado: o invasor controla implicitamente o que esse comando significa.

Nesse caso, estamos preocupados principalmente com o primeiro cenário, no qual um invasor controla explicitamente o comando que é executado. Vulnerabilidades de injeção de comandos desse tipo ocorrem quando:

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


2. Os dados fazem parte de uma string que é executada como um comando pelo aplicativo.


3. Ao executar o comando, o aplicativo concede ao invasor um privilégio ou uma capacidade que ele não teria de outra forma.

Exemplo 1: O seguinte programa simples aceita um nome de arquivo como um argumento de linha de comando e exibe o conteúdo desse arquivo de volta para o usuário. O programa é instalado em setuid root porque se destina para uso como uma ferramenta de aprendizagem, para permitir que administradores de sistema em treinamento inspecionem arquivos de sistema com privilégios sem lhes dar a capacidade de modificá-los ou danificar o sistema.

int main(char* argc, char** argv) {
	char cmd[CMD_MAX] = "/usr/bin/cat ";
	strcat(cmd, argv[1]);
	system(cmd);
}

Como o programa é executado com privilégios de root, a chamada para system() também é executada com privilégios de root. Se um usuário especificar um nome de arquivo padrão, a chamada funcionará conforme esperado. No entanto, se um invasor transmitir uma string de caracteres no formato ";rm -rf /", a chamada para system() não conseguirá executar cat devido a uma falta de argumentos e, em seguida, abrirá caminho para excluir recursivamente o conteúdo da partição root.

Exemplo 2: O seguinte código de um programa privilegiado usa a variável de ambiente $APPHOME para determinar o diretório de instalação do aplicativo e, em seguida, executa um script de inicialização nesse diretório.

	...
	char* home=getenv("APPHOME");
	char* cmd=(char*)malloc(strlen(home)+strlen(INITCMD));
	if (cmd) {
		strcpy(cmd,home);
		strcat(cmd,INITCMD);
		execl(cmd, NULL);
	}
	...

Como no Example 1, o código no exemplo permite que um invasor execute comandos arbitrários com o privilégio elevado do aplicativo. Nesse exemplo, o invasor pode modificar a variável de ambiente $APPHOME para especificar um caminho diferente contendo uma versão mal-intencionada de INITCMD. Como o programa não valida o valor lido do ambiente, ao controlar a variável de ambiente, o invasor pode enganar o aplicativo, fazendo com que este execute um código mal-intencionado.

O invasor está usando a variável de ambiente para controlar o comando que o programa invoca e, portanto, o efeito do ambiente é explícito nesse exemplo. Vamos agora voltar nossa atenção para o que pode acontecer quando o invasor consegue mudar a maneira como o comando é interpretado.

Exemplo 3: O código a seguir é proveniente de um utilitário CGI baseado na Web que permite aos usuários alterar suas senhas. O processo de atualização de senha no NIS inclui a execução de make no diretório /var/yp. Observe que, como o programa atualiza registros de senha, ele foi instalado em setuid root.

O programa invoca make da seguinte maneira:

system("cd /var/yp && make &> /dev/null");

Diferentemente dos exemplos anteriores, o comando nesse exemplo está inserido em código fixo para que um invasor não possa controlar o argumento transmitido para system(). No entanto, como o programa não especifica um caminho absoluto para make e não limpa as respectivas variáveis de ambiente antes de invocar o comando, o invasor pode modificar a respectiva variável $PATH de forma que ela aponte para um binário mal-intencionado denominado make e execute o script CGI de um prompt de shell. E, como o programa foi instalado em setuid root, a versão do invasor de make agora é executada com privilégios de root.

No Windows, existem riscos adicionais presentes.

Exemplo 4: Ao invocar CreateProcess() diretamente ou através de uma chamada para uma das funções na família _spawn(), é necessário ter cautela quando existe um espaço em um executável ou caminho.

...
LPTSTR cmdLine = _tcsdup(TEXT("C:\\Program Files\\MyApplication -L -S"));
CreateProcess(NULL, cmdLine, ...);
...

Devido à maneira como CreateProcess() analisa espaços, o primeiro executável que o sistema operacional tentará executar é Program.exe, e não MyApplication.exe. Portanto, se um invasor for capaz de instalar um aplicativo mal-intencionado denominado Program.exe no sistema, qualquer programa que chamar CreateProcess() incorretamente usando o diretório Program Files executará esse aplicativo em vez daquele pretendido.

O ambiente desempenha um papel poderoso na execução de comandos do sistema dentro de programas. Funções como system(), exec() e CreateProcess() usam o ambiente do programa que as chama e, portanto, os invasores têm uma oportunidade potencial para influenciar o comportamento dessas chamadas.

Vulnerabilidades de injeção de comandos assumem duas formas:

- Um invasor pode alterar o comando que o programa executa: o invasor controla explicitamente o comando.

- Um invasor pode controlar os parâmetros do programa.

- Um invasor pode alterar o ambiente no qual o comando é executado: o invasor controla implicitamente o que esse comando significa.

Nesse caso, estamos preocupados principalmente com o segundo cenário, no qual um invasor pode modificar o significado do comando alterando uma variável de ambiente ou inserindo um executável mal-intencionado no início do caminho de pesquisa. Vulnerabilidades de Command injection desse tipo ocorrem quando:

1. Um invasor modifica o ambiente de um aplicativo.

2. O aplicativo executa um comando sem especificar um caminho absoluto ou verificar o binário que está sendo executado.



3. Ao executar o comando, o aplicativo concede ao invasor um privilégio ou uma capacidade que ele não teria de outra forma.

Exemplo 1: Esse exemplo demonstra o que pode acontecer quando o invasor consegue alterar a forma como um comando é interpretado. O código é proveniente de um utilitário CGI baseado na Web que permite aos usuários alterar suas senhas. O processo de atualização de senha no NIS inclui a execução de make no diretório /var/yp. Observe que, como o programa atualiza registros de senha, ele foi instalado em setuid root.

O programa invoca make da seguinte maneira:

MOVE "cd /var/yp && make &> /dev/null" to command-line
CALL "CBL_EXEC_RUN_UNIT" USING command-line
                               length of command-line
                               run-unit-id
                               stack-size
                               flags

O comando nesse exemplo é hardcoded. Portanto, um invasor não pode controlar o argumento passado para CBL_EXEC_RUN_UNIT. No entanto, como o programa não especifica um caminho absoluto para make e não limpa suas variáveis de ambiente antes de invocar o comando, o invasor pode modificar sua variável $PATH para apontar para um binário mal-intencionado chamado make e executar o script CGI por meio de um prompt de shell. Além disso, como o programa foi instalado com setuid root, a versão do invasor de make agora é executada com privilégios de root.

Exemplo 2: O código a seguir usa uma variável de ambiente para determinar o diretório temporário que contém o arquivo a ser impresso com o comando pdfprint.

DISPLAY "TEMP" UPON ENVIRONMENT-NAME
ACCEPT ws-temp-dir FROM ENVIRONMENT-VARIABLE
STRING "pdfprint " DELIMITED SIZE
             ws-temp-dir DELIMITED SPACE
             "/" DELIMITED SIZE
             ws-pdf-filename DELIMITED SPACE
             x"00" DELIMITED SIZE
             INTO cmd-buffer
CALL "SYSTEM" USING cmd-buffer

De maneira semelhante ao exemplo anterior, o comando é hardcoded. No entanto, como o programa não especifica um caminho absoluto para pdfprint, o invasor pode modificar a variável $PATH para apontar para um binário mal-intencionado. Além disso, embora as frases DELIMITED SPACE evitem espaços embutidos em ws-temp-dir e ws-pdf-filename, pode haver metacaracteres de shell (como &&) embutidos em qualquer um deles.

Vulnerabilidades de injeção de comandos assumem duas formas:

- Um invasor pode alterar o comando executado pelo programa: o invasor controla explicitamente qual é esse comando.

- Um invasor pode alterar o ambiente no qual o comando é executado: o invasor controla implicitamente o que esse comando significa.

Nesse caso, estamos preocupados principalmente com o primeiro cenário, com a possibilidade de que um invasor seja capaz de controlar o comando que é executado. Vulnerabilidades de injeção de comandos 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 comando executado pelo aplicativo.

3. Ao executar o comando, 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 permite que um invasor especifique comandos arbitrários através do parâmetro de solicitação cmd.

    ...
<cfset var="#url.cmd#">
<cfexecute name = "C:\windows\System32\cmd.exe"
    arguments = "/c #var#"
    timeout = "1"
    variable="mycmd">
</cfexecute>
    ...

Vulnerabilidades de injeção de comandos assumem duas formas:

- Um invasor pode alterar o comando que o programa executa: o invasor controla explicitamente qual é o comando.

- Um invasor pode alterar o ambiente no qual o comando é executado: o invasor controla implicitamente o que esse comando significa.

Nesse caso, estamos preocupados principalmente com o primeiro cenário, a possibilidade de um invasor controlar o comando executado. Vulnerabilidades de Command injection 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 (ou como parte de) uma string que representa um comando executado pelo aplicativo.

3. Ao executar o comando, 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 de um utilitário do sistema usa a propriedade do sistema APPHOME para determinar o diretório no qual está instalado e, em seguida, executa um script de inicialização com base em um caminho relativo do diretório especificado.

	...
	final cmd = String.fromEnvironment('APPHOME');
    await Process.run(cmd);
	...

O código no Example 1 permite que um invasor execute comandos arbitrários com o privilégio elevado do aplicativo, modificando a propriedade do sistema APPHOME de forma que ela aponte para um caminho diferente contendo uma versão mal-intencionada de INITCMD. Como o programa não valida o valor lido do ambiente, se um invasor puder controlar o valor da propriedade do sistema APPHOME, ele poderá enganar o aplicativo, fazendo com que este execute o código mal-intencionado, e assumir o controle do sistema.

Vulnerabilidades de injeção de comandos assumem duas formas:

- Um invasor pode alterar o comando que o programa executa: o invasor controla explicitamente o comando.

- Um invasor pode alterar o ambiente no qual o comando é executado: o invasor controla implicitamente o que esse comando significa.

Nesse caso, estamos preocupados principalmente com o primeiro cenário, a possibilidade de um invasor controlar o comando executado. Vulnerabilidades de Command injection 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 parte de uma cadeia de caracteres que representa um comando que o aplicativo executa.

3. Ao executar o comando, o aplicativo concede ao invasor um privilégio ou uma capacidade que ele não teria de outra forma.

Exemplo: O código a seguir executa um comando controlado pelo usuário.

  cmdName := request.FormValue("Command")
  c := exec.Command(cmdName)
  c.Run()

Vulnerabilidades de injeção de comandos assumem duas formas:

- Um invasor pode alterar o comando executado pelo programa: o invasor controla explicitamente qual é esse comando.

- Um invasor pode alterar o ambiente no qual o comando é executado: o invasor controla implicitamente o que esse comando significa.

Nesse caso, estamos preocupados principalmente com o primeiro cenário, com a possibilidade de que um invasor seja capaz de controlar o comando que é executado. Vulnerabilidades de injeção de comandos 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 comando executado pelo aplicativo.

3. Ao executar o comando, 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 de um utilitário do sistema usa a propriedade do sistema APPHOME para determinar o diretório no qual ele está instalado e, em seguida, executa um script de inicialização com base em um caminho relativo a partir do diretório especificado.

	...
	String home = System.getProperty("APPHOME");
	String cmd = home + INITCMD;
	java.lang.Runtime.getRuntime().exec(cmd);
	...

O código no Example 1 permite que um invasor execute comandos arbitrários com o privilégio elevado do aplicativo, modificando a propriedade do sistema APPHOME de forma que ela aponte para um caminho diferente contendo uma versão mal-intencionada de INITCMD. Como o programa não valida o valor lido do ambiente, se um invasor puder controlar o valor da propriedade do sistema APPHOME, ele poderá enganar o aplicativo, fazendo com que este execute o código mal-intencionado, e assumir o controle do sistema.

Exemplo 2: O código a seguir é de um aplicativo Web administrativo projetado para permitir que os usuários iniciem um backup de um banco de dados Oracle usando um wrapper de arquivos em lote em torno do utilitário rman e, em seguida, executem um script cleanup.bat para excluir alguns arquivos temporários. O script rmanDB.bat aceita um único parâmetro de linha de comando, que especifica o tipo de backup a ser realizado. Como o acesso ao banco de dados é restrito, o aplicativo executa o backup como um usuário privilegiado.

...
String btype = request.getParameter("backuptype");
String cmd = new String("cmd.exe /K
\"c:\\util\\rmanDB.bat "+btype+"&&c:\\util\\cleanup.bat\"")
System.Runtime.getRuntime().exec(cmd);
...

O problema aqui é que o programa não realiza validações no parâmetro backuptype lido do usuário. Em geral, o módulo da função Runtime.exec() não executará vários comandos, mas, nesse caso, o programa primeiro executa o shell cmd.exe para executar vários comandos com uma única chamada para Runtime.exec(). Uma vez invocado, o shell permitirá a execução de vários comandos separados por dois "Es" comerciais (símbolo &). Se um invasor transmitir uma string no formato "&& del c:\\dbms\\*.*", o aplicativo executará esse comando juntamente com os outros especificados pelo programa. Devido à natureza do aplicativo, ele é executado com os privilégios necessários para interagir com o banco de dados, o que significa que qualquer comando injetado pelo invasor também será executado com esses privilégios.

Exemplo 3: O código a seguir é de um aplicativo Web que fornece aos usuários uma interface através da qual eles podem atualizar suas senhas no sistema. Parte do processo de atualização de senhas em determinados ambientes de rede é executar um comando make no diretório /var/yp.

...
System.Runtime.getRuntime().exec("make");
...

O problema aqui é que o programa não especifica um caminho absoluto para make e não consegue limpar o ambiente antes de executar a chamada para Runtime.exec(). Se um invasor puder modificar a variável $PATH a fim de que aponte para um binário malicioso chamado make e fazer com que o programa seja executado no ambiente dele, o binário malicioso será carregado ao invés do binário pretendido. Por causa da natureza do aplicativo, ele é executado com os privilégios necessários para realizar operações do sistema, o que significa que, agora, o make do invasor será executado com esses privilégios, possivelmente concedendo a ele controle total sobre o sistema.

Algumas pessoas acham que, no mundo móvel, vulnerabilidades clássicas, como injeção de comandos, não fazem sentido -- por que um usuário atacaria ele próprio? No entanto, lembre-se de que a essência das plataformas móveis são aplicativos que são baixados de várias fontes e executados lado a lado no mesmo dispositivo. A probabilidade de execução de um malware junto com um aplicativo de banco é alta, o que exige a expansão da superfície de ataque de aplicativos móveis de forma a incluir comunicações entre processos.

Exemplo 4: O código a seguir lê comandos a serem executados a partir de uma intenção do Android.

...
        String[] cmds = this.getIntent().getStringArrayExtra("commands");
	Process p = Runtime.getRuntime().exec("su");
        DataOutputStream os = new DataOutputStream(p.getOutputStream());
        for (String cmd : cmds) {
        	os.writeBytes(cmd+"\n");
        }
        os.writeBytes("exit\n");
        os.flush();
...

Em um dispositivo root, um aplicativo mal-intencionado pode forçar o aplicativo de uma vítima a executar comandos arbitrários com privilégios de superusuário.

Vulnerabilidades de injeção de comandos assumem duas formas:

- Um invasor pode alterar o comando executado pelo programa: o invasor controla explicitamente qual é esse comando.

- Um invasor pode alterar o ambiente no qual o comando é executado: o invasor controla implicitamente o que esse comando significa.

Nesse caso, estamos preocupados principalmente com o primeiro cenário, com a possibilidade de que um invasor seja capaz de controlar o comando que é executado. Vulnerabilidades de injeção de comandos 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 comando executado pelo aplicativo.

3. Ao executar o comando, o aplicativo concede ao invasor um privilégio ou uma capacidade que ele não teria de outra forma.

Exemplo 1: Este código de um utilitário do sistema usa a variável de ambiente APPHOME para determinar o diretório no qual será instalado e executa um script de inicialização com base em um caminho relativo do diretório especificado.

var cp = require('child_process');
  ...
  var home = process.env('APPHOME');
  var cmd = home + INITCMD;
  child = cp.exec(cmd, function(error, stdout, stderr){
    ...
  });
  ...

O código no Example 1 permite que um invasor execute comandos arbitrários com o privilégio elevado do aplicativo, modificando a propriedade do sistema APPHOME de forma que ela aponte para um caminho diferente contendo uma versão mal-intencionada de INITCMD. Uma vez que o programa não valida o valor lido a partir do ambiente, se um invasor puder controlar o valor da propriedade do sistemaAPPHOME, poderá enganar o aplicativo para que execute o código malicioso e assumir o controle do sistema.

Exemplo 2: Este código é de um aplicativo da Web administrativo projetado para permitir os usuários a iniciar o backup de um banco de dados Oracle usando um wrapper de arquivo em lote no utilitário rman. O script rmanDB.bat aceita um único parâmetro de linha de comando, que especifica o tipo de backup a ser realizado. Como o acesso ao banco de dados é restrito, o aplicativo executa o backup como um usuário privilegiado.

var cp = require('child_process');
var http = require('http');
var url = require('url');

function listener(request, response){
  var btype = url.parse(request.url, true)['query']['backuptype'];
  if (btype !== undefined){
    cmd = "c:\\util\\rmanDB.bat" + btype;
    cp.exec(cmd, function(error, stdout, stderr){
      ...
    });
  }
  ...
}
...
http.createServer(listener).listen(8080);

O problema aqui é que o programa não faz qualquer validação na leitura do parâmetro backuptype a partir do usuário além de verificar a sua existência. Depois que o shell é invocado, ele poderá permitir a execução de vários comandos e, devido à natureza do aplicativo, ele será executado com os privilégios necessários para interagir com o banco de dados: isso significa que, seja lá o que o invasor injetar, será executado com os mesmos privilégios.

Exemplo 3: O código a seguir é de um aplicativo Web que fornece aos usuários uma interface através da qual eles podem atualizar suas senhas no sistema. Parte do processo de atualização de senhas em determinados ambientes de rede é executar um comando make no diretório /var/yp.

...
require('child_process').exec("make", function(error, stdout, stderr){
  ...
});
...

O problema aqui é que o programa não especifica um caminho absoluto para make e não consegue limpar o ambiente antes de executar a chamada de child_process.exec(). Se um invasor puder modificar a variável $PATH a fim de que aponte para um binário malicioso chamado make e fazer com que o programa seja executado no ambiente dele, o binário malicioso será carregado ao invés do binário pretendido. Por causa da natureza do aplicativo, ele é executado com os privilégios necessários para realizar operações do sistema, o que significa que, agora, o make do invasor será executado com esses privilégios, possivelmente concedendo a ele controle total sobre o sistema.

Vulnerabilidades de injeção de comandos assumem duas formas:

- Um invasor pode alterar o comando executado pelo programa: o invasor controla explicitamente qual é esse comando.

- Um invasor pode alterar o ambiente no qual o comando é executado: o invasor controla implicitamente o que esse comando significa.

Nesse caso, estamos preocupados principalmente com o primeiro cenário, com a possibilidade de que um invasor seja capaz de controlar o comando que é executado. Vulnerabilidades de injeção de comandos 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 comando executado pelo aplicativo.

3. Ao executar o comando, 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 de um utilitário do sistema usa a propriedade do sistema APPHOME para determinar o diretório no qual ele está instalado e, em seguida, executa um script de inicialização com base em um caminho relativo a partir do diretório especificado.

	...
	$home = $_ENV['APPHOME'];
	$cmd = $home . $INITCMD;
	system(cmd);
	...

O código no Example 1 permite que um invasor execute comandos arbitrários com o privilégio elevado do aplicativo, modificando a propriedade do sistema APPHOME de forma que ela aponte para um caminho diferente contendo uma versão mal-intencionada de INITCMD. Como o programa não valida o valor lido do ambiente, se um invasor puder controlar o valor da propriedade do sistema APPHOME, ele poderá enganar o aplicativo, fazendo com que este execute o código mal-intencionado, e assumir o controle do sistema.

Exemplo 2: O código a seguir é de um aplicativo Web administrativo projetado para permitir que os usuários iniciem um backup de um banco de dados Oracle usando um wrapper de arquivos em lote em torno do utilitário rman e, em seguida, executem um script cleanup.bat para excluir alguns arquivos temporários. O script rmanDB.bat aceita um único parâmetro de linha de comando, que especifica o tipo de backup a ser realizado. Como o acesso ao banco de dados é restrito, o aplicativo executa o backup como um usuário privilegiado.

...
$btype = $_GET['backuptype'];
$cmd = "cmd.exe /K \"c:\\util\\rmanDB.bat " . $btype . "&&c:\\util\\cleanup.bat\"";
system(cmd);
...

O problema aqui é que o programa não realiza validações no parâmetro backuptype lido do usuário. Em geral, o módulo da função Runtime.exec() não executará vários comandos, mas, nesse caso, o programa primeiro executa o shell cmd.exe para executar vários comandos com uma única chamada para Runtime.exec(). Uma vez invocado, o shell permitirá a execução de vários comandos separados por dois "Es" comerciais (símbolo &). Se um invasor transmitir uma string no formato "&& del c:\\dbms\\*.*", o aplicativo executará esse comando juntamente com os outros especificados pelo programa. Devido à natureza do aplicativo, ele é executado com os privilégios necessários para interagir com o banco de dados, o que significa que qualquer comando injetado pelo invasor também será executado com esses privilégios.

Exemplo 3: O código a seguir é de um aplicativo Web que fornece aos usuários uma interface através da qual eles podem atualizar suas senhas no sistema. Parte do processo de atualização de senhas em determinados ambientes de rede é executar um comando make no diretório /var/yp.

...
$result = shell_exec("make");
...

O problema aqui é que o programa não especifica um caminho absoluto para make e não consegue limpar o ambiente antes de executar a chamada para Runtime.exec(). Se um invasor puder modificar a variável $PATH a fim de que aponte para um binário malicioso chamado make e fazer com que o programa seja executado no ambiente dele, o binário malicioso será carregado ao invés do binário pretendido. Por causa da natureza do aplicativo, ele é executado com os privilégios necessários para realizar operações do sistema, o que significa que, agora, o make do invasor será executado com esses privilégios, possivelmente concedendo a ele controle total sobre o sistema.

Vulnerabilidades de injeção de comandos assumem duas formas:

- Um invasor pode alterar o comando executado pelo programa: o invasor controla explicitamente qual é esse comando.

- Um invasor pode alterar o ambiente no qual o comando é executado: o invasor controla implicitamente o que esse comando significa.

Nesse caso, estamos preocupados principalmente com o primeiro cenário, com a possibilidade de que um invasor seja capaz de controlar o comando que é executado. Vulnerabilidades de injeção de comandos 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 comando executado pelo aplicativo.

3. Ao executar o comando, o aplicativo concede ao invasor um privilégio ou uma capacidade que ele não teria de outra forma.

Exemplo: O código a seguir define um procedimento armazenado T-SQL que, ao ser chamado com dados não confiáveis, executará um comando do sistema controlado por um invasor.

...
CREATE PROCEDURE dbo.listFiles (@path NVARCHAR(200))
AS

DECLARE @cmd NVARCHAR(500)
SET @cmd = 'dir ' + @path

exec xp_cmdshell @cmd

GO
...

Vulnerabilidades de injeção de comandos assumem duas formas:

- Um invasor pode alterar o comando executado pelo programa: o invasor controla explicitamente qual é esse comando.

- Um invasor pode alterar o ambiente no qual o comando é executado: o invasor controla implicitamente o que esse comando significa.

Nesse caso, estamos preocupados principalmente com o primeiro cenário, com a possibilidade de que um invasor seja capaz de controlar o comando que é executado. Vulnerabilidades de injeção de comandos 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 comando executado pelo aplicativo.

3. Ao executar o comando, 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 de um utilitário do sistema usa a propriedade do sistema APPHOME para determinar o diretório no qual ele está instalado e, em seguida, executa um script de inicialização com base em um caminho relativo a partir do diretório especificado.

	...
	home = os.getenv('APPHOME')
	cmd = home.join(INITCMD)
	os.system(cmd);
	...

O código no Example 1 permite que um invasor execute comandos arbitrários com o privilégio elevado do aplicativo, modificando a propriedade do sistema APPHOME de forma que ela aponte para um caminho diferente contendo uma versão mal-intencionada de INITCMD. Como o programa não valida o valor lido do ambiente, se um invasor puder controlar o valor da propriedade do sistema APPHOME, ele poderá enganar o aplicativo, fazendo com que este execute o código mal-intencionado, e assumir o controle do sistema.

Exemplo 2: O código a seguir é de um aplicativo Web administrativo projetado para permitir que os usuários iniciem um backup de um banco de dados Oracle usando um wrapper de arquivos em lote em torno do utilitário rman e, em seguida, executem um script cleanup.bat para excluir alguns arquivos temporários. O script rmanDB.bat aceita um único parâmetro de linha de comando, que especifica o tipo de backup a ser realizado. Como o acesso ao banco de dados é restrito, o aplicativo executa o backup como um usuário privilegiado.

...
	btype = req.field('backuptype')
	cmd = "cmd.exe /K \"c:\\util\\rmanDB.bat " + btype + "&&c:\\util\\cleanup.bat\""
	os.system(cmd);
...

O problema aqui é que o programa não realiza validações no parâmetro backuptype lido do usuário. Em geral, o módulo da função Runtime.exec() não executará vários comandos, mas, nesse caso, o programa primeiro executa o shell cmd.exe para executar vários comandos com uma única chamada para Runtime.exec(). Uma vez invocado, o shell permitirá a execução de vários comandos separados por dois "Es" comerciais (símbolo &). Se um invasor transmitir uma string no formato "&& del c:\\dbms\\*.*", o aplicativo executará esse comando juntamente com os outros especificados pelo programa. Devido à natureza do aplicativo, ele é executado com os privilégios necessários para interagir com o banco de dados, o que significa que qualquer comando injetado pelo invasor também será executado com esses privilégios.

Exemplo 3: O código a seguir é de um aplicativo Web que fornece aos usuários uma interface através da qual eles podem atualizar suas senhas no sistema. Parte do processo de atualização de senhas em determinados ambientes de rede é executar um comando make no diretório /var/yp.

...
result = os.system("make");
...

O problema aqui é que o programa não especifica um caminho absoluto para make e não consegue limpar o ambiente antes de executar a chamada para os.system(). Se um invasor puder modificar a variável $PATH a fim de que aponte para um binário malicioso chamado make e fazer com que o programa seja executado no ambiente dele, o binário malicioso será carregado ao invés do binário pretendido. Por causa da natureza do aplicativo, ele é executado com os privilégios necessários para realizar operações do sistema, o que significa que, agora, o make do invasor será executado com esses privilégios, possivelmente concedendo a ele controle total sobre o sistema.

Vulnerabilidades de injeção de comandos assumem duas formas:

- Um invasor pode alterar o comando executado pelo programa: o invasor controla explicitamente qual é esse comando.

- Um invasor pode alterar o ambiente no qual o comando é executado: o invasor controla implicitamente o que esse comando significa.

Nesse caso, estamos preocupados principalmente com o primeiro cenário, com a possibilidade de que um invasor seja capaz de controlar o comando que é executado. Vulnerabilidades de injeção de comandos 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 comando executado pelo aplicativo.

3. Ao executar o comando, 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 de um utilitário do sistema usa a propriedade do sistema APPHOME para determinar o diretório no qual ele está instalado e, em seguida, executa um script de inicialização com base em um caminho relativo a partir do diretório especificado.

...
home = ENV['APPHOME']
cmd = home + INITCMD
Process.spawn(cmd)
...

O código no Example 1 permite que um invasor execute comandos arbitrários com o privilégio elevado do aplicativo, modificando a propriedade do sistema APPHOME de forma que ela aponte para um caminho diferente contendo uma versão mal-intencionada de INITCMD. Como o programa não valida o valor lido do ambiente, se um invasor puder controlar o valor da propriedade do sistema APPHOME, ele poderá enganar o aplicativo, fazendo com que este execute o código mal-intencionado, e assumir o controle do sistema.

Exemplo 2: O código a seguir é de um aplicativo Web administrativo projetado para permitir que os usuários iniciem um backup de um banco de dados Oracle usando um wrapper de arquivos em lote em torno do utilitário rman e, em seguida, executem um script cleanup.bat para excluir alguns arquivos temporários. O script rmanDB.bat aceita um único parâmetro de linha de comando, que especifica o tipo de backup a ser realizado. Como o acesso ao banco de dados é restrito, o aplicativo executa o backup como um usuário privilegiado.

...
btype = req['backuptype']
cmd = "C:\\util\\rmanDB.bat #{btype} &&C:\\util\\cleanup.bat"
spawn(cmd)
...

O problema aqui é que o programa não realiza validações no parâmetro backuptype lido do usuário. Depois que o shell é invocado via Kernel.spawn, ele permitirá a execução de vários comandos separados por dois sinais tipográficos &. Se um invasor transmitir uma string no formato "&& del c:\\dbms\\*.*", o aplicativo executará esse comando juntamente com os outros especificados pelo programa. Devido à natureza do aplicativo, ele é executado com os privilégios necessários para interagir com o banco de dados, o que significa que qualquer comando injetado pelo invasor também será executado com esses privilégios.

Exemplo 3: O código a seguir é de um aplicativo Web que fornece aos usuários uma interface através da qual eles podem atualizar suas senhas no sistema. Parte do processo de atualização de senhas em determinados ambientes de rede é executar um comando make no diretório /var/yp.

...
system("make")
...

O problema aqui é que o programa não especifica um caminho absoluto para make e não consegue limpar o ambiente antes de executar a chamada para Kernel.system(). Se um invasor puder modificar a variável $PATH a fim de que aponte para um binário malicioso chamado make e fazer com que o programa seja executado no ambiente dele, o binário malicioso será carregado ao invés do binário pretendido. Por causa da natureza do aplicativo, ele é executado com os privilégios necessários para realizar operações do sistema, o que significa que, agora, o make do invasor será executado com esses privilégios, possivelmente concedendo a ele controle total sobre o sistema.

Vulnerabilidades de injeção de comandos assumem duas formas:

- Um invasor pode alterar o comando executado pelo programa: o invasor controla explicitamente qual é esse comando.

- Um invasor pode alterar o ambiente no qual o comando é executado: o invasor controla implicitamente o que esse comando significa.

Nesse caso, estamos preocupados principalmente com o primeiro cenário, com a possibilidade de que um invasor seja capaz de controlar o comando que é executado. Vulnerabilidades de injeção de comandos 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 comando executado pelo aplicativo.

3. Ao executar o comando, 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 de um utilitário do sistema usa a propriedade do sistema APPHOME para determinar o diretório no qual ele está instalado e, em seguida, executa um script de inicialização com base em um caminho relativo a partir do diretório especificado.

	...
	Dim cmd
	Dim home

	home = Environ$("AppHome")
	cmd = home & initCmd
	Shell cmd, vbNormalFocus
	...

O código no Example 1 permite que um invasor execute comandos arbitrários com o privilégio elevado do aplicativo, modificando a propriedade do sistema APPHOME de forma que ela aponte para um caminho diferente contendo uma versão mal-intencionada de INITCMD. Como o programa não valida o valor lido do ambiente, se um invasor puder controlar o valor da propriedade do sistema APPHOME, ele poderá enganar o aplicativo, fazendo com que este execute o código mal-intencionado, e assumir o controle do sistema.

Exemplo 2: O código a seguir é de um aplicativo Web administrativo projetado para permitir que os usuários iniciem um backup de um banco de dados Oracle usando um wrapper de arquivos em lote em torno do utilitário rman e, em seguida, executem um script cleanup.bat para excluir alguns arquivos temporários. O script rmanDB.bat aceita um único parâmetro de linha de comando, que especifica o tipo de backup a ser realizado. Como o acesso ao banco de dados é restrito, o aplicativo executa o backup como um usuário privilegiado.

...
btype = Request.Form("backuptype")
cmd = "cmd.exe /K " & Chr(34) & "c:\util\rmanDB.bat " & btype & "&&c:\util\cleanup.bat" & Chr(34) & ";
Shell cmd, vbNormalFocus
...

O problema aqui é que o programa não realiza validações no parâmetro backuptype lido do usuário. Uma vez invocado, o shell permitirá a execução de vários comandos separados por dois "Es" comerciais (símbolo &). Se um invasor transmitir uma string no formato "&& del c:\\dbms\\*.*", o aplicativo executará esse comando juntamente com os outros especificados pelo programa. Devido à natureza do aplicativo, ele é executado com os privilégios necessários para interagir com o banco de dados, o que significa que qualquer comando injetado pelo invasor também será executado com esses privilégios.

Exemplo 3: O código a seguir é de um aplicativo Web que fornece aos usuários uma interface através da qual eles podem atualizar suas senhas no sistema. Parte do processo de atualização de senhas em determinados ambientes de rede é executar um comando make no diretório /var/yp.

...
$result = shell_exec("make");
...

O problema aqui é que o programa não especifica um caminho absoluto para make e não consegue limpar o ambiente antes de executar a chamada para Runtime.exec(). Se um invasor puder modificar a variável $PATH a fim de que aponte para um binário malicioso chamado make e fazer com que o programa seja executado no ambiente dele, o binário malicioso será carregado ao invés do binário pretendido. Por causa da natureza do aplicativo, ele é executado com os privilégios necessários para realizar operações do sistema, o que significa que, agora, o make do invasor será executado com esses privilégios, possivelmente concedendo a ele controle total sobre o sistema.

Os navegadores da Web modernos oferecem suporte a um sinalizador Secure para cada cookie. Se esse sinalizador estiver definido, o navegador apenas enviará o cookie via HTTPS. O envio de cookies por um canal não criptografado pode expô-los a ataques de detecção de rede. O sinalizador seguro ajuda a manter o valor de um cookie confidencial. Isso é especialmente importante quando o cookie contém dados privados ou carrega um identificador de sessão.

Exemplo 1: No exemplo abaixo, um cookie é criado sem definir o parâmetro isSecure como true.

...
Cookie cookie = new Cookie('emailCookie', emailCookie, path, maxAge, false, 'Strict');
...

Se o seu aplicativo usar HTTP e HTTPS, mas não definir o parâmetro isSecure, os cookies enviados durante uma solicitação HTTPS também serão enviados durante as solicitações HTTP subsequentes. O sniffing do tráfego da rede por conexões sem fio não criptografadas é uma tarefa simples para os invasores. O envio de cookies (especialmente aqueles com IDs de sessão) via HTTP pode comprometer o aplicativo.

Os navegadores da Web modernos oferecem suporte a um sinalizador Secure para cada cookie. Se esse sinalizador estiver definido, o navegador apenas enviará o cookie via HTTPS. O envio de cookies através de um canal criptografado pode expô-los a ataques de sniffing de rede e, portanto, o sinalizador "secure" ajuda a manter o valor de um cookie confidencial. Isso é especialmente importante quando o cookie contém dados privados ou carrega um identificador de sessão.

Exemplo: No exemplo a seguir, um cookie é adicionado à resposta sem definir a propriedade Secure.

...
 HttpCookie cookie = new HttpCookie("emailCookie", email);
    Response.AppendCookie(cookie);
...

Se o seu aplicativo usar HTTP e HTTPS, mas não definir o sinalizador Secure, os cookies enviados durante uma solicitação HTTPS também serão enviados durante as solicitações HTTP subsequentes. O sniffing do tráfego de rede por meio de conexões sem fio não criptografadas é uma tarefa simples para os invasores e, portanto, o envio de cookies (especialmente aqueles com IDs de sessão) via HTTP pode comprometer o aplicativo.

Os navegadores da Web modernos oferecem suporte a um sinalizador Secure para cada cookie. Se esse sinalizador estiver definido, o navegador apenas enviará o cookie via HTTPS. O envio de cookies através de um canal criptografado pode expô-los a ataques de sniffing de rede e, portanto, o sinalizador "secure" ajuda a manter o valor de um cookie confidencial. Isso é especialmente importante se o cookie contém dados ou identificadores de sessão privados, ou carrega um token CSRF.
Exemplo 1: O seguinte código adiciona um cookie à resposta sem definir o sinalizador Secure.

cookie := http.Cookie{
  Name:     "emailCookie",
  Value:    email,
}
http.SetCookie(response, &cookie)
...

Se um aplicativo usar HTTP e HTTPS, mas não definir o sinalizador Secure, os cookies enviados durante uma solicitação HTTPS também serão enviados durante as solicitações HTTP subsequentes. Dessa forma, os invasores poderão comprometer o cookie farejando o tráfego de rede não criptografado, o que é particularmente fácil em redes sem fio.

Os navegadores da Web modernos oferecem suporte a um sinalizador Secure para cada cookie. Se esse sinalizador estiver definido, o navegador apenas enviará o cookie via HTTPS. O envio de cookies através de um canal criptografado pode expô-los a ataques de sniffing de rede e, portanto, o sinalizador "secure" ajuda a manter o valor de um cookie confidencial. Isso é especialmente importante quando o cookie contém dados privados ou carrega um identificador de sessão.

Exemplo 1: No exemplo a seguir, o atributo use-secure-cookie permite que o cookie remember-me seja enviado por transporte não criptografado.

	<http auto-config="true">
        ...
        <remember-me use-secure-cookie="false"/>
	</http>

Se o seu aplicativo usar HTTP e HTTPS, mas não definir o sinalizador Secure, os cookies enviados durante uma solicitação HTTPS também serão enviados durante as solicitações HTTP subsequentes. O sniffing do tráfego de rede por meio de conexões sem fio não criptografadas é uma tarefa simples para os invasores e, portanto, o envio de cookies (especialmente aqueles com IDs de sessão) via HTTP pode comprometer o aplicativo.

Os navegadores da Web modernos oferecem suporte a um sinalizador Secure para cada cookie. Se esse sinalizador estiver definido, o navegador apenas enviará o cookie via HTTPS. O envio de cookies através de um canal criptografado pode expô-los a ataques de sniffing de rede e, portanto, o sinalizador "secure" ajuda a manter o valor de um cookie confidencial. Isso é especialmente importante quando o cookie contém dados privados ou carrega um identificador de sessão.
Exemplo 1: No exemplo abaixo, o cookie é adicionado à resposta sem definir a propriedade Secure como true.

  res.cookie('important_cookie', info, {domain: 'secure.example.com', path: '/admin', httpOnly: true, secure: false});

Se o seu aplicativo usar HTTP e HTTPS, mas não definir o sinalizador Secure, os cookies enviados durante uma solicitação HTTPS também serão enviados durante as solicitações HTTP subsequentes. O sniffing do tráfego de rede por meio de conexões sem fio não criptografadas é uma tarefa simples para os invasores e, portanto, o envio de cookies (especialmente aqueles com IDs de sessão) via HTTP pode comprometer o aplicativo.

Os navegadores da Web modernos oferecem suporte a um sinalizador Secure para cada cookie. Se esse sinalizador estiver definido, o navegador apenas enviará o cookie via HTTPS. O envio de cookies através de um canal criptografado pode expô-los a ataques de sniffing de rede e, portanto, o sinalizador "secure" ajuda a manter o valor de um cookie confidencial. Isso é especialmente importante quando o cookie contém dados privados ou carrega um identificador de sessão.
Exemplo 1: No exemplo a seguir, o cookie é adicionado à resposta sem definir o sinalizador Secure.

  ...
  NSDictionary *cookieProperties = [NSDictionary dictionary];
  ...
  NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];
  ...

Se o seu aplicativo usar HTTP e HTTPS, mas não definir o sinalizador Secure, os cookies enviados durante uma solicitação HTTPS também serão enviados durante as solicitações HTTP subsequentes. O sniffing do tráfego de rede por meio de conexões sem fio não criptografadas é uma tarefa simples para os invasores e, portanto, o envio de cookies (especialmente aqueles com IDs de sessão) via HTTP pode comprometer o aplicativo.

Os navegadores da Web modernos oferecem suporte a um sinalizador Secure para cada cookie. Se esse sinalizador estiver definido, o navegador apenas enviará o cookie via HTTPS. O envio de cookies através de um canal criptografado pode expô-los a ataques de sniffing de rede e, portanto, o sinalizador "secure" ajuda a manter o valor de um cookie confidencial. Isso é especialmente importante quando o cookie contém dados privados ou carrega um identificador de sessão.
Exemplo 1: O seguinte código adiciona um cookie à resposta sem definir o sinalizador Secure.

...
setcookie("emailCookie", $email, 0, "/", "www.example.com");
...

Se um aplicativo usar HTTP e HTTPS, mas não definir o sinalizador Secure, os cookies enviados durante uma solicitação HTTPS também serão enviados durante as solicitações HTTP subsequentes. Dessa forma, os invasores poderão comprometer o cookie farejando o tráfego de rede não criptografado, o que é particularmente fácil em redes sem fio.

Os navegadores da Web modernos oferecem suporte a um sinalizador Secure para cada cookie. Se esse sinalizador estiver definido, o navegador apenas enviará o cookie via HTTPS. O envio de cookies através de um canal criptografado pode expô-los a ataques de sniffing de rede e, portanto, o sinalizador "secure" ajuda a manter o valor de um cookie confidencial. Isso é especialmente importante se o cookie contém dados ou identificadores de sessão privados, ou carrega um token CSRF.
Exemplo 1: O seguinte código adiciona um cookie à resposta sem definir o sinalizador Secure.

from django.http.response import HttpResponse
...
def view_method(request):
  res = HttpResponse()
  res.set_cookie("emailCookie", email)
  return res
...

Se um aplicativo usar HTTP e HTTPS, mas não definir o sinalizador Secure, os cookies enviados durante uma solicitação HTTPS também serão enviados durante as solicitações HTTP subsequentes. Dessa forma, os invasores poderão comprometer o cookie farejando o tráfego de rede não criptografado, o que é particularmente fácil em redes sem fio.

Os navegadores da Web modernos oferecem suporte a um sinalizador Secure para cada cookie. Se esse sinalizador estiver definido, o navegador apenas enviará o cookie via HTTPS. O envio de cookies através de um canal criptografado pode expô-los a ataques de sniffing de rede e, portanto, o sinalizador "secure" ajuda a manter o valor de um cookie confidencial. Isso é especialmente importante quando o cookie contém dados privados ou carrega um identificador de sessão.
Exemplo 1: No exemplo a seguir, o cookie é adicionado à resposta sem definir o sinalizador Secure.

...
let properties = [
    NSHTTPCookieDomain: "www.example.com",
    NSHTTPCookiePath: "/service",
    NSHTTPCookieName: "foo",
    NSHTTPCookieValue: "bar"
]
let cookie : NSHTTPCookie? = NSHTTPCookie(properties:properties)
...

Se o seu aplicativo usar HTTP e HTTPS, mas não definir o sinalizador Secure, os cookies enviados durante uma solicitação HTTPS também serão enviados durante as solicitações HTTP subsequentes. O sniffing do tráfego de rede por meio de conexões sem fio não criptografadas é uma tarefa simples para os invasores e, portanto, o envio de cookies (especialmente aqueles com IDs de sessão) via HTTP pode comprometer o aplicativo.

Os principais navegadores são compatíveis com a propriedade de cookie HttpOnly, a qual impede que scripts do lado do cliente acessem o cookie. Ataques de Cross-Site Scripting muitas vezes acessam cookies em uma tentativa de roubar identificadores de sessão ou tokens de autenticação. Sem HttpOnly habilitado, os invasores podem acessar cookies de usuário com mais facilidade.
Exemplo 1: O código a seguir cria um cookie sem definir a propriedade HttpOnly.

    HttpCookie cookie = new HttpCookie("emailCookie", email);
    Response.AppendCookie(cookie);

Os navegadores dão suporte à propriedade de cookie HttpOnly, a qual impede que scripts do lado do cliente acessem o cookie. Ataques de criação de script entre sites muitas vezes acessam cookies em uma tentativa de roubar identificadores de sessão ou tokens de autenticação. Com HttpOnly desativado, os invasores têm acesso mais fácil aos cookies do usuário.
Exemplo 1: O código a seguir cria um cookie sem definir a propriedade HttpOnly.

cookie := http.Cookie{
  Name:     "emailCookie",
  Value:    email,
}
...

Os principais navegadores são compatíveis com a propriedade de cookie HttpOnly, a qual impede que scripts do lado do cliente acessem o cookie. Ataques de Cross-Site Scripting muitas vezes acessam cookies em uma tentativa de roubar identificadores de sessão ou tokens de autenticação. Sem HttpOnly habilitado, os invasores podem acessar cookies de usuário com mais facilidade.
Exemplo 1: O código a seguir cria um cookie sem definir a propriedade HttpOnly.

javax.servlet.http.Cookie cookie = new javax.servlet.http.Cookie("emailCookie", email);
// Missing a call to: cookie.setHttpOnly(true);

Os principais navegadores são compatíveis com a propriedade de cookie HttpOnly, a qual impede que scripts do lado do cliente acessem o cookie. Ataques de Cross-Site Scripting muitas vezes acessam cookies em uma tentativa de roubar identificadores de sessão ou tokens de autenticação. Sem HttpOnly habilitado, os invasores podem acessar cookies de usuário com mais facilidade.
Exemplo 1: O código a seguir cria um cookie sem definir a propriedade httpOnly.

  res.cookie('important_cookie', info, {domain: 'secure.example.com', path: '/admin'});

Os principais navegadores são compatíveis com a propriedade de cookie HttpOnly, a qual impede que scripts do lado do cliente acessem o cookie. Ataques de Cross-Site Scripting muitas vezes acessam cookies em uma tentativa de roubar identificadores de sessão ou tokens de autenticação. Sem HttpOnly habilitado, os invasores podem acessar cookies de usuário com mais facilidade.
Exemplo 1: O código a seguir cria um cookie sem definir a propriedade HttpOnly.

setcookie("emailCookie", $email, 0, "/", "www.example.com", TRUE);  //Missing 7th parameter to set HttpOnly

Os navegadores são compatíveis com a propriedade de cookie HttpOnly, a qual impede que scripts do lado do cliente acessem o cookie. Ataques de Cross-Site Scripting muitas vezes acessam cookies em uma tentativa de roubar identificadores de sessão ou tokens de autenticação. Sem HttpOnly habilitado, os invasores podem acessar cookies de usuário com mais facilidade.
Exemplo 1: O código a seguir cria um cookie sem definir a propriedade HttpOnly.

from django.http.response import HttpResponse
...
def view_method(request):
  res = HttpResponse()
  res.set_cookie("emailCookie", email)
  return res
...

Os desenvolvedores muitas vezes definem cookies para serem ativos em um domínio base, como ".example.com". Isso expõe o cookie a todos os aplicativos Web no domínio base e em quaisquer subdomínios. Como cookies frequentemente contêm informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro.

Exemplo:
Imagine que você tenha um aplicativo seguro implantado em http://secure.example.com/ e esse aplicativo defina uma ID de cookie de sessão com o domínio ".example.com" quando um usuário faz login.

Por exemplo:

  HttpCookie cookie = new HttpCookie("sessionID", sessionID);
  cookie.Domain = ".example.com";

Suponha que você tenha outro aplicativo menos seguro em http://insecure.example.com/ e ele contenha uma vulnerabilidade de criação de scripts entre sites. Qualquer usuário autenticado em http://secure.example.com que navegar até http://insecure.example.com correrá o risco de expor seu cookie de sessão de http://secure.example.com.

Além de lerem um cookie, talvez os invasores consigam realizar um ataque de Envenenamento de Cookie usando insecure.example.com para criar o seu próprio cookie excessivamente amplo que substitui o cookie de secure.example.com.

Os desenvolvedores muitas vezes definem cookies para serem ativos em um domínio base, como ".example.com". Isso expõe o cookie a todos os aplicativos Web no domínio base e em quaisquer subdomínios. Como cookies carregam frequentemente informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro aplicativo.

Exemplo 1: Imagine que você tenha um aplicativo seguro implantado em http://secure.example.com/ e esse aplicativo defina uma ID de cookie de sessão com o domínio ".example.com" quando um usuário faz logon.

Por exemplo:

cookie := http.Cookie{
  Name:       "sessionID",
  Value:      getSessionID(),
  Domain:     ".example.com",
}
...

Suponha que você tenha outro aplicativo menos seguro em http://insecure.example.com/ e ele contenha uma vulnerabilidade de cross-site scripting. Qualquer usuário autenticado em http://secure.example.com que navegar até http://insecure.example.com correrá o risco de expor seu cookie de sessão de http://secure.example.com.

Além de ler um cookie, os invasores podem executar um "ataque de envenenamento de cookie" usando insecure.example.com para criar seu próprio cookie excessivamente amplo que substitui o cookie em Secure.example.com.

Os desenvolvedores muitas vezes definem cookies para serem ativos em um domínio base, como ".example.com". Isso expõe o cookie a todos os aplicativos Web no domínio base e em quaisquer subdomínios. Como cookies frequentemente contêm informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro.

Exemplo 1:
Imagine que você tenha um aplicativo seguro implantado em http://secure.example.com/ e esse aplicativo defina uma ID de cookie de sessão com o domínio ".example.com" quando um usuário faz login.

Por exemplo:

  Cookie cookie = new Cookie("sessionID", sessionID);
  cookie.setDomain(".example.com");

Suponha que você tenha outro aplicativo menos seguro em http://insecure.example.com/ e ele contenha uma vulnerabilidade de criação de scripts entre sites. Qualquer usuário autenticado em http://secure.example.com que navegar até http://insecure.example.com correrá o risco de expor seu cookie de sessão de http://secure.example.com.

Além de lerem um cookie, talvez os invasores consigam realizar um ataque de Envenenamento de Cookie usando insecure.example.com para criar o seu próprio cookie excessivamente amplo que substitui o cookie de secure.example.com.

Os desenvolvedores muitas vezes definem cookies para serem ativos em um domínio base, como ".example.com". Isso expõe o cookie a todos os aplicativos Web no domínio base e em quaisquer subdomínios. Como cookies frequentemente contêm informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro.

Exemplo 1:
Imagine que você tenha um aplicativo seguro implantado em http://secure.example.com/ e esse aplicativo defina um cookie de ID de sessão com o domínio ".example.com" quando um usuário faz login.

Por exemplo:

  cookie_options = {};
  cookie_options.domain = '.example.com';
  ...
  res.cookie('important_cookie', info, cookie_options);

Suponha que você tenha outro aplicativo menos seguro em http://insecure.example.com/ e ele contenha uma vulnerabilidade de criação de scripts entre sites. Qualquer usuário autenticado em http://secure.example.com que navegar até http://insecure.example.com correrá o risco de expor seu cookie de sessão de http://secure.example.com.

Além de lerem um cookie, talvez os invasores consigam realizar um ataque de Envenenamento de Cookie usando insecure.example.com para criar o seu próprio cookie excessivamente amplo que substitui o cookie de secure.example.com.

Os desenvolvedores muitas vezes definem cookies para serem ativos em um domínio base, como ".example.com". Isso expõe o cookie a todos os aplicativos Web no domínio base e em quaisquer subdomínios. Como cookies frequentemente contêm informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro.

Exemplo 1:
Imagine que você tenha um aplicativo seguro implantado em http://secure.example.com/ e esse aplicativo defina uma ID de cookie de sessão com o domínio ".example.com" quando um usuário faz login.

Por exemplo:

  ...
  NSDictionary *cookieProperties = [NSDictionary dictionary];
  ...
  [cookieProperties setValue:@".example.com" forKey:NSHTTPCookieDomain];
  ...
  NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];
  ...

Suponha que você tenha outro aplicativo menos seguro em http://insecure.example.com/ e ele contenha uma vulnerabilidade de criação de scripts entre sites. Qualquer usuário autenticado em http://secure.example.com que navegar até http://insecure.example.com correrá o risco de expor seu cookie de sessão de http://secure.example.com.

Além de lerem um cookie, talvez os invasores consigam realizar um ataque de Envenenamento de Cookie usando insecure.example.com para criar o seu próprio cookie excessivamente amplo que substitui o cookie de secure.example.com.

Os desenvolvedores muitas vezes definem cookies para serem ativos em um domínio base, como ".example.com". Isso expõe o cookie a todos os aplicativos Web no domínio base e em quaisquer subdomínios. Como cookies frequentemente contêm informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro.

Exemplo 1:
Imagine que você tenha um aplicativo seguro implantado em http://secure.example.com/ e esse aplicativo defina uma ID de cookie de sessão com o domínio ".example.com" quando um usuário faz login.

Por exemplo:

setcookie("mySessionId", getSessionID(), 0, "/", ".example.com", true, true);

Suponha que você tenha outro aplicativo menos seguro em http://insecure.example.com/ e ele contenha uma vulnerabilidade de criação de scripts entre sites. Qualquer usuário autenticado em http://secure.example.com que navegar até http://insecure.example.com correrá o risco de expor seu cookie de sessão de http://secure.example.com.

Além de lerem um cookie, talvez os invasores consigam realizar um ataque de Envenenamento de Cookie usando insecure.example.com para criar o seu próprio cookie excessivamente amplo que substitui o cookie de secure.example.com.

Os desenvolvedores muitas vezes definem cookies para serem ativos em um domínio base, como ".example.com". Isso expõe o cookie a todos os aplicativos Web no domínio base e em quaisquer subdomínios. Como cookies frequentemente contêm informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro.

Exemplo 1: Imagine que você tenha um aplicativo seguro implantado em http://secure.example.com/ e esse aplicativo defina uma ID de cookie de sessão com o domínio ".example.com" quando um usuário faz login.

Por exemplo:

from django.http.response import HttpResponse
...
def view_method(request):
  res = HttpResponse()
  res.set_cookie("mySessionId", getSessionID(), domain=".example.com")
  return res
...

Suponha que você tenha outro aplicativo menos seguro em http://insecure.example.com/ e ele contenha uma vulnerabilidade de criação de scripts entre sites. Qualquer usuário autenticado em http://secure.example.com que navegar até http://insecure.example.com correrá o risco de expor seu cookie de sessão de http://secure.example.com.

Além de ler um cookie, pode ser possível aos invasores realizar um "ataque de envenenamento de cookie" usando insecure.example.com para criar o cookie próprio e excessivamente amplo que substitui o cookie secure.example.com.

Os desenvolvedores muitas vezes definem cookies para serem ativos em um domínio base, como ".example.com". Isso expõe o cookie a todos os aplicativos Web no domínio base e em quaisquer subdomínios. Como cookies frequentemente contêm informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro.

Exemplo 1:
Imagine que você tenha um aplicativo seguro implantado em http://secure.example.com/ e esse aplicativo defina uma ID de cookie de sessão com o domínio ".example.com" quando um usuário faz login.

Por exemplo:

...
let properties = [
    NSHTTPCookieDomain: ".example.com",
    NSHTTPCookiePath: "/service",
    NSHTTPCookieName: "foo",
    NSHTTPCookieValue: "bar",
    NSHTTPCookieSecure: true
]
let cookie : NSHTTPCookie? = NSHTTPCookie(properties:properties)
...

Suponha que você tenha outro aplicativo menos seguro em http://insecure.example.com/ e ele contenha uma vulnerabilidade de criação de scripts entre sites. Qualquer usuário autenticado em http://secure.example.com que navegar até http://insecure.example.com correrá o risco de expor seu cookie de sessão de http://secure.example.com.

Além de lerem um cookie, talvez os invasores consigam realizar um ataque de Envenenamento de Cookie usando insecure.example.com para criar o seu próprio cookie excessivamente amplo que substitui o cookie de secure.example.com.

Os desenvolvedores muitas vezes definem cookies para serem acessíveis no caminho do contexto raiz ("/"). Fazer isso expõe o cookie a todos os aplicativos Web no domínio. Como cookies carregam frequentemente informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro aplicativo.

Exemplo 1:
Imagine que você tenha um aplicativo de fórum implantado em http://communitypages.example.com/MyForum e esse aplicativo defina um cookie de ID de sessão com o caminho "/" quando os usuários fazem login no fórum. Por exemplo:

...
String path = '/';
Cookie cookie = new Cookie('sessionID', sessionID, path, maxAge, true, 'Strict');
...

Suponha que um invasor crie outro aplicativo em http://communitypages.example.com/EvilSite e publique um link para esse site no fórum. Quando um usuário do fórum clicar nesse link, o navegador enviará o cookie definido por /MyForum ao aplicativo em execução em /EvilSite. Roubando a ID de sessão, o invasor pode comprometer a conta de qualquer usuário do fórum que tenha navegado até /EvilSite.

Além de lerem um cookie, talvez os invasores consigam realizar um ataque de Envenenamento de Cookie usando /EvilSite para criar o seu próprio cookie excessivamente amplo que substitui o cookie de /MyForum.

Os desenvolvedores muitas vezes definem cookies para serem o caminho do contexto raiz "/". No entanto, fazer isso expõe o cookie a todos os aplicativos Web no mesmo nome de domínio. Como cookies frequentemente contêm informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro.

Exemplo:
Imagine que você tenha um aplicativo de fórum implantado em http://communitypages.example.com/MyForum e esse aplicativo defina um cookie de ID de sessão com o caminho "/" quando os usuários fazem login no fórum.

Por exemplo:

  HttpCookie cookie = new HttpCookie("sessionID", sessionID);
  cookie.Path = "/";

Suponha que um invasor crie outro aplicativo em http://communitypages.example.com/EvilSite e publique um link para esse site no fórum. Quando um usuário do fórum clicar nesse link, o navegador enviará o cookie definido por /MyForum ao aplicativo em execução em /EvilSite. Roubando o ID da sessão, o invasor consegue comprometer a conta de qualquer usuário do fórum que tiver navegado até /EvilSite.

Além de lerem um cookie, talvez os invasores consigam realizar um ataque de Envenenamento de Cookie usando /EvilSite para criar o seu próprio cookie excessivamente amplo que substitui o cookie de /MyForum.

Os desenvolvedores muitas vezes definem cookies para serem acessíveis no caminho do contexto raiz ("/"). Fazer isso expõe o cookie a todos os aplicativos Web no domínio. Como cookies carregam frequentemente informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro aplicativo.

Exemplo 1:
Suponha que você tenha um aplicativo de fórum implantado em http://communitypages.example.com/MyForum e esse aplicativo defina um cookie de ID de sessão com o caminho "/" quando os usuários fazem logon no fórum.

Por exemplo:

cookie := http.Cookie{
  Name:    "sessionID",
  Value:   sID,
  Expires: time.Now().AddDate(0, 0, 1),
  Path:    "/",
}
...

Suponha que um invasor crie outro aplicativo em http://communitypages.example.com/EvilSite e publique um link para esse site no fórum. Quando um usuário do fórum clica nesse link, o navegador envia o cookie definido por /MyForum para o aplicativo em execução em /EvilSite. Roubando a ID de sessão, o invasor pode comprometer a conta de qualquer usuário do fórum que tenha navegado até /EvilSite.

Além de ler um cookie, os invasores podem executar um "ataque de envenenamento de cookie" usando /EvilSite para criar seu próprio cookie excessivamente amplo que substitui o cookie em /MyForum.

Os desenvolvedores muitas vezes definem que os cookies sejam acessíveis a partir do caminho do contexto raiz ("/"). Isso expõe o cookie a todos os aplicativos Web no domínio. Como cookies frequentemente contêm informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro.

Exemplo 1:
Imagine que você tenha um aplicativo de fórum implantado em http://communitypages.example.com/MyForum e esse aplicativo defina um cookie de ID de sessão com o caminho "/" quando os usuários fazem login no fórum.

Por exemplo:

  Cookie cookie = new Cookie("sessionID", sessionID);
  cookie.setPath("/");

Suponha que um invasor crie outro aplicativo em http://communitypages.example.com/EvilSite e publique um link para esse site no fórum. Quando um usuário do fórum clicar nesse link, o navegador enviará o cookie definido por /MyForum ao aplicativo em execução em /EvilSite. Roubando o ID da sessão, o invasor consegue comprometer a conta de qualquer usuário do fórum que tiver navegado até /EvilSite.

Além de lerem um cookie, talvez os invasores consigam realizar um ataque de Envenenamento de Cookie usando /EvilSite para criar o seu próprio cookie excessivamente amplo que substitui o cookie de /MyForum.