Quando navegadores como IE 11, Firefox 26, Chrome 32 etc. recebem um cookie por uma conexão insegura (HTTP) com o atributo "Seguro" especificado, eles armazenam o cookie e o enviam de volta quando fazem uma solicitação ao mesmo servidor. uma conexão segura (HTTPS).

Embora isso provavelmente esteja de acordo com algumas especificações (acho que os cookies do Netscape), pergunto-me se isso abre uma brecha de segurança adicional (Session Fixation) para sites protegidos por SSL.

Considere o seguinte cenário:

Um usuário (com um dispositivo cliente limpo / livre de malware) deseja acessar um site que possui um nome de usuário + senha de acesso, em uma rede não segura (por exemplo, ponto de acesso WiFi não criptografado), em que um invasor pode ler e modificar todos os dados enviados por aquele rede. Deixe o nome DNS do site serwww.example.com.

O usuário sabe que, quando este site solicitar que ele digite uma senha, verifique sempre se a barra de endereços do navegador contém o ícone de bloqueio SSL antes de inserir a senha.

O site:

fornece acesso a todas as suas páginas e recursos através de SSL / TLS. Isso significa que, uma vez que o usuário visita uma página usando https, todos os links internos dessa página são links https, para que eles não "façam o downgrade" da conexão de HTTPS para HTTP. Além disso, ele não contém nenhum conteúdo misto (HTTP / HTTPS).redireciona o usuário de HTTP para HTTPS com um código de status 301 se um usuário acessar uma de suas páginas por HTTP.armazena informações de login em um cookie de sessão.garante que todos os cookies (incluindo o cookie de sessão) enviados ao cliente sejam enviados apenas por uma conexão segura (HTTPS) e que eles sempre definam os atributos "Seguro" e "HttpOnly".aceita apenas identificadores de sessão que foram gerados pelo site e enviados pelo cliente através de um cookie com o atributo "Seguro" definido (o site não aceita identificadores de sessão de URLs etc.)é protegido contra CSRF, definindo um token específico do usuário em formulários HTML que é verificado pelo servidor quando o usuário envia uma solicitação POST.é protegido contra o XSS, codificando corretamente todas as seqüências de caracteres que são exibidas como HTML.faznão implementar HSTS, ou o navegador do usuário não suporta HSTS (como IE, Safari).faznão altere o identificador da sessão (valor do cookie de sessão) quando o usuário efetuar login.

Agora, imagine que o invasor execute um programa que intercepte todos os dados enviados por solicitações HTTP não seguras e, se forem páginas HTML, insira um trecho que faça o navegador enviar uma solicitação HTTP para www.example.com, como um img invisível ou tag iframe:

<img src="http://www.example.com/" style="display: none;" />

O atacante então visitahttps://www.example.com/ sozinho para obter um cookie de sessão gerado pelo servidor e continua navegando no site para manter a sessão ativa. Ele também modifica as solicitações HTTP do usuário parawww.example.com para incluir o mesmo cookie de sessão na resposta HTTP que o invasor acabou de receber do servidor. O cookie tem o sinalizador "Seguro" definido.

Agora, imagine o usuário visitando alguns sites HTTP regulares que não transferem dados confidenciais e, portanto, não têm SSL. Isso significa que o navegador do usuário receberá o cookie de sessão enviado pelo invasor nessas solicitações.

Posteriormente, o usuário foi parahttps://www.example.com/ e deseja efetuar login. Ele olha a barra de endereço para garantir que o ícone SSL seja exibido e, como é, efetua login com sua senha. No entanto, como o invasor fixou a sessão do usuário enviando um cookie com um atributo "Seguro" sobre uma solicitação HTTP insegura anteriormente, o invasor agora tem acesso ao estado da sessão do usuário.

Observe que, se o site estivesse alterando o identificador da sessão quando os usuários efetuassem login, o invasor não teria acesso ao estado da sessão do usuário, mas ainda assim seria possível que o invasor fizesse login como ele mesmo e enviasse o cookie da sessão para o usuário. usuário, substituindo os cookies de sessão / login anteriores, para que o usuário execute ações (por exemplo, escreva mensagens confidenciais etc.) em nome do atacante.

Minha impressão do comportamento deste navegador é que ele introduz um cenário adicional de Fixação de Sessão, conforme descrito acima. A única maneira que vejo para evitar isso é alterar o identificador da sessão em cada solicitação (para uma página HTML).

Estou faltando alguma coisa aqui?

Na minha opinião, se um navegador rejeitasse os cookies que possuem o atributo "Seguro" definido, mas que foram enviados por uma conexão HTTP insegura, o invasor não seria capaz de:

injetar um cookie de sessão no navegador do usuário com o atributo "Seguro" definido como o navegador o rejeitaria e(EDIT: não aplicável) injetar um cookie de sessão no navegador do usuário que não tenha o atributo "Seguro" definido, pois o site ignorará os cookies sem o atributo "Seguro".

Isso eliminaria a necessidade de um site específico de alterar o identificador da sessão a cada solicitação.

EDITAR: Ok, uma coisa que eu perdi é que os navegadores parecem não enviar o atributo "Seguro" no cabeçalho do cookie de volta ao servidor, portanto, o servidor não tem como determinar se esse cookie foi definido no navegador do cliente com o " Atributo "Seguro".

Mas isso significa que, mesmo que os navegadores rejeitem cookies com o sinalizador "Seguro" em conexões não SSL, o invasor poderá definir um cookie sem o sinalizador "Seguro", que será aceito pelo site em solicitações HTTPS pois não pode verificar o sinalizador "Seguro" do cookie.

Alguma ideia?

Obrigado!