Funcionamento

Na resposta a um pedido HTTP, o servidor pode incluir informações80

que vão permitir suprir a falta de estado das ligações HTTP. Fá-lo através da introdução de um cabeçalho set-cookie na resposta HTTP.

78

BARTH, A., HTTP State Management Mechanism, RFC 6265, The Internet Engineering Task Force (IETF), abril

2011, disponível em http://tools.ietf.org/html/rfc6265, última consulta em 4 de novembro de 2012, “This document

specifies the syntax and semantics of these headers as they are actually used on the Internet”, p. 4.

79 _{“The working group must not introduce any new syntax or new semantics not already in common use”, cfr}

descrição do Grupo de Trabalho, disponível em http://datatracker.ietf.org/wg/httpstate/charter/, última consulta em 04

de novembro de 2012.

80 _{Utilizamos, neste primeiro cap tulo, os termos “dados” e “informaç es” indistintamente. Usamos “informaç es”}

para nos referirmos aos dados compreendidos nos testemunhos de conexão por ser essa a terminologia usada nas especificações da IETF.

Na literatura sobre gestão e representação do conhecimento, é comum encontrarmos a distinção entre os conceitos de dados, informação e conhecimento. Os dados serão, então, os elementos mais básicos, os factos em bruto, sem significado, relações ou contexto. Da contextualização – organização – dos dados surge a informação. A informação resulta da interpretação dos factos, que são relacionados entre si de modo a obterem significado. Mais difícil de definir é a noção de conhecimento. O conhecimento é obtido a partir dos dados e da informação. Para uma

26

O cliente recebe esta informação e armazena-a no terminal do

utilizador. Aquando de uma nova ligação ao servidor, reenvia inalterada81 a

informação previamente recebida através da introdução do chamado cabeçalho cookie no seu pedido.

Esta é a descrição básica dos testemunhos de conexão.

Os testemunhos de conexão permitem ao servidor reconhecer o navegador, até que a validade do testemunho expire.

A informação compreendida nos testemunhos de conexão está na discricionariedade do servidor.

Os testemunhos de conexão são simples linhas de texto, legíveis, enviadas pelo servidor ao navegador, no cabeçalho set-cookie da resposta ao pedido HTTP que, uma vez recebidas por um navegador cooperante, são armazenadas como um arquivo de texto por este no terminal do utilizador e, aquando de um novo pedido ao site, são reenviados inalterados, no cabeçalho cookie do pedido HTTP.

Assim, o cabeçalho set-cooki pode ser o seguinte:

Set-Cookie: example = one; path=/; expires Fri, 15-Feb-2013 15:50:00 GMT

O servidor dá, desta forma, ordem ao navegador para armazenar o testemunho e reenviá-lo aquando de uma nova solicitação.

O navegador, cooperante e com permissão para tal, armazena o

testemunho juntamente com os seus atributos, com o nome example, como

um ficheiro de texto numa pasta ou subpasta no terminal do utilizador e, se este não tiver expirado ou sido apagado, reenvia-a na nova solicitação, introduzindo o cabeçalho cookie:

and Knowledge, Journal of the American Society for Information science and Technology, 15 de fevereiro, 2007,

disponível em http://www.success.co.il/is/zins_definitions_dik.pdf, última consulta em 04 de novembro de 2012.

81

Como veremos, ainda sob este título, o cabeçalho cookie é diferente do cabeçalho set-cookie, mas a informação que contém foi a que o site previamente definiu naquele cabeçalho set-cookie.

27

Cookie: example = one

O servidor pode enviar múltiplos cabeçalhos set-cookie na mesma resposta.

Cada cabeçalho set-cookie, por sua vez, conforme explica a

especificação82, compreende obrigatoriamente o atributo nome=valor – no

nosso exemplo, o nome será example e o valor one – seguido de nenhum ou

vários atributos.

Os atributos “data de expiração” (Expires Attribute) e “idade-máxima”

(Max-Age Attribute) indicam a longevidade do testemunho.

O atributo “data de expiração” indica a data em que o testemunho de conexão expira – e é eliminado.

O atributo “idade-máxima” indica, não a data em que o testemunho expira, mas os segundos que faltam até que este expire.

Se ambos os atributos estiverem definidos (“data de expiração” e “idade-máxima”), é o atributo “idade-máxima” que deve prevalecer. Quando nenhum dos dois esteja definido, por defeito o navegador deve apagar o testemunho quando a sessão para que foi gerado expirar.

De todo o modo, o utilizador sempre pode apagar o testemunho de conexão por iniciativa própria, a qualquer momento.

O atributo “dom nio” (Domain Attribute) é particularmente importante

nos casos – tão comuns – em que o site conta com vários servidores para

suportar a sua atividade na rede. Assim, com este atributo o site consegue que o testemunho seja acessível a todas as suas páginas. Se o valor do

atributo domínio for "example.com"83, o navegador vai reenviar o testemunho

num futuro pedido dirigido a “example.com”, “www.example.com” e “www.corp.example.com”.

Se este atributo não for definido, o cliente dele apenas deve reenviar o testemunho aquando de um pedido ao servidor de origem.

82

Cf. BARTH, A., HTTP ... RFC 6265, cit., pp. 10 e ss..

28

Ademais, o servidor que envia o testemunho tem de pertencer ao domínio que define, ou seja, "example.com" não pode enviar um testemunho com o atributo de dom nio definido para “instance.com”.

Testemunhos de conexão que tenham definido unicamente um domínio público (.com ou .pt, por exemplo) são conhecidos por supercookies. Os navegadores estão configurados para bloquear este tipo de testemunhos.

O atributo “caminho” (Path Attribute) define os caminhos (URLs) para os quais o testemunho é válido. Só as páginas compreendidas nos caminhos definidos podem ler o testemunho. Se este atributo não estiver definido, por defeito será somente considerado o URL que enviou o testemunho.

O atributo “segurança” (Secure Attribute) não tem um valor associado. Quando este atributo conste, o testemunho só deve ser enviado através de uma ligação segura. Assim, o testemunho só será usado através de uma ligação HTTPS, que vai garantir que o testemunho (como parte que é da mensagem HTTP) seja transmitido cifrado – e não em claro.

O atributo “HttpOnly”, também, não tem um valor associado84

. Este atributo dá indicação ao navegador de que o testemunho apenas pode ser usado em pedidos HTTP. Deste modo, pretende-se impedir que seja dado acesso ao testemunho às chamadas Interfaces de Programação de

Aplicativos (Application Programming Interface – APIs)85.

84 _{Os atributos “segurança” e “HttpOnly”, por não terem valores associados, são referidos como “bandeiras” (flags).}

85

O Interface de Programação de Aplicativos (API) permite que uma parte de software a correr num terminal utilize a infraestrutura da rede de modo a fazer chegar informação a outra parte de software específica que, por sua vez, corre noutro sistema terminal da rede.

O JavaScript é um exemplo dessas APIs. Trata-se de um script que é executado no lado do cliente, no próprio navegador. O JavaScript tem, geralmente, permissão para aceder aos testemunhos de conexão, a menos que a bandeira HttpOnly esteja definida e, então, impeça este acesso.

O Cross-site scripting (XSS) é um ataque que se serve desta possibilidade de executar linguagens no lado do cliente. Um utilizador mal intencionado pode procura vulnerabilidades num site que lhe permita injetar código que depois vai correr nos navegadores que acederem à ligação do site onde está alojado. O XSS pode, pois, ser utilizado para ganhar acesso ao testemunho de conexão que o site onde o código malicioso está inserido armazenou no terminal do utilizador (vitima do ataque), e que são enviados ao atacante quando o utilizador enviar um novo pedido ao site original. Uma vez que só o site que cria o testemunho é que pode ter acesso a ele (ou o conjunto de sites do mesmo domínio), o atacante precisa de injetar o código malicioso no site que instalou os testemunhos a que pretende aceder.

29 O navegador pode, porém, estar configurado para ignorar

completamente o cabeçalho set-cookie86. Caso contrário, recebido um

cabeçalho set-cookie, o navegador armazena o testemunho no terminal do utilizador como pares atributo-valor.

O espaço de armazenamento disponível para os testemunhos de

conexão não é, geralmente, muito grande. A especificação87 recomenda os

navegadores a fornecer as capacidades de, pelo menos: 4096 bytes por testemunho, 50 testemunhos por domínio e 3000 testemunhos no total.

Cada navegador instalado em cada computador tem a sua área de armazenamento de testemunhos de conexão.

Num novo pedido ao mesmo servidor (ou a domínios pertencentes ao

mesmo servidor) – por exemplo, no pedido de outra página do site – o

navegador envia aquelas informações que recebeu, que vão permitir ao site reconhecer o navegador e associar o presente pedido ao anterior.

As informações são reenviadas pelo navegador ao servidor no cabeçalho cookie. O cliente reenvia ao servidor, apenas, o par nome-valor do testemunho.

Assim, os testemunhos de conexão são:

1) Informações enviadas pelo servidor ao cliente, numa linha de cabeçalho da resposta HTTP,

2) Informações armazenadas pelo cliente no terminal do utilizador como um arquivo de texto

3) E informações que são reenviados pelo cliente, inalterados, ao servidor aquando de um novo pedido.

Mas a tecnologia dos testemunhos de conexão, geralmente, contempla outra componente: uma base de dados do site web.

86

É o que acontece quando são bloqueados por defeito pelo navegador ou por opção do utilizador os testemunhos de terceiros, cf. BARTH, A., HTTP ... RFC 6265, cit., p.17.

30

É comum que os testemunhos de conexão se limitam a fazer o reconhecimento do navegador ou se associam a dados anónimos.

Como tão bem explica Marshall Brain88, os testemunhos de conexão

muitas vezes não são mais do que um número de identificação, gerado aleatoriamente pelo site web.

O espaço de armazenamento disponível para os testemunhos de conexão não é, como vimos, muito grande. Daí tratarem-se de (e serem persistentemente referidos como) “pequenos” ficheiros.

Assim, muitas vezes, recorrendo ao exemplo dos cestos de compras, os produtos selecionados são armazenados numa base de dados do site web

e não no testemunho de conexão, no terminal do utilizador89.