HTTP é um protocolo “sem estado”. O que significa que não existe um padrão “embutido” para controlar as requests inter-relacionadas. Cada solicitação é tratada como independente. Atualmente, a maioria dos aplicativos da web está usando HTTP 1.1, que foi lançado em 1996. Esses aplicativos da web são muito avançados e geralmente lidam com operações complexas que levam mais de um par de solicitação / resposta para serem concluídas. Isso requer algo para rastrear o estado atual de Operação. Esses aplicativos também apresentam conteúdo personalizado para cada usuário. Isso requer a identificação de um usuário em várias requests. Portanto, deve haver algo que adiciona um “aprimoramento” ao HTTP.
Existem soluções que são o resultado de um pensamento inteligente de programadores da web.

O HTTP usa a arquitetura cliente-servidor e usa o TCP como protocolo de transmissão e várias requests podem ser enviadas em apenas uma conexão TCP, mas também são consideradas independentes pelo cliente e pelo servidor. Existem dois aspectos da sessão em HTTP, conforme discutido acima. Existem basicamente duas maneiras de conseguir o rastreamento entre as requests.

1. Parâmetros de solicitação:
O token que representa o estado atual de um processo de várias etapas ou identifica um usuário pode ser armazenado pelo servidor na página da web em um campo de formulário, que será enviado automaticamente sempre que o usuário executar uma ação. O token está contido como um valor de um campo de entrada. Esse token pode ser enviado como um parâmetro de solicitação GET ou um parâmetro de solicitação POST. Os parâmetros de solicitação em uma solicitação GET são incorporados na URL e são registrados no histórico do navegador. Enquanto o POST envia os parâmetros como corpo da solicitação, de modo que não seja incorporado na URL e também não apareça no histórico do navegador. Obviamente, para enviar informações confidenciais, requests POST devem ser usadas, enquanto requests GET podem ser usadas para informações confidenciais. Por exemplo, se o token for um identificador para um usuário, ele sempre deve ser enviado na solicitação POST.
Existe outra maneira de enviar identificadores em requests GET. Que usa o nome do caminho em vez de parâmetros.

2. Cookies
Cookies são pares de nome-valor que são armazenados no navegador e enviados automaticamente em requests subsequentes. O servidor os gera e os envia ao cliente usando o cabeçalho HTTP “set-cookie”. Um cookie é enviado usando o cabeçalho “cookie”.

O cabeçalho do cookie envia pares nome-valor separados por ponto e vírgula. O cabeçalho set-cookie contém diretivas e parâmetros extras para cookies. Isso ajuda o navegador a entender como e quando enviá-los.
Os parâmetros mais comuns são - domínio, caminho e expira, enquanto as diretivas são - “seguro” e “httponly”. O parâmetro domain especifica o domínio para o qual o cookie é válido, o cookie também será válido para todos os seus subdomínios. O parâmetro path especifica o caminho do URL. Expira é autoexplicativo.
A diretiva “secure” instrui o navegador a enviar o cookie por HTTPS apenas, enquanto “httponly” instrui o navegador a não permitir que o JavaScript do site acesse o cookie. Isso é feito para evitar a exploração de XSS que rouba cookies, caso o site seja vulnerável a XSS.

As
sessões de rastreamento de práticas recomendadas exigem geração, transmissão e armazenamento de tokens confidenciais. Qualquer configuração incorreta em qualquer estágio pode colocar em risco a segurança dos dados dos usuários. Existem alguns pontos que devem ser mantidos em mente ao desenvolver um aplicativo que mantém as sessões do usuário.

• Nunca envie nenhum token por meio de um canal não criptografado (HTTP).
• Invalide tokens no lado do servidor quando o usuário fizer logout, apenas limpar os cookies no navegador do usuário é insuficiente e pode levar ao controle permanente da conta.
• Sempre implemente a proteção CSRF em ações confidenciais que requerem autenticação.
• Nunca envie tokens anti-CSRF em uma solicitação GET (e nem pense em enviar tokens de sessão em uma solicitação GET)
• Sempre use nonce e padding ao gerar tokens confidenciais e evite usar esquemas de codificação reversíveis como Base64.
• Não armazene senhas no servidor em texto simples. Sempre os hash e armazene o hash. Isso protegerá o usuário de um evento infeliz de violação de dados.