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

  def searchInvoice(value:String) = Action.async { implicit request =>
    val result: Future[Seq[Invoice]] = db.run {
      sql"select * from invoices where id=$value".as[Invoice]
    }
    ...
  }

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 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 1: 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 1: 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 segundo cenário, com a possibilidade de que um invasor seja capaz de modificar o significado do comando alterando uma variável de ambiente ou colocando um executável mal-intencionado no início do caminho de pesquisa. Vulnerabilidades de injeção de comandos 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 sem 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: 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.

def changePassword(username: String, password: String) = Action { request =>
    ...
    s'echo "${password}" | passwd ${username} --stdin'.!
    ...
}

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.

Vulnerabilidades de XSS (Cross-Site Scripting) ocorrem quando:

1. Os dados entram em um aplicativo Web através de uma fonte não confiável. No caso da Persistent (também conhecida como Stored) XSS, a fonte não confiável é tipicamente um banco de dados ou outro repositório de dados back-end. Por outro lado, no caso da Reflected XSS, essa fonte é tipicamente uma solicitação da Web.


2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação.

O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

Exemplo 1: O seguinte segmento de código ABAP consulta um banco de dados em busca de um funcionário com uma determinada ID e imprime o nome do funcionário correspondente.

...
DATA: BEGIN OF itab_employees,
        eid   TYPE employees-itm,
        name  TYPE employees-name,
      END OF itab_employees,
      itab LIKE TABLE OF itab_employees.
...
itab_employees-eid = '...'.
APPEND itab_employees TO itab.

SELECT *
  FROM employees
  INTO CORRESPONDING FIELDS OF TABLE itab_employees
  FOR ALL ENTRIES IN itab
  WHERE eid = itab-eid.
ENDSELECT.
...
response->append_cdata( 'Employee Name: ').
response->append_cdata( itab_employees-name ).
...

Esse código funciona corretamente quando os valores de name apresentam um comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.

Exemplo 2: O seguinte segmento de código ABAP lê uma ID de funcionário, eid, de uma solicitação HTTP e a exibe para o usuário.

...
eid = request->get_form_field( 'eid' ).
...
response->append_cdata( 'Employee ID: ').
response->append_cdata( eid ).
...

Como no Example 1, esse código funcionará corretamente se eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta HTTP.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém digitaria uma URL que provoca a execução de código mal-intencionado em seu próprio computador? O verdadeiro perigo está no fato de que um invasor criará a URL mal-intencionada e depois utilizará truques de email ou engenharia social para atrair as vítimas e convencê-las a visitar um link para essa URL. Quando as vítimas clicarem no link, elas refletirão inadvertidamente o conteúdo mal-intencionado através do aplicativo Web vulnerável de volta a seus próprios computadores. Esse mecanismo de exploração de aplicativos Web é conhecido como XSS Refletida.

Como demonstram os exemplos, as vulnerabilidades de XSS são causadas por um código que inclui dados não validados em uma resposta HTTP. Existem três vetores por meio dos quais um ataque de XSS pode atingir uma vítima:

- Como no Example 1, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.

- Como no Example 2, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.

- Uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.

Vulnerabilidades de XSS (Cross-Site Scripting) ocorrem quando:

1. Os dados entram em um aplicativo Web através de uma fonte não confiável. No caso da Persistent (também conhecida como Stored) XSS, a fonte não confiável é tipicamente um banco de dados ou outro repositório de dados back-end. Por outro lado, no caso da Reflected XSS, essa fonte é tipicamente uma solicitação da Web.


2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação.

O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

Exemplo 1: O seguinte segmento de código ActionScript consulta um banco de dados em busca de um funcionário com uma determinada ID e imprime o nome do funcionário correspondente.

  stmt.sqlConnection = conn;
  stmt.text = "select * from emp where id="+eid;
  stmt.execute();
  var rs:SQLResult = stmt.getResult();
  if (null != rs) {
    var name:String = String(rs.data[0]);
    var display:TextField = new TextField();
    display.htmlText = "Employee Name: " + name;
  }

Esse código funciona corretamente quando os valores de name apresentam um comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.

Exemplo 2: O seguinte segmento de código ActionScript lê uma ID de funcionário, eid, de uma solicitação HTTP e a exibe para o usuário.

var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var eid:String = String(params["eid"]);
...
var display:TextField = new TextField();
display.htmlText = "Employee ID: " + eid;
...

Como no Example 1, esse código funcionará corretamente se eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta HTTP.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém digitaria uma URL que provoca a execução de código mal-intencionado em seu próprio computador? O verdadeiro perigo está no fato de que um invasor criará a URL mal-intencionada e depois utilizará truques de email ou engenharia social para atrair as vítimas e convencê-las a visitar um link para essa URL. Quando as vítimas clicarem no link, elas refletirão inadvertidamente o conteúdo mal-intencionado através do aplicativo Web vulnerável de volta a seus próprios computadores. Esse mecanismo de exploração de aplicativos Web é conhecido como XSS Refletida.

Como demonstram os exemplos, as vulnerabilidades de XSS são causadas por um código que inclui dados não validados em uma resposta HTTP. Existem três vetores por meio dos quais um ataque de XSS pode atingir uma vítima:

- Como no Example 1, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.

- Como no Example 2, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.

- Uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.

Vulnerabilidades de XSS (Cross-Site Scripting) ocorrem quando:

1. Dados entram em um aplicativo Web por meio de uma fonte não confiável. No caso da XSS persistente, uma fonte não confiável é mais frequentemente o resultado de uma consulta de banco de dados e, no caso da XSS Refletida, uma solicitação da Web.

2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação.

O conteúdo mal-intencionado geralmente é um segmento de código JavaScript, mas também pode ser HTML, Flash ou qualquer outro conteúdo ativo que possa ser executado pelo navegador. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

Exemplo 1: O seguinte segmento de código Apex consulta um banco de dados em busca de um nome de contato com um determinado ID e retorna o nome do funcionário correspondente, que mais tarde é impresso pelo código do Visualforce.

...
variable = Database.query('SELECT Name FROM Contact WHERE id = ID');
...

<div onclick="this.innerHTML='Hello {!variable}'">Click me!</div>

Esse código se comporta corretamente quando os valores de name estão bem definidos, assim como caracteres alfanuméricos, mas não faz nada para verificar se há dados mal-intencionados. Mesmo lido do banco de dados, o valor deve ser devidamente validado, pois o conteúdo do banco de dados pode ser proveniente de dados fornecidos pelo usuário. Dessa forma, um invasor pode ter comandos mal-intencionados executados no navegador da Web do usuário, sem a necessidade de interagir com a vítima como na XSS Refletida. Esse tipo de ataque, conhecido como XSS Armazenada (ou Persistente), pode ser muito difícil de detectar, pois os dados são indiretamente fornecidos para a função vulnerável e também têm um impacto maior devido à possibilidade de afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.

Exemplo 2: O seguinte segmento de código do Visualforce lê um parâmetro de solicitação HTTP, username, e o exibe ao usuário.

<script>
document.write('{!$CurrentPage.parameters.username}')
</script>

O código neste exemplo foi concebido para receber apenas texto alfanumérico e exibir esse texto. No entanto, se username contiver metacaracteres ou código-fonte, ele será executado pelo navegador da Web.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém digitaria uma URL que provoca a execução de código mal-intencionado em seu próprio computador? O verdadeiro perigo está no fato de que um invasor criará a URL mal-intencionada e depois utilizará truques de email ou engenharia social para atrair as vítimas e convencê-las a visitar um link para essa URL. Quando as vítimas clicarem no link, elas refletirão inadvertidamente o conteúdo mal-intencionado através do aplicativo Web vulnerável de volta a seus próprios computadores. Esse mecanismo de exploração de aplicativos Web é conhecido como XSS Refletida.

Como demonstram os exemplos, as vulnerabilidades de XSS são causadas por um código que inclui dados não validados em uma resposta HTTP. Existem dois vetores por meio dos quais um ataque de XSS pode ser executado:

- Como no Example 1, o banco de dados ou outro armazenamento de dados pode fornecer dados perigosos ao aplicativo que serão incluídos no conteúdo dinâmico. Do ponto de vista do invasor, o melhor lugar para armazenar conteúdo mal-intencionado é em uma área acessível a todos os usuários, especialmente para aqueles com privilégios elevados, que são mais propensos a lidar com informações confidenciais ou realizar operações críticas.

- Como no Example 2, os dados são lidos na solicitação HTTP e refletidos de volta na resposta HTTP. A XSS Refletida ocorre quando um invasor pode ter conteúdo perigoso distribuído a um aplicativo Web vulnerável e, em seguida, refletido de volta para o usuário e executado por seu navegador. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é postada publicamente ou enviada por email diretamente para a vítima. As URLs criadas dessa forma são a essência de muitos esquemas de phishing, nos quais o invasor convence a vítima a visitar a URL. Depois que o site refletir o conteúdo de volta para o usuário, ele será executado e poderá realizar várias ações, como encaminhar informações confidenciais particulares, executar operações não autorizadas no computador da vítima, etc.

Vulnerabilidades de XSS (Cross-Site Scripting) ocorrem quando:

1. Os dados entram em um aplicativo Web através de uma fonte não confiável. No caso da Persistent (também conhecida como Stored) XSS, a fonte não confiável é tipicamente um banco de dados ou outro repositório de dados back-end. Por outro lado, no caso da Reflected XSS, essa fonte é tipicamente uma solicitação da Web.


2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação.

O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

Exemplo 1: O seguinte Formulário da Web ASP.NET consulta um banco de dados em busca de um funcionário com uma ID de funcionário específica e imprime o nome correspondente a essa ID.

<script runat="server">
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = name;
</script>

Em que EmployeeName é um controle de formulário definido da seguinte maneira:

<form runat="server">
   ...
   <asp:Label id="EmployeeName" runat="server">
   ...
</form>

Exemplo 2: O seguinte segmento de código ASP.NET é funcionalmente equivalente ao Example 1, mas implementa todos os elementos de formulário programaticamente.

protected System.Web.UI.WebControls.Label EmployeeName;
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = name;

Esses exemplos de código funcionam corretamente quando os valores de name apresentam um comportamento satisfatório, mas não fazem nada para impedir explorações na ausência desse comportamento. Esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.

Exemplo 3: O Web Form do ASP.NET a seguir lê um número de ID de funcionário de uma solicitação HTTP e o exibe para o usuário.

<script runat="server">
...
EmployeeID.Text = Login.Text;
...
</script>

Em que Login e EmployeeID são controles de formulário definidos da seguinte maneira:

<form runat="server">
   <asp:TextBox runat="server" id="Login"/>
   ...
   <asp:Label runat="server" id="EmployeeID"/>
</form>

Exemplo 4: O seguinte segmento de código ASP.NET mostra a maneira programática de implementar o Example 3.

protected System.Web.UI.WebControls.TextBox Login;
protected System.Web.UI.WebControls.Label EmployeeID;
...
EmployeeID.Text = Login.Text;

Como no Example 1 e no Example 2, esses exemplos funcionarão corretamente se Login contiver apenas texto alfanumérico padrão. Se Login tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web conforme este exibir a resposta HTTP.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém digitaria uma URL que provoca a execução de código mal-intencionado em seu próprio computador? O verdadeiro perigo está no fato de que um invasor criará a URL mal-intencionada e depois utilizará truques de email ou engenharia social para atrair as vítimas e convencê-las a clicar em um link. Quando as vítimas clicarem no link, elas reproduzirão involuntariamente o conteúdo mal-intencionado por meio do aplicativo Web vulnerável e refletido em seus próprios computadores. Esse mecanismo de exploração de aplicativos Web é conhecido como XSS Refletida.

Como demonstram os exemplos, as vulnerabilidades de XSS são causadas por um código que inclui dados não validados em uma resposta HTTP. Existem três vetores por meio dos quais um ataque de XSS pode atingir uma vítima:

- Como no Example 1 e no Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.

- Como no Example 3 e no Example 4, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.

- Uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.

Várias estruturas da Web modernas fornecem mecanismos para executar a validação de entrada do usuário (incluindo Validação de Solicitação do ASP.NET e WCF). 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. Com a Validação de Solicitações ASP.NET, também fornecemos evidências para quando a validação está explicitamente desabilitada. 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.

Vulnerabilidades de XSS (Cross-Site Scripting) ocorrem quando:

1. Os dados entram em um aplicativo Web através de uma fonte não confiável. No caso da Persistent (também conhecida como Stored) XSS, a fonte não confiável é tipicamente um banco de dados ou outro repositório de dados back-end. Por outro lado, no caso da Reflected XSS, essa fonte é tipicamente uma solicitação da Web.


2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação.

O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

Exemplo 1: O seguinte segmento de código CFML consulta um banco de dados em busca de um funcionário com uma determinada ID e imprime o nome do funcionário correspondente.

 
<cfquery name="matchingEmployees" datasource="cfsnippets">
  SELECT name
  FROM Employees 
  WHERE eid = '#Form.eid#'
</cfquery>
<cfoutput>
Employee Name: #name#
</cfoutput>

O código no exemplo funciona corretamente quando os valores de name apresentam um comportamento satisfatório, mas não faz nada para impedir explorações na ausência desse comportamento. Esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.

Exemplo 2: O seguinte segmento de código CFML lê uma ID de funcionário, eid, de um formulário da Web e a exibe para o usuário.

<cfoutput>
Employee ID: #Form.eid#
</cfoutput>

Como no Example 1, esse código funcionará corretamente se Form.eid contiver apenas texto alfanumérico padrão. Se Form.eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web conforme este exibir a resposta HTTP.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém digitaria uma URL que provoca a execução de código mal-intencionado em seu próprio computador? O verdadeiro perigo está no fato de que um invasor criará a URL mal-intencionada e depois utilizará truques de email ou engenharia social para atrair as vítimas e convencê-las a visitar um link para essa URL. Quando as vítimas clicarem no link, elas refletirão inadvertidamente o conteúdo mal-intencionado através do aplicativo Web vulnerável de volta a seus próprios computadores. Esse mecanismo de exploração de aplicativos Web é conhecido como XSS Refletida.

Como demonstram os exemplos, as vulnerabilidades de XSS são causadas por um código que inclui dados não validados em uma resposta HTTP. Existem três vetores por meio dos quais um ataque de XSS pode atingir uma vítima:

- Como no Example 1, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.

- Como no Example 2, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.

- Uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.

Vulnerabilidades de XSS (criação de script entre sites) ocorrem quando:

1. Os dados entram em um aplicativo Web através de uma fonte não confiável. No caso de XSS refletida, a fonte não confiável é tipicamente uma solicitação da Web, enquanto, no caso de XSS persistente (também conhecida como armazenada), essa fonte é tipicamente um banco de dados ou outro repositório de dados back-end.

2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação.

O conteúdo mal-intencionado enviado ao navegador da Web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo da Web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.


Exemplo 1: O seguinte segmento de código Go lê um nome de usuário, user, de uma solicitação HTTP e o exibe para o usuário.

func someHandler(w http.ResponseWriter, r *http.Request){
  r.parseForm()
  user := r.FormValue("user")
  ...
  fmt.Fprintln(w, "Username is: ", user)
}

O código nesse exemplo funcionará corretamente se user contiver apenas texto alfanumérico padrão. Se user tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web conforme este exibir a resposta HTTP.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém digitaria uma URL que provoca a execução de código mal-intencionado em seu próprio computador? O verdadeiro perigo está no fato de que um invasor criará a URL mal-intencionada e depois utilizará truques de email ou engenharia social para atrair as vítimas e convencê-las a visitar um link para essa URL. Quando as vítimas clicarem no link, elas refletirão inadvertidamente o conteúdo mal-intencionado através do aplicativo Web vulnerável de volta a seus próprios computadores. Esse mecanismo de exploração de aplicativos Web é conhecido como XSS Refletida.

Exemplo 2: O segmento de código Go a seguir consulta um banco de dados em busca de um funcionário com determinada ID e imprime o nome do funcionário correspondente.

func someHandler(w http.ResponseWriter, r *http.Request){
  ...
  row := db.QueryRow("SELECT name FROM users WHERE id =" + userid)
  err := row.Scan(&name)
  ...
  fmt.Fprintln(w, "Username is: ", name)
}

Como no Example 1, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque a indireção causada pelo armazenamento de dados dificulta a identificação da ameaça e aumenta a possibilidade de o ataque afetar vários usuários. O XSS começou dessa forma, com sites que ofereciam um "livro de visitas" aos visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.

Como demonstram os exemplos, as vulnerabilidades de XSS são causadas por um código que inclui dados não validados em uma resposta HTTP. Existem três vetores por meio dos quais um ataque de XSS pode atingir uma vítima:

- Como mostrado no Example 1, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações XSS refletidas ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.

- Como mostrado no Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor poderá executar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais pertencentes ao usuário.

- Uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.

Vulnerabilidades de XSS (Cross-Site Scripting) ocorrem quando:

1. Os dados entram em um aplicativo Web através de uma fonte não confiável. No caso da Persistent (também conhecida como Stored) XSS, a fonte não confiável é tipicamente um banco de dados ou outro repositório de dados back-end. Por outro lado, no caso da Reflected XSS, essa fonte é tipicamente uma solicitação da Web.


2. Os dados são incluídos no conteúdo dinâmico enviado a um usuário da Web sem validação.

O conteúdo mal-intencionado enviado ao navegador web geralmente assume a forma de um segmento JavaScript, mas também pode incluir HTML, Flash ou qualquer outro tipo de código que o navegador executa. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável.

Exemplo 1: O seguinte segmento de código JSP consulta um banco de dados em busca de um funcionário com uma determinada ID e imprime o nome do funcionário correspondente.

<%...
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
   rs.next();
   String name = rs.getString("name");
}
%>

Employee Name: <%= name %>

Esse código funciona corretamente quando os valores de name apresentam um comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.

Exemplo 2: O seguinte segmento de código JSP lê uma ID de funcionário, eid, de uma solicitação HTTP e a exibe para o usuário.

<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>

Como no Example 1, esse código funcionará corretamente se eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta HTTP.

Inicialmente, isso pode não ter muita semelhança com uma vulnerabilidade. Afinal, por que alguém digitaria uma URL que provoca a execução de código mal-intencionado em seu próprio computador? O verdadeiro perigo está no fato de que um invasor criará a URL mal-intencionada e depois utilizará truques de email ou engenharia social para atrair as vítimas e convencê-las a visitar um link para essa URL. Quando as vítimas clicarem no link, elas refletirão inadvertidamente o conteúdo mal-intencionado através do aplicativo Web vulnerável de volta a seus próprios computadores. Esse mecanismo de exploração de aplicativos Web é conhecido como XSS Refletida.

Algumas pessoas acham que, no ambiente móvel, vulnerabilidades clássicas de aplicativos Web, como criação de scripts entre sites, 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 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 3: O código a seguir habilita o JavaScript no WebView do Android (o JavaScript está desabilitado por padrão) e carrega uma página com base no valor recebido de uma intenção do Android.

...
        WebView webview = (WebView) findViewById(R.id.webview);
        webview.getSettings().setJavaScriptEnabled(true);
        String url = this.getIntent().getExtras().getString("url");
        webview.loadUrl(url);
...

Se o valor de url começar com javascript:, o código JavaScript seguinte será executado no contexto da página da Web dentro de WebView.

Como demonstram os exemplos, as vulnerabilidades de XSS são causadas por um código que inclui dados não validados em uma resposta HTTP. Existem três vetores por meio dos quais um ataque de XSS pode atingir uma vítima:

- Como no Example 1, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.

- Como no Example 2, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.

- Como no Example 3, uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.

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.