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 LINQ.
Exemplo 1: O código a seguir usa uma consulta LINQ que procura uma fatura correspondente ao identificador especificado [1]. O identificador é selecionado de uma lista de todas as faturas associadas ao usuário autenticado atual.

...

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

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

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

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


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

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

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

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

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


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

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

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

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

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


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

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

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


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

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

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

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

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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


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

...

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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


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

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

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

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

1. Os dados entram em um programa 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Ok(Html(command)).withCookies(Cookie("sessionID", sessionID, secure = false))

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

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

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

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

Os navegadores anexam cookies automaticamente a cada solicitação HTTP feita ao site que define o cookie. Os cookies podem armazenar dados confidenciais, como ID de sessão e token de autorização ou dados do site que são compartilhados entre diferentes solicitações para o mesmo site durante uma sessão. Um invasor pode realizar um ataque de personificação gerando uma solicitação ao site autenticado de uma página de site de terceiros carregada na máquina cliente porque o navegador anexou automaticamente o cookie à solicitação.

O atributo SameSite limita o escopo do cookie de forma que ele só seja anexado a uma solicitação se ela for gerada do contexto primário ou do mesmo site. Isso ajuda a proteger os cookies contra ataques CSRF (Cross-Site Request Forgery). O atributo SameSite pode ter os três seguintes valores:

- Strict: Quando definido como Strict, os cookies são enviados apenas com as solicitações na navegação de nível superior.
- Lax: Quando definidos como Lax, os cookies são enviados com navegação de nível superior do mesmo host, bem como solicitações GET originadas de sites de terceiros, incluindo aqueles que têm as tags iframe ou href vinculadas ao site host. Se um usuário seguir o link, a solicitação incluirá o cookie.
- None: Os cookies são enviados em todas as solicitações feitas ao site no caminho e no escopo de domínio definidos para o cookie. As solicitações geradas devido ao envio de formulários usando o método POST também podem enviar cookies com solicitação.

Exemplo 1: O código a seguir desabilita o atributo SameSite para cookies de sessão.

    ...
    CookieOptions opt = new CookieOptions()
    {
        SameSite = SameSiteMode.None;
    };
    context.Response.Cookies.Append("name", "Foo", opt);
    ...

Os navegadores anexam cookies automaticamente a cada solicitação HTTP feita ao site que define o cookie. Os cookies podem armazenar dados confidenciais, como ID de sessão e token de autorização ou dados do site que são compartilhados entre diferentes solicitações para o mesmo site durante uma sessão. Um invasor pode realizar um ataque de personificação gerando uma solicitação ao site autenticado de uma página de site de terceiros carregada na máquina cliente porque o navegador anexou automaticamente o cookie à solicitação.

O atributo SameSite limita o escopo do cookie de forma que ele só seja anexado a uma solicitação se ela for gerada do contexto primário ou do mesmo site. Isso ajuda a proteger os cookies contra ataques CSRF (Cross-Site Request Forgery). O atributo SameSite pode ter os três seguintes valores:

- Strict: Quando definido como Strict, os cookies são enviados apenas com as solicitações na navegação de nível superior.
- Lax: Quando definido como Lax, os cookies são enviados com navegação de nível superior do mesmo host, bem como solicitações GET originadas para o host de sites de terceiros. Por exemplo, suponha que haja um site de terceiros que tenha tags iframe ou href para o site host. Se um usuário seguir o link, a solicitação incluirá o cookie.
- None: Os cookies são enviados em todas as solicitações feitas ao site no caminho e no escopo de domínio definidos para o cookie. As solicitações geradas devido ao envio de formulários usando o método POST também podem enviar cookies com a solicitação.

Exemplo 1: O código a seguir desabilita o atributo SameSite para cookies de sessão.

c := &http.Cookie{
  Name: "cookie",
  Value: "samesite-none",
  SameSite: http.SameSiteNoneMode,
}

Os navegadores anexam cookies automaticamente a cada solicitação HTTP feita ao site que define o cookie. Os cookies podem armazenar dados confidenciais, como ID de sessão e token de autorização ou dados do site que são compartilhados entre diferentes solicitações para o mesmo site durante uma sessão. Um invasor pode realizar um ataque de personificação gerando uma solicitação ao site autenticado de uma página de site de terceiros carregada na máquina cliente porque o navegador anexou automaticamente o cookie à solicitação.

O atributo SameSite limita o escopo do cookie de forma que ele só seja anexado a uma solicitação se ela for gerada do contexto primário ou do mesmo site. Isso ajuda a proteger os cookies contra ataques CSRF (Cross-Site Request Forgery). O atributo SameSite pode ter os três seguintes valores:

- Strict: Quando definido como Strict, os cookies são enviados apenas com as solicitações na navegação de nível superior.
- Lax: Quando definidos como Lax, os cookies são enviados com navegação de nível superior do mesmo host, bem como solicitações GET originadas de sites de terceiros, incluindo aqueles que têm as tags iframe ou href vinculadas ao site host. Por exemplo, suponha que haja um site de terceiros que tenha tags iframe ou href para o site host. Se um usuário seguir o link, a solicitação incluirá o cookie.
- None: Os cookies são enviados em todas as solicitações feitas ao site no caminho e no escopo de domínio definidos para o cookie. As solicitações geradas devido ao envio de formulários usando o método POST também podem enviar cookies com a solicitação.

Exemplo 1: O código a seguir desabilita o atributo SameSite para cookies de sessão.

 ResponseCookie cookie = ResponseCookie.from("myCookie", "myCookieValue")
     ...
     .sameSite("None") 
     ...

Os navegadores anexam cookies automaticamente a cada solicitação HTTP feita ao site que define o cookie. Os cookies podem armazenar dados confidenciais, como ID de sessão e token de autorização ou dados do site que são compartilhados entre diferentes solicitações para o mesmo site durante uma sessão. Um invasor pode realizar um ataque de personificação gerando uma solicitação ao site autenticado de uma página de site de terceiros carregada na máquina cliente porque o navegador anexou automaticamente o cookie à solicitação.

O atributo SameSite limita o escopo do cookie de forma que ele só seja anexado a uma solicitação se ela for gerada do contexto primário ou do mesmo site. Isso ajuda a proteger os cookies contra ataques CSRF (Cross-Site Request Forgery). O atributo SameSite pode ter os três seguintes valores:

- Strict: Quando definido como Strict, os cookies são enviados apenas com as solicitações na navegação de nível superior.
- Lax: Quando definidos como Lax, os cookies são enviados com navegação de nível superior do mesmo host, bem como solicitações GET originadas de sites de terceiros, incluindo aqueles que têm as tags iframe ou href vinculadas ao site host. Por exemplo, suponha que haja um site de terceiros que tenha tags iframe ou href para o site host. Se um usuário seguir o link, a solicitação incluirá o cookie.
- None: Os cookies são enviados em todas as solicitações feitas ao site no caminho e no escopo de domínio definidos para o cookie. As solicitações geradas devido ao envio de formulários usando o método POST também podem enviar cookies com a solicitação.

Exemplo 1: O código a seguir desabilita o atributo SameSite para cookies de sessão.

app.get('/', function (req, res) {
    ...
    res.cookie('name', 'Foo', { sameSite: false });
    ...
}

Os navegadores anexam cookies automaticamente a cada solicitação HTTP feita ao site que define o cookie. Os cookies podem armazenar dados confidenciais, como ID de sessão e token de autorização ou dados do site que são compartilhados entre diferentes solicitações para o mesmo site durante uma sessão. Um invasor pode realizar um ataque de personificação gerando uma solicitação ao site autenticado de uma página de site de terceiros carregada na máquina cliente porque o navegador anexou automaticamente o cookie à solicitação.

O atributo SameSite limita o escopo do cookie de forma que ele só seja anexado a uma solicitação se ela for gerada do contexto primário ou do mesmo site. Isso ajuda a proteger os cookies contra ataques CSRF (Cross-Site Request Forgery). O atributo SameSite pode ter os três seguintes valores:

- Strict: Quando definido como Strict, os cookies são enviados apenas com as solicitações na navegação de nível superior.
- Lax: Quando definido como Lax, os cookies são enviados com navegação de nível superior do mesmo host, bem como solicitações GET originadas para o host de sites de terceiros. Por exemplo, suponha que haja um site de terceiros que tenha tags iframe ou href para o site host. Se um usuário seguir o link, a solicitação incluirá o cookie.
- None: Os cookies são enviados em todas as solicitações feitas ao site no caminho e no escopo de domínio definidos para o cookie. As solicitações geradas devido ao envio de formulários usando o método POST também podem enviar cookies com solicitação.

Exemplo 1: O código a seguir desabilita o atributo SameSite para cookies de sessão.

ini_set("session.cookie_samesite", "None");

Os navegadores anexam cookies automaticamente a cada solicitação HTTP feita ao site que define o cookie. Os cookies podem armazenar dados confidenciais, como ID de sessão e token de autorização ou dados do site que são compartilhados entre diferentes solicitações para o mesmo site durante uma sessão. Um invasor pode realizar um ataque de personificação gerando uma solicitação ao site autenticado de uma página de site de terceiros carregada na máquina cliente porque o navegador anexou automaticamente o cookie à solicitação.

O parâmetro samesite limita o escopo do cookie para que ele seja anexado apenas a uma solicitação se a solicitação for gerada do contexto primário ou do mesmo site. Isso ajuda a proteger os cookies contra ataques CSRF (Cross-Site Request Forgery). O parâmetro samesite pode ter os três seguintes valores:

- Strict: Quando definido como Strict, os cookies são enviados apenas com as solicitações na navegação de nível superior.
- Lax: Quando definido como Lax, os cookies são enviados com navegação de nível superior do mesmo host, bem como solicitações GET originadas para o host de sites de terceiros. Por exemplo, suponha que haja um site de terceiros que tenha tags iframe ou href para o site host. Se um usuário seguir o link, a solicitação incluirá o cookie.
- None: Os cookies são enviados em todas as solicitações feitas ao site no caminho e no escopo de domínio definidos para o cookie. As solicitações geradas devido ao envio de formulários usando o método POST também podem enviar cookies com a solicitação.

Exemplo 1: O código a seguir desabilita o atributo SameSite para cookies de sessão.

  response.set_cookie("cookie", value="samesite-none", samesite=None)

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

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

Por exemplo:

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

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

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

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

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

Por exemplo:

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

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

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

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

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

Por exemplo:

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

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

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

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

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

Por exemplo:

  cookie_options = {};
  cookie_options.path = '/';
  ...
  res.cookie('important_cookie', info, cookie_options);

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

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

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

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

Por exemplo:

  ...
  NSDictionary *cookieProperties = [NSDictionary dictionary];
  ...
  [cookieProperties setValue:@"/" forKey:NSHTTPCookiePath];
  ...
  NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];
  ...

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

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

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

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

Por exemplo:

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

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

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

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

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

Por exemplo:

from django.http.response import HttpResponse
...
def view_method(request):
  res = HttpResponse()
  res.set_cookie("sessionid", value)   # Path defaults to "/"
  return res
...

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

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

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

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

Por exemplo:

    Ok(Html(command)).withCookies(Cookie("sessionID", sessionID, path = "/"))

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

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

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

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

Por exemplo:

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

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

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

O atributo SameSite protege cookies contra ataques como CSRF (Cross-Site Request Forgery). Os cookies de sessão representam um usuário para o site para que ele possa executar ações autorizadas. No entanto, o navegador envia automaticamente os cookies com a solicitação e, portanto, os usuários e os sites confiam implicitamente no navegador para autorização. Um invasor pode usar indevidamente essa confiança e fazer uma solicitação ao site em nome do usuário incorporando links no atributo href e src de tags como link e iframe em páginas de sites de terceiros que um invasor controla. Se um invasor conseguir atrair um usuário desavisado para o site de terceiros que ele controla, ele poderá fazer solicitações que incluam automaticamente o cookie de sessão que autoriza o usuário, autorizando efetivamente o invasor como se fosse o usuário.
Defina o valor do atributo SameSite como Strict nos cookies de sessão. Isso restringe o navegador a anexar cookies apenas a solicitações de navegação de nível superior ou originadas do mesmo site. Solicitações originadas de sites de terceiros por meio de links em várias tags, como iframe, img e form, não têm esses cookies e, portanto, evitam que o site execute ações que o usuário possa não ter autorizado.

Exemplo 1: O código a seguir define o valor do atributo SameSite como Lax para cookies de sessão.

    ...
    CookieOptions opt = new CookieOptions()
    {
        SameSite = SameSiteMode.Lax;
    };
    context.Response.Cookies.Append("name", "Foo", opt);
    ...

O atributo SameSite protege cookies contra ataques como CSRF (Cross-Site Request Forgery). Os cookies de sessão representam um usuário para o site para que ele possa executar ações autorizadas. No entanto, o navegador envia automaticamente os cookies com a solicitação e, portanto, os usuários e os sites confiam implicitamente no navegador para autorização. Um invasor pode usar indevidamente essa confiança e fazer uma solicitação ao site em nome do usuário incorporando links no atributo href e src de tags como link e iframe em páginas de sites de terceiros que um invasor controla. Se um invasor conseguir atrair um usuário desavisado para o site de terceiros que ele controla, ele poderá fazer solicitações que incluam automaticamente o cookie de sessão que autoriza o usuário, autorizando efetivamente o invasor como se fosse o usuário.
Defina cookies de sessão com o atributo SameSiteStrictMode para SameSite, o que restringe o navegador a anexar cookies apenas a solicitações de navegação de nível superior ou originadas do mesmo site. Solicitações originadas de sites de terceiros por meio de links em várias tags, como iframe, img e form, não têm esses cookies e, portanto, evitam que o site execute ações que o usuário possa não ter autorizado.

Exemplo 1: O código a seguir habilita SameSiteLaxMode no atributo SameSite para cookies de sessão.

c := &http.Cookie{
  Name: "cookie",
  Value: "samesite-lax",
  SameSite: http.SameSiteLaxMode,
}

O atributo SameSite protege cookies contra ataques como CSRF (Cross-Site Request Forgery). Os cookies de sessão representam um usuário para o site para que ele possa executar ações autorizadas. No entanto, o navegador envia automaticamente os cookies com a solicitação e, portanto, os usuários e os sites confiam implicitamente no navegador para autorização. Um invasor pode usar indevidamente essa confiança e fazer uma solicitação ao site em nome do usuário incorporando links no atributo href e src de tags como link e iframe em páginas de sites de terceiros que um invasor controla. Se um invasor conseguir atrair um usuário desavisado para o site de terceiros que ele controla, ele poderá fazer solicitações que incluam automaticamente o cookie de sessão que autoriza o usuário, autorizando efetivamente o invasor como se fosse o usuário.
Defina o valor do atributo SameSite como Strict nos cookies de sessão. Isso restringe o navegador a anexar cookies apenas a solicitações de navegação de nível superior ou originadas do mesmo site. Solicitações originadas de sites de terceiros por meio de links em várias tags, como iframe, img e form, não têm esses cookies e, portanto, evitam que o site execute ações que o usuário possa não ter autorizado.

Exemplo 1: O código a seguir define o valor do atributo SameSite como Lax para cookies de sessão.

 ResponseCookie cookie = ResponseCookie.from("myCookie", "myCookieValue") 
     ...
     .sameSite("Lax")  
     ...
}

O atributo SameSite protege cookies contra ataques como CSRF (Cross-Site Request Forgery). Os cookies de sessão representam um usuário para o site para que ele possa executar ações autorizadas. No entanto, o navegador envia automaticamente os cookies com a solicitação e, portanto, os usuários e os sites confiam implicitamente no navegador para autorização. Um invasor pode usar indevidamente essa confiança e fazer uma solicitação ao site em nome do usuário incorporando links no atributo href e src de tags como link e iframe em páginas de sites de terceiros que um invasor controla. Se um invasor conseguir atrair um usuário desavisado para o site de terceiros que ele controla, ele poderá fazer solicitações que incluam automaticamente o cookie de sessão que autoriza o usuário, autorizando efetivamente o invasor como se fosse o usuário.
Defina o valor do atributo SameSite como Strict nos cookies de sessão. Isso restringe o navegador a anexar cookies apenas a solicitações de navegação de nível superior ou originadas do mesmo site. Solicitações originadas de sites de terceiros por meio de links em várias tags, como iframe, img e form, não têm esses cookies e, portanto, evitam que o site execute ações que o usuário possa não ter autorizado.

Exemplo 1: O código a seguir define o valor do atributo SameSite como Lax para cookies de sessão.

app.get('/', function (req, res) {
    ...
    res.cookie('name', 'Foo', { sameSite: "Lax" });
    ...
}

O atributo SameSite protege cookies contra ataques como CSRF (Cross-Site Request Forgery). Os cookies de sessão representam um usuário para o site para que ele possa executar ações autorizadas. No entanto, o navegador envia automaticamente os cookies com a solicitação e, portanto, os usuários e os sites confiam implicitamente no navegador para autorização. Um invasor pode usar indevidamente essa confiança e fazer uma solicitação ao site em nome do usuário incorporando links no atributo href e src de tags como link e iframe em páginas de sites de terceiros que um invasor controla. Se um invasor conseguir atrair um usuário desavisado para o site de terceiros que ele controla, ele poderá fazer solicitações que incluam automaticamente o cookie de sessão que autoriza o usuário, autorizando efetivamente o invasor como se fosse o usuário.
Defina cookies de sessão com o atributo Strict para SameSite, o que restringe o navegador a anexar cookies apenas a solicitações de navegação de nível superior ou originadas do mesmo site. Solicitações originadas de sites de terceiros por meio de links em várias tags, como iframe, img e form, não têm esses cookies e, portanto, evitam que o site execute ações que o usuário possa não ter autorizado.

Exemplo 1: O código a seguir habilita o modo Lax no atributo SameSite para cookies de sessão.

ini_set("session.cookie_samesite", "Lax");

O atributo SameSite protege cookies contra ataques como CSRF (Cross-Site Request Forgery). Os cookies de sessão representam um usuário para o site para que ele possa executar ações autorizadas. No entanto, o navegador envia automaticamente os cookies com a solicitação e, portanto, os usuários e os sites confiam implicitamente no navegador para autorização. Um invasor pode usar indevidamente essa confiança e fazer uma solicitação ao site em nome do usuário incorporando links no atributo href e src de tags como link e iframe em páginas de sites de terceiros que um invasor controla. Se um invasor atrair um usuário desavisado para o site de terceiros que ele controla, o invasor poderá fazer solicitações que incluam automaticamente o cookie de sessão com autorização do usuário. Isso efetivamente dá ao invasor acesso com a autorização do usuário.
Defina cookies de sessão como Strict para o parâmetro SameSite, o que restringe o navegador a anexar cookies apenas a solicitações de navegação de nível superior ou originadas do mesmo site. Solicitações originadas de sites de terceiros por meio de links em várias tags, como iframe, img e form, não têm esses cookies e, portanto, evitam que o site execute ações que o usuário possa não ter autorizado.

Exemplo 1: O código a seguir habilita Lax no atributo samesite para cookies de sessão.

  response.set_cookie("cookie", value="samesite-lax", samesite="Lax")