Como o protocolo HTTP não prevê o estabelecimento de sessões (cada requisição é, do ponto de vista do HTTP, independente), as aplicações web são obrigadas a implementar seus próprios mecanismos para manter o estado das sessões dos usuários. Estes mecanismos normalmente envolvem a criação de uma estrutura de dados no servidor para manter os dados relativos às sessões, como identificador do usuário ou o conteúdo de carrinhos de compras.

Alguns frameworks já incluem a criação e manutenção de sessões para os usuários de forma transparente para o programador, como no caso do J2EE e do ASP.NET. Nestes casos, o programador deve apenas se preocupar com a qualidade e segurança dos mecanismos de controle implementados pela infra-estrutura. No caso de servidores de aplicação Java, podem existir algumas opções de configuração que aumentem a segurança do controle de sessões. Por exemplo, no Apache Tomcat as seguintes opções podem ser configuradas no arquivos server.xml para aumentar a segurança do servidor:

1. checkSSLSessionId: indica que o servidor deve validar o identificador de sessão gerado pelo Tomcat contra o identificador da sessão SSL. Isto garante que, mesmo que o cookie com o identificador de sessão seja copiado, a sessão não poderá ser usada, já que a sessão SSL não será a mesma.
2. secureCookie: indica que o cookie de identificação de sessão deverá ser marcado como secure e que o browser do usuários somente deverá transmití-lo em conexões SSL, garantindo a sua confidencialidade.
   

Nos casos em que o controle de sessão deva ser implementado na aplicação, os meios mais comuns são a utilização de identificadores como parâmetros nas URLs ou em cookies. Nestes casos, a aplicação recebe o identificador a cada requisição feita pelo browser do cliente e consegue associar cada requisição a uma sessão específica. Quando a aplicação tiver de implementar seu próprio mecanismo de controle de sessão, devem ser tomados os seguintes cuidados:

1. Usar identificadores com alta entropia (pelo menos 32 bits). Isto é possível pelo uso de bons geradores de sequências pseudo-aleatórias, como o java.security.SecureRandom. Veja também o item Usar mecanismos criptográficos adequados. Isto dificulta ataques de adivinhação de identificadores, onde o atacante tenta diversas possibilidades até encontrar um identificador válido.
   
2. Sempre transmitir os identificadores em canais seguros, de preferência utilizando o protocolo SSL (Ver também o item Usar sockets com criptografia SSL). Isto evita que os identificadores sejam capturados durante transmissões na rede. Se a aplicação tiver funcionalidades acessíveis sem SSL, deve ser gerado um novo identificador de sessão quando for iniciada a sessão SSL, conforme descrito no item Criar nova sessão após a autenticação do usuário.
   
3. Verificar os identificadores da sessão SSL em conjunto com os identificadores da sessão do usuário para dificultar ataques de sequestro de sessão. A aplicação deve garantir que um identificador de sessão sempre é transmitido na mesma sessão SSL.
   
4. Definir na aplicação um período de validade e um tempo máximo de inatividade para as sessões. Isto diminui a possibilidade de abuso em caso de escuta do identificador de sessão em trânsito (período de validade) e diminui os riscos de abuso se o usuário deixar de fechar a sessão após o uso da aplicação (tempo de inatividade).
   
5. Implementar um mecanismo de cancelamento de sessões (logout). Isto permite que o usuário invalide a sessão quando terminar de usar a aplicação e evita que a sessão fique disponível se o usuário deixar de usar o computador.
6. Implementar mecanismos de detecção de ataques de força bruta contra os identificadores de sessão, evitando que um adversário teste diversos valores até encontrar um identificador de sessão válido.
7. Nunca incluir os identificadores de sessão na URL, para evitar ataques de session fixation, conforme descrito no item Criar nova sessão após a autenticação do usuário.
   

Nos casos em que são utilizados cookies para o controle de sessão, os seguintes cuidados adicionais deve ser tomados:

1. usar a flag secure: isto indica ao browser que o cookie comente deve ser transmitido por conexões SSL (ver item 2 acima).
   
2. especificar domain: especificar corretamente o domínio (o nome do servidor, preferencialmente) para o qual o cookie deve ser usado. Isto indica para o browser que o cookie somente deve ser enviado para servidores que correspondam ao domínio indicado.
   
3. usar flag httpOnly: impede o uso do cookie por scripts, evitando ataques de cross-site scripting (ver item Proteger a aplicação web contra cross site scripting). Esta funcionalidade está implementada apenas em alguns browsers mais recentes. Alguns servidores de aplicação (Apache Tomcat por exemplo) já estão prevendo a implementação do httpOnly para seus cookies de sessão em futuras versões.
   
4. usar cookies não-persistentes: quando um cookie não tem uma data de expiração definida, este será considerado não-persistente. Neste caso, o browser não armazenará o cookie em disco, mantendo-o somente em memória. O conteúdo do cookie será descartado quando o browser for fechado.

Fontes:

PALMER, Chris. Secure Session Management With Cookies for Web Applications. iSEC Partners, Inc - Sep 2008: http://www.isecpartners.com/files/web-session-management.pdf
OLLMAN, Gunter. Web Based Session Management: Best practices in managing HTTP-based client sessions: http://www.technicalinfo.net/papers/WebBasedSessionManagement.html
OWASP. A Guide to Building Secure Web Applications. Sep 2002: http://www.cgisecurity.com/owasp/html/index.html
DARBIRSIAGHI, Arshan. Google inurl: still the quickest way to find 216 million flaws. Jan 2009: http://i8jesus.com/?p=29