Caro habrozhitel! Caros especialistas! Apresento para sua avaliação um novo conceito de identificação de usuário em sites que, espero, com sua ajuda se tornará um padrão aberto da Internet, tornando esse mundo da Internet um pouco melhor. Esta é uma versão preliminar do protocolo de autenticação sem senha, desenvolvido como um artigo gratuito. E se a idéia subjacente receber uma avaliação positiva de você, caro leitor, continuarei a publicá-la no reddit.com e no rfc-editor.org. E espero poder interessar aos desenvolvedores dos principais navegadores em sua implementação. Portanto, espero críticas construtivas de você.

Atenção: muito texto.


Então a questão é. É possível identificar inequivocamente os visitantes do site sem divulgar seus dados pessoais e rastrear entre sites diferentes? É possível, resolvendo esse problema, abandonar completamente a forma mais primitiva de autorização por login / senha e usar cookie / localStorage?

Por um lado, os sites precisam reconhecer um cliente para, por exemplo, "restaurar" suas configurações, cesta de produtos, anúncios, artigos etc. Por outro lado, os visitantes desejam permanecer o mais anônimos possível, sem revelar seus dados pessoais e impedir que sites de terceiros os rastreiem. E o último pode fazer isso trocando entre si os dados coletados.

Parece uma tarefa garantir que os lobos estejam cheios e as ovelhas seguras. Isso é real?

Eu, até certo ponto, eu acho - realmente.

Sumário

1 conceito de autenticação sem senha
1.1 Chaves e tokens em vez de logins e senhas
1.2 Estrutura do Token
1.3 cabeçalhos de protocolo HTTP
1.4 Como os clientes identificam sites?
1.4.2 Como sei se um site suporta este protocolo?
1.5 Como os clientes autorizam sites?
1.6 Como implementar uma identificação confiável do cliente?
1.7 Autorização no site pelos olhos do usuário
1.8 Como a chave do site muda?
1.9 Como a autorização entre domínios é implementada?
1.10 Como implementar a autenticação entre domínios?
1.11 Mobilidade da conta

2 Descrição técnica do protocolo
2.0 Algoritmo de geração de chave de domínio
2.1 o algoritmo para calcular o token de origem
2.2 Algoritmo de proteção de token durante a transferência
2.3 Procedimento de troca de sal entre o navegador e o servidor
2.4 Regras para a formação do campo Contexto
2.5 Regras para definir os campos Remetente e Destinatário
2.6 Detalhes sobre tabelas de definição de contexto
2.7 Cenários de protocolo
2.8 Processando tokens no servidor
2.9 Autenticação entre domínios

3 Recomendações de segurança
3.1 Proteção das principais informações contra acesso não autorizado
3.2 Sobre senhas como chaves de domínio
3.3 Riscos de perder / comprometer chaves e minimizá-las

4 Ataques ao regime de autorização
4.1 Rastreamento de usuário
4.2 Ataque XSS
4.3 Ataque do CSRF
4.4 Rastreando usando SSO
4.5 Compromisso de chave para SSO
4.6 Compromisso de token durante a transferência
4.7 Hackeando um site e comprometendo tokens

Conclusão

1 conceito de autenticação sem senha

1.1 Chaves e tokens em vez de logins e senhas

Para cada domínio, incluindo os filhos, o navegador do cliente gera aleatoriamente uma chave exclusiva de 256 bits $$ . Essa chave nunca é transmitida. Permanece constante na sessão do usuário. Cada nova sessão cria uma nova chave.
Baseado em chave $$ o navegador gera um token de 256 bits ^* usando um algoritmo especial $$ para identificar o usuário com um domínio específico. Token de identificação $$ o usuário (doravante chamado de token) serve como um substituto para cookies de sessão como PHPSESSIONID e JSESSIONID.
Key $$ pode ser " corrigido " pelo usuário. A correção da chave permitirá que o usuário permaneça autorizado no site por um tempo ilimitado em diferentes sessões do navegador e retorne a autorização existente anteriormente. Este é um análogo da função "lembre-se de mim" .
Quando a confirmação é cancelada, o navegador "esquece" essa chave e começa novamente a gerar uma chave aleatória para esse domínio para cada nova sessão (a partir da atual), que é análoga à "saída" do usuário do site. A saída é instantânea, não exigindo o recarregamento da página.
O usuário pode criar uma chave permanente para o domínio . A chave permanente, assim como a chave fixa, permitirá ao usuário retornar a autorização anterior. De fato, essa chave se torna um substituto para a conexão de senha de login.
O usuário tem a oportunidade de controlar quando o navegador do domínio usará uma chave constante e quando - aleatoriamente. Este é um análogo da função de logon / logout . O conceito é apresentado nas imagens abaixo .
Os métodos para gerar chaves de domínio persistentes fornecem a mobilidade de contas de usuário entre diferentes dispositivos. O protocolo define o seguinte:

• geração de uma chave de domínio com base em uma chave mestra do usuário
• formar individualmente uma chave de domínio com base em um sensor de número aleatório biológico
• Importando Chaves Existentes de um Arquivo de Chaves de Outro Dispositivo

1.2 Estrutura do Token

O token é uma estrutura de 256 bits, representada como uma sequência hexadecimal:

A parte de identificação do token (os 128 bits mais altos) é semelhante ao logon. Por essa sequência de bits, o servidor pode identificar exclusivamente o usuário.
A parte de autenticação do token (os 128 bits inferiores) é semelhante à senha. Essa sequência de bits ajuda o servidor a validar o token.
As regras de validação de token são descritas abaixo .

1.3 cabeçalhos de protocolo HTTP

Cabeçalhos usados ​​pelo cliente:

CSI-Token : <Token> é usado para enviar um token para o servidor
Token CSI : <Token1>; Alterado para <Token2> é usado para alterar o token atual:

• ao autorizar uma chave permanente,
• ao registrar uma chave permanente,
• ao alterar a chave permanente.

CSI-Token : <Token> Permanente é usado ao corrigir a chave aleatória atual pelo usuário.
CSI-Token : <Token> O logout é usado para finalizar prematuramente a sessão atual.

Cabeçalhos usados ​​pelo servidor:
Suporte CSI: yes diz ao cliente que o servidor suporta o protocolo de autorização CSI.
CSI-Token-Action: sucesso é usado para notificar o navegador sobre a aceitação de um novo token de usuário (chave Change-To).
CSI-Token-Action: abort cancela o procedimento de alteração de tokens (reversão para o token anterior).
Ação CSI-token: o registro informa ao navegador que o novo token de usuário ainda está em processo de registro.
CSI-Token-Action: erro inválido de verificação do token do lado do servidor.

Finalmente
O CSI-Salt é enviado pelo navegador e pelo servidor ao trocar o “salt” usado para proteger o token (parte de autenticação). Veja abaixo para mais detalhes.

1.4 Como os clientes identificam sites?

Um site pode usar um token para identificar um visitante do site. Ao mesmo tempo, o esquema de geração de tokens e sua capacidade de 256 bits garantem tokens exclusivos para cada par: domínio do usuário. Outro domínio verá outro token de usuário. Mesmo se executado no contexto do site de destino (via IFRAME, IMG, LINK, SCRIPT). Além disso, um algoritmo especial de geração de token protege os usuários contra ataques XSS, SRF e torna impossível rastrear um usuário sem seu conhecimento. Mas, ao mesmo tempo, a tecnologia SSO permanece possível com sua permissão e identificação entre domínios.
O token é transmitido no cabeçalho HTTP CSI-Token com todas as solicitações para qualquer recurso de domínio (página, documento, imagem, script, estilo, fonte, arquivo, solicitação ajax, ...):

O token é recalculado a cada solicitação HTTP (S) : página, imagem, solicitação ajax.
Para otimizar os cálculos, o cache de tokens pelo navegador é permitido, mas apenas durante a sessão e somente se as condições para atender à solicitação permanecerem inalteradas.
Como observado acima, o token pode servir como um substituto para cookies de sessão como PHPSESSIONID e JSESSIONID. A única diferença é que, se o site gerou anteriormente um identificador para o visitante rastrear um usuário específico entre suas diferentes solicitações (afinal, milhares de solicitações de usuários diferentes chegam ao site ao mesmo tempo), agora o próprio cliente executa essa função.
Essa identificação é suficiente para permitir que você faça compras na loja online, anuncie em sites apropriados, escreva em fóruns, redes sociais, artigos da Wikipedia ou da Habré.
Sim, o usuário permanece anônimo para o site. Mas pode ser um "familiar" anônimo para o site. E o servidor pode salvar o token de um usuário assim, juntamente com seus dados (conta pessoal com compras, preferências, karma, pães, gostos e outros bônus). Mas apenas para manter a condição de conclusão de qualquer processo comercial: compra, envio do anúncio, etc. As condições são determinadas pelo próprio site.
Como você pode ver, o protocolo é o mais simples possível para sites que não precisam registrá-lo antes de dar a oportunidade de executar qualquer ação. Mas aqueles que precisam terão um pouco mais de dificuldade. Mas mais sobre isso abaixo.

1.4.2 Como sei se um site suporta este protocolo?

O site deve passar o cabeçalho http do CSI-Support: yes na seção Cabeçalhos de resposta de sua resposta:

Ao ver esse título, o navegador informará discretamente o usuário que ele pode se salvar no site. Por exemplo, o símbolo da chave na barra de endereço:

Clicar em uma chave, por exemplo, criará uma chave para o domínio www.youtube.com :

A formação de uma nova chave não leva ao seu uso automático.

A chave permanente começa a ser usada apenas quando ativada pelo usuário.

1.5 Como os clientes autorizam sites?

É importante entender que o token ainda não torna o usuário autorizado em um site específico - apenas reconhecível. Mas, como já foi dito, por enquanto você é simplesmente uma "pessoa anônima" reconhecível.
Se o site precisar associar seu token a você pessoalmente, o registro nesse site, infelizmente, não poderá ser evitado. Mas no protocolo proposto, isso é um pouco mais fácil.

É importante que os desenvolvedores entendam: a maioria dos sites não precisa de um questionário. Evite forçar os visitantes a se registrarem. Nas situações mais comuns, você pode executar um processo de negócios sem coletar visitantes do PD.

Preencher formulários de registro tediosos "com ou sem" é desagradável. Mas com o novo protocolo, não é mais necessário criar outro login e senha. Somente o botão Confirmar e salvar me:

Obviamente, você precisará primeiro criar uma chave permanente para o site. Mas isso é questão de alguns cliques do mouse.
E, com certeza, você será solicitado a confirmar seu telefone ou endereço de correspondência. Mas isso já depende do site.
Após a autorização bem-sucedida, o servidor, por meio de um cabeçalho HTTP especial, o CSI-Token-Action informará o navegador que aceitou a nova chave. Mais detalhes no capítulo II .

1.6 Como implementar uma identificação confiável do cliente?

Em situações mais graves (conta pessoal do provedor, hospedagem, banco), a autenticação de dois fatores deve e pode ser realizada, e a comprovação da posse do token pode ser feita através do pré-registro e confirmação da identidade de outras maneiras: por e-mail, SMS ou mesmo fixando em papel o token do usuário. (Sim, sim. Os certificados são gravados em papel, porque não os tokens).

1.7 Autorização no site pelos olhos do usuário

O navegador notifica o usuário que o site suporta autorização CSI através do ícone de cadeado na barra de endereço. Se você executar algumas ações no site, peça ao site para lembrar de você. A partir deste momento, o servidor reconhecerá o usuário mesmo entre diferentes sessões:


Em vez de fixar a chave, o usuário pode criar uma chave permanente para o site e se registrar no local. Ilustração animada:


E quando o usuário tem uma chave permanente para o site e essa chave é registrada lá, o processo de login é bastante simplificado:


O maior poder do protocolo se manifesta quando o usuário cria uma chave para o site com base na chave mestra. Nesse caso, o problema de sua identificação em sites de outros dispositivos é facilmente resolvido . A animação a seguir demonstra isso. Supõe-se que você já tenha distribuído sua chave mestra uma vez entre seus dispositivos / navegadores:


Para sites com autorização de dois fatores, o "reconhecimento" pode ser assim:


Sair é ainda mais fácil. Clique em "Logout" no navegador e pronto:

O navegador envia uma solicitação para o site (em qualquer página) com o método HEAD, no qual envia o cabeçalho CSI-Token <>; Sair.

O servidor, vendo esse cabeçalho, efetua um logout. Se fosse uma chave fixa, o site excluirá todas as informações sobre o usuário (mais do que essa chave nunca aparecerá). Se fosse uma chave permanente, apenas interrompe a sessão.
Qualquer outra atividade do site transforma o usuário em um anônimo desconhecido para o site: recarregar a página, tentar fazer uma solicitação de ajax, baixar um arquivo etc. - O navegador enviará um token gerado já com base em uma chave aleatória.

Você pode gerenciar as chaves no gerenciador de chaves: altere a chave permanente, exporte a chave permanente para um arquivo, importe de um arquivo de outro dispositivo. Configure a "saída automática" após fechar uma guia ou navegador. Defina a duração de uma chave fixa.

1.8 Como a chave do site muda?

Substituir a chave permanente do site é tecnicamente o mesmo que mudar de uma chave aleatória para uma permanente. Isso é descrito em mais detalhes no capítulo II .
No caso de alterar a chave permanente do site, o navegador notifica o site da alteração correspondente no token, enviando um cabeçalho CSI-Token com a chave Changed-To em cada solicitação subsequente :

O site deve processar corretamente essa solicitação. E, se um determinado token de usuário estiver armazenado em seu banco de dados, ele deverá fazer uma substituição apropriada. Ao mesmo tempo, o site deve responder ao navegador sobre a alteração bem-sucedida do token. Ele faz isso no cabeçalho Response Headers com o parâmetro: CSI-Token-Action: success , indicando o token aplicado.
O site tem o direito de rejeitar uma tentativa de alterar o token (por exemplo, se não houvesse esse token no banco de dados ou se não os salvasse) com o parâmetro CSI-Token-Action: abortado.
Até que o navegador receba o cabeçalho CSI-Token-Action, ele adicionará a chave Changed-To a cada solicitação de CSI-Token no site.
Este é um análogo da "alteração de senha" do usuário.

1.9 Como a autorização entre domínios é implementada?

A autorização clássica de domínio cruzado usando a tecnologia SSO tem muitas vantagens para o usuário. Você não precisa se lembrar de várias senhas de vários sites. Não há necessidade de se registrar e preencher os formulários tristes. Alguns servidores de autorização perguntam quais direitos conceder ao site que solicitou o SSO.
Mas também há desvantagens. Você depende do provedor de SSO. Se o servidor SSO não funcionar, você não chegará ao site de destino. Se você perder sua senha ou sua conta for roubada - você perderá o acesso de todos os sites de uma só vez.
Para desenvolvedores web, as coisas são um pouco mais complicadas. Desde o início, você precisa registrar seu site no servidor de autorização, obter as chaves, aprender a trabalhar com o protocolo ( SAML , OAuth etc.) e as bibliotecas correspondentes, verifique se a chave não expira, se o servidor de autorização não bloqueia seu site por seus motivos e etc. É uma taxa pelo fato de você não precisar manter contas de usuário, fazer formulários de registro, fazer login etc. A verdade aumenta o custo de manutenção (na forma de reparar falhas repentinas). Novamente, se o servidor estiver subitamente indisponível no site, então, infelizmente.
Esse esquema de autorização torna o SSO um pouco mais seguro e a autorização para todos os participantes é mais fácil. A segurança será discutida abaixo na seção "Compromisso de chave para SSO".

Dê uma olhada no site S, que suporta o SSO do Google. Suponha que você tenha uma conta do Google. Para fazer login, clique no link "Fazer login com o Google", que abrirá a guia de autorização do Google. O navegador informará que você tem uma chave para o Google. E o Google informará quais direitos S. solicita.
Se você concordar, clique em "Login" no gerenciador de chaves. A página será recarregada. O Google já receberá seu token válido, reconhecerá e autorizará você. E com uma solicitação entre servidores, ele informará o Site S sobre as informações da sua conta, de acordo com os campos solicitados.
A página recarregada conterá um botão "Avançar" que o levará ao site de destino.


O Site S pode decidir salvar dados sobre você no banco de dados ou não. Esta questão está além do escopo do esquema de autorização proposto. Além disso, onde consideraremos os riscos de perder a chave do SSO, o site é recomendado para manter o token e o identificador do usuário do SSO de lado e recomenda-se que o usuário crie uma chave permanente para S.

Vulnerabilidade: após essa autorização, os sites S1, S2, S3, ... (onde você acessou o Google) poderão reconhecê-lo (pelo identificador atribuído a você pelo Google) e, como resultado, rastrear sua atividade.

Opção de proteção: não trabalhe simultaneamente em sites se você se registrou através do SSO do mesmo provedor. Se possível, efetue logout no servidor de autorização imediatamente após a conclusão da autorização ("saída automática" para o domínio).

1.10 Como implementar a autenticação entre domínios?

Tudo isso, claro, é bom. Enquanto o trabalho é realizado em um navegador - está tudo bem. Mas e as realidades modernas quando uma pessoa tem dois telefones celulares, um computador em funcionamento e vários navegadores, um computador doméstico e outro laptop? Além de um tablet comum para a esposa / filhos.
De alguma forma, teremos que resolver o problema da transferência de chaves de domínio entre navegadores, dispositivos. E também resolva o problema de sua sincronização correta.
Um dos mecanismos para resolver esse problema é calcular várias chaves de domínio com base em uma chave mestra comum, sem a possibilidade de recuperação reversa da chave mestra de uma chave de domínio conhecida.
Ao criar uma chave pessoal K para o domínio D usando a chave mestre M em um dispositivo, o usuário poderá criar a mesma chave K para o domínio D e em qualquer outra usando a mesma chave mestre M e um único algoritmo. Mais precisamente, isso será feito não pelo usuário, mas pelo navegador. Com essa abordagem, é suficiente para o usuário distribuir sua chave mestra entre todos os navegadores usados ​​por ele e ele "transfere todas as suas chaves" de domínios de uma só vez. Ao mesmo tempo, faz backups dessa maneira.
Máxima comodidade do usuário. Mas também o risco máximo em caso de comprometimento da chave mestra. Portanto, este último deve ser protegido adequadamente. Os riscos de perda ou comprometimento da chave mestra e as formas de minimizar esses riscos estão descritos no capítulo "3 Recomendações de segurança" .
Usar apenas uma chave mestra para gerar todas as chaves para todos os domínios nem sempre é uma opção conveniente. Em primeiro lugar, o que fazer se de repente a chave do domínio for comprometida e precisar ser alterada? Em segundo lugar, e se você precisar compartilhar uma chave de domínio com outra pessoa? Por exemplo, entre membros da família. Ou é uma conta corporativa de acesso ao correio público. Como, então, "pegar" sua chave (porque na verdade ela foi comprometida)?
Portanto, a geração de chaves de domínio individuais usando um sensor de número aleatório biológico deve ser suportada pelos navegadores. Mas voltamos novamente à questão de nossa mobilidade e aos problemas de sincronização, às funções de exportar e importar chaves no navegador e criar cópias de backup.

Transferir através de um dispositivo físico alienável

Cartões inteligentes e tokens USB podem ser bastante adequados como armazenamento seguro de informações importantes (porque foram criadas para isso). A autenticação de dois fatores protege as chaves contra acesso não autorizado com acesso direto ao dispositivo.
É verdade que os cartões inteligentes requerem leitores especiais (para não mencionar drivers), o que limita seu uso apenas às estações de trabalho equipadas com esses leitores.
Com tokens USB um pouco mais fácil. Somente drivers são necessários. Mas você não pode colocar esse símbolo no telefone. E embora para telefones celulares existam tokens feitos na forma de cartões SD, para não dizer que esta solução aumenta a mobilidade. Tente desenhar um cartão de um telefone celular, mas insira-o em outro. E não é que isso seja impossível. O problema é que não é conveniente.
E se o token quebrar? Então todas as suas chaves irão para o Grande Cthulhu.
Portanto, haverá uma tentação com esse esquema de usar vários dispositivos duplicados. Mas você ainda precisará resolver o problema de sincronização de chaves se tiver vários cartões inteligentes.
E, francamente, esses dispositivos não estão protegidos contra keyloggers. Agora, se o código PIN for inserido no próprio cartão / token. Então outra coisa. Mas eu não vi isso na natureza.

Prós: chaves aleatórias de 256 bits podem ser usadas; alta segurança através do uso de autenticação de dois fatores; o mais alto nível de proteção contra adulteração direta.
Contras: dependência do dispositivo; requer custos financeiros; baixa mobilidade; a necessidade de reservar cartões e, como resultado, sincronizar dados entre eles; permanece vulnerável a keyloggers.

Sincronizar via serviço online

A "tecnologia em nuvem" agora é empurrada sempre que possível. Parece que eles, juntamente com o blockchain, se tornaram um substituto para a "tecnologia da banana". Naturalmente, existe o desejo de usar uma certa plataforma da Internet para a troca de informações importantes. Um tipo de cartão inteligente "online".
O que? Você efetua login usando nosso esquema anonimamente em um site desse tipo; envie suas chaves criptografadas com uma senha lá; Você vai de outro dispositivo para o mesmo site com a mesma chave / senha; você pega as chaves de lá; Você sincroniza as alterações na data da edição. Semelhante ao gerenciador de senhas, somente isso está online.
Isso é justo, ninguém garante que o serviço on-line não será invadido ou não mesclará suas chaves, embora criptografadas, "onde necessário". Quem implementará esse serviço gratuitamente. É isso.
Embora, é claro, a senha proteja as chaves do uso direto. Mas sua senha é resistente à força bruta "offline"? Essa é outra questão.

Prós: alta mobilidade de credenciais; independência de dispositivo e navegador; você precisa de apenas uma senha (embora elas não tenham deixado a senha, já é melhor).
Desvantagens: menos seguro do que armazenar chaves em um meio alienável. De fato, a segurança das chaves é baseada na força da senha da seleção.

Obviamente, você pode usar uma chave mestra para criptografar outras chaves. Aquele com o qual outras chaves de domínio são calculadas. Como uma opção

2 Descrição técnica do protocolo

2.0 Algoritmo de geração de chave de domínio

Este protocolo define apenas 2 métodos para gerar chaves de domínio.

• com base em um gerador de números aleatórios (de preferência biológico)
• com base em uma chave mestra de 256 bits

No último caso, a chave do domínio é calculada como:

$$

onde $$ - chave mestra de 256 bits, Domínio - nome do domínio para o qual a chave foi feita.
A seguir, o HMAC é um algoritmo criptográfico de hash baseado em uma implementação de 256 bits da função de hash SHA-2 .

A divulgação comprometida ou voluntária de uma chave de domínio não compromete a chave mestra original.

A chave mestra fornece um mecanismo para a mobilidade das credenciais do usuário.

Se a chave criada com base no "mestre" foi comprometida ou o token calculado a partir dessa chave (como resultado da invasão do site) foi comprometido, a chave deve ser alterada. Você pode alterá-lo para uma chave aleatória de 256 bits ou gerá-lo a partir do mesmo "assistente", com a adição de uma versão:

$$

A seguir, o símbolo $$ será usado para operação de concatenação de strings (matrizes de bytes).

2.1 o algoritmo para calcular o token de origem

O token de autenticação do usuário é calculado com todas as solicitações de qualquer recurso de domínio. Para calcular o token de solicitação, os seguintes dados são obtidos:

• Remetente - o nome de domínio do iniciador da solicitação (pode ser uma página com um iframe ou um script do domínio de outra pessoa que realiza a busca),
• Destinatário - nome de domínio do destinatário (para onde a solicitação é enviada),
• Contexto - solicite o contexto de execução,
• Proteção - uma sequência aleatória de 32 bytes (256 bits), se o Contexto estiver vazio; caso contrário vazio

Esses dados são concatenados e agrupados com SHA-2 de 256 bits na chave K do domínio que inicia a solicitação :

$$

Um token válido é obtido quando o Contexto não está vazio. Para uma identificação adequada no site de destino, a condição Remetente = Destinatário = Contexto deve ser atendida.

O campo Contexto, junto com Proteção, é usado para proteger contra ataques XSS e CSRF , bem como do rastreamento de usuários.
Explicações mais detalhadas sobre as regras para determinar Remetente / Destinatário / Contexto serão fornecidas abaixo.

2.2 Algoritmo de proteção de token durante a transferência

O token do cliente original é transmitido extremamente raramente. Somente ao transferir um token não registrado no momento em que a sessão foi criada.
Um token é considerado não registrado se: é criado com base em uma chave aleatória (não fixa); não foi aceito pelo servidor após o envio da chave Alterar para ou Permanente. Para mais detalhes, consulte “Processando tokens no servidor” .
O navegador e o servidor geram conjuntamente um par de números aleatórios, os chamados salt (Salt), com o qual os 128 bits inferiores do token são hash. Ambos trocam esses números de acordo com o protocolo. Para detalhes, consulte “Servidor de Procedimentos de Troca de Sal” .
Portanto, o servidor do site vê o seguinte token:

$$

onde $$ - 128 bits altos, $$ - os 128 bits inferiores do token original, $$ - concatenação de strings. Nesse caso, o token inicial $$ já deve ser conhecido pelo servidor.

Idealmente, o CSI-Salt deve mudar toda vez que um navegador solicita um servidor. No entanto, isso pode ser um requisito caro em termos de recursos de computação. Além disso, ele pode "matar" a capacidade de enviar solicitações paralelas ao servidor.
Portanto, para otimizar os cálculos, é permitido manter os valores de CSI-Salt inalterados em diferentes solicitações, mas não mais que uma sessão . Pode ser um limite de tempo (alteração do CSI-Salt a cada 5 minutos) ou uma reação à intensidade das solicitações (alteração do CSI-Salt a cada 100 solicitações) ou após cada série de solicitações (no momento da pausa, cliente-servidor) ou uma versão mista. Aqui a decisão é deixada para os desenvolvedores do navegador.
Manter o CSI-Salt inalterado por muito tempo enfraquece a proteção do token transmitido, permitindo que o invasor, ao interceptar o token, use-o até que o usuário legítimo conclua o Logout e faça uma solicitação não autorizada em nome da vítima.

2.3 Procedimento de troca de sal entre o navegador e o servidor

2.3.1 Token baseado em uma chave de servidor ^[1] aleatória ou não registrada.

2.3.2 Token baseado na chave registrada pelo servidor ^[1] .

---

^{[1] Um token é considerado não registrado se: é criado com base em uma chave aleatória; não foi aceito pelo servidor após o envio da chave Alterar para ou Permanente com a resposta CSI-Token-Action: success.
[2] O tempo durante o qual a alteração CSI-Salt é feita é determinado pelos próprios navegadores. Isso pode acontecer após uma série de solicitações, após um tempo limite, após um determinado número de solicitações. – CSI-Salt .
[3] 16- 128- . , : _salt || S _salt . – , . , , .}

2.4 Context

Nós chamaremos nosso domínio de cuja página estamos carregando (exibido na barra de endereços do navegador). Os domínios restantes serão chamados externos . Mesmo que esses sejam domínios filhos de um dado.

Chamamos o recurso de externo se ele foi baixado de um domínio externo. Chamaremos o recurso de interno se ele tiver sido baixado do nosso domínio. O recurso pode ser um script, imagem, solicitação de ajax e qualquer outro arquivo.

Um script é considerado externo se tiver sido baixado de um domínio externo. O script colocado na tag <script> criada, criada por um script externo, também será considerado externo. O script localizado na tag <script> modificada é declarado externo se tiver sido modificado por um script externo ou se um script externo estiver presente na cadeia de chamadas quando seu conteúdo for alterado. Mesmo se, ao mesmo tempo, esse <script> estivesse originalmente na página ou fosse criado por um script interno.

Nomearemos as tags LINK, SCRIPT, IMG, IFAME e outras, que exigem que o navegador carregue algum recurso assim que ele for atendido pelo analisador DOM - tags de recurso .

Nomearemos as tags FORM, A, META e outras, que podem iniciar o carregamento da página sob determinadas condições (enviar, clicar,timeout) - iniciando tags.

Nós chamaremos a tag estática se ela estava originalmente presente na página quando foi emitida pela primeira vez pelo servidor. Chamaremos a tag de dinâmica se ela foi criada no processo de execução dos scripts.

A tag FORM é declarada dinâmica, mesmo que não apenas a tag em si tenha sido alterada, mas também os valores de todos os campos INPUT associados a este formulário.

Nós chamaremos uma tag dinâmica nossa se o script que a criou pertencer ao nosso domínio e a cadeia de chamadas da instrução que gerou essa tag não tiver uma função pertencente a um script externo. Caso contrário, consideramos inadequada uma tag dinâmica .

O carregamento da página é acionado iniciando tags.A tag inicial pode ser ativada diretamente pelo usuário, ou ativada pelo script, executando o comando click (para o link) e enviando (para o formulário), ou pelo script que gera os eventos onclick / onsubmit correspondentes.

Além disso, a tag inicial pode ser ativada pelo navegador. Um exemplo dessa tag é META com os parâmetros http-equiv = "refresh" content = "0".

^{Tabela P. Valores de contexto sob diferentes condições de abertura da página}


Se a tag do recurso foi alterada por um script (por exemplo, o atributo SRC do IMG) e o recurso foi carregado automaticamente pelo navegador, acreditamos que o conteúdo / recurso foi acionado pelo analisador, o método de carregamento é a tag, mas o status dessa tag torna-se "dinâmico".

^{Tabela R. Valores de contexto sob diferentes condições para carregar conteúdo / recurso}

---

^{[1] Iniciando tag
[2] Resource tag
[3] Herdar para páginas próprias, Vazio ao abrir páginas de domínios estrangeiros
[4] Herdar ao redirecionar servidores para suas páginas, Vazio ao redirecionar para outros domínios ou abrir uma página de fontes externas (consulte . clarificação )}


Marcas no formato P1..PF, R1..RC serão usadas para se referir à célula correspondente na tabela ao analisar situações específicas.

Observe o referenciador e o domínio destacados na primeira tabela. Você só pode ser autorizado em um site quando você mesmo o abrir em um endereço direto ou por um link de outro site, com o recarregamento subsequente da página por sua própria iniciativa.

2.5 Regras para definir os campos Remetente e Destinatário

Remetente é o domínio da página / script / estilo do qual a solicitação vem. A página solicita estilos, imagens, scripts. Os scripts solicitam conteúdo via ajax. Estilos podem carregar outros estilos. Estes são os iniciadores da solicitação.

Destinatário é o domínio para o qual a solicitação realmente vai.

Para que não restem perguntas, vamos considerar exemplos específicos.

Que haja um site site.net. Na página principal do site é:

• estilo site.net/css/common.css
• os estilos common.css importam estilos de fonts.google.com/fonts/Roboto.css
• O estilo Roboto.css importa a fonte fonts.google.com/fonts/Roboto.ttf
• imagem levando a img.site.net/picture1.jpg
• quadro carregado de adriver.ru/frame
• script de adm.site.net/admin.js

Deixe no quadro (com adriver.ru) conectar:

• estilo de adriver.ru/style.css
• foto de img.adriver.ru/img/01.png
• script de adriver.ru/libs.js
• script de api.adriver.ru/v1/ad.js

Valores de remetente / destinatário ao carregar recursos com o analisador DOM

Agora, vejamos os valores de Remetente / Destinatário ao carregar conteúdo com scripts durante a execução de solicitações de ajax.

Valores de remetente / destinatário ao carregar conteúdo com scripts

2.6 Detalhes sobre tabelas de definição de contexto

Vamos considerar com mais detalhes quais opções de abertura de páginas (guias no navegador) temos e qual valor de contexto será obtido.

P1 - o usuário na página anterior clicou no link ou no botão enviar no formulário. O manipulador de navegador de eventos padrão para o link / formulário redirecionou o usuário para esta página. Situação normal. Transição segura entre páginas de um domínio ou domínios diferentes.

Ao alternar para o site.net de outro domínio do google.com, o Contexto será igual ao domínio anterior (google.com). E o usuário no novo domínio site.net não será autorizado (mesmo que a guia vizinha deste site onde o usuário está autorizado esteja aberta).

A transição independente repetida do usuário (sem a assistência de scripts) por meio do link para o mesmo site levará novamente à situação P1 , mas o Contexto já será igual ao domínio site.net, porque pela regra Contexto = Referenciador.

É feito para proteger contraAtaque CSRF .

P5 - o usuário da página anterior clicou no link criado / modificado por um script baixado do domínio da página anterior; ou o usuário na página anterior clicou no botão enviar do formulário criado / modificado pelo script (alterando a tag FORM, incluindo seus campos INPUT). O manipulador de navegador de eventos padrão para o link / formulário redirecionou o usuário para esta página.

P9 é igual a P5 , apenas o script era externo ou existe uma função de um script externo na cadeia de chamadas (proteção contra a edição das funções de script do script do site por um script de terceiros).

PD - o usuário abriu a página em um endereço direto. Abertura segura.

O usuário deve abrir a página digitando o URL na barra de endereço. Ou abra um site a partir dos favoritos do navegador.

Ao abrir um link a partir de um atalho na área de trabalho de outro programa, qualquer outra situação em que o SO envie um comando ao navegador para abrir o link deve ser considerado um caso de PG (a abertura do link é iniciada pelo navegador). Mesmo se o usuário pressionar F5 para recarregar a página, isso deve ser considerado um caso de PG . Somente se o usuário entrar na barra de endereços e pressionar Enter será considerado pelo navegador como um PD .

Isso é feito para proteger ataques CSRF de outros programas.

Seguir o link de outro programa levará o usuário ao site atacado com um token inválido e um Contexto vazio, que será salvo mesmo que o usuário pressione F5 (atualize a página). Você não pode fazer login até que o usuário abra qualquer link para as páginas do site (situação P1 ).

Portanto, se um invasor de outro programa decidir inserir um link para a página do site site.net que está executando um comando, o usuário autorizado não poderá fazer isso com facilidade. Será necessário forçar o usuário a clicar em outro link nesta página, forçar o usuário a se autenticar lá, e somente então ... Então, o usuário provavelmente estará em outra página do site.net.

P2 - na página anterior de um link ou formulário originalmente colocado na página, um script nativo da página anterior gerava um evento de clique / envio. Não havia funções na cadeia de chamadas que pertenciam a scripts externos. O navegador redirecionou o usuário para esta página.

Se a nova página pertencer ao mesmo domínio, o contexto será herdado da página anterior. Se a nova página pertencer a um domínio externo, o Contexto ficará em branco.

P6 é o mesmo que P2 , apenas o link / formulário foi criado / modificado por seu próprio script.

PA é o mesmo que P2 , apenas o link / formulário foi criado / modificado por um script externo.

PE - o script da página anterior provocou a abertura desta página com o comando window.location.href ou window.open (...).

Se o script da página site.net redirecionar o usuário para a página do mesmo domínio, o campo Contexto será herdado da página geradora. Nesse caso, Context = site.net.

Se a página ya.ru foi aberta e o script nos transferiu para maps.ya.ru, o Contexto da nova página já estará vazio. Nas ações subseqüentes do usuário, o Contexto quase sempre permanecerá vazio, o que complicará a autorização do usuário no site.

O protocolo implica que abrir um site de outro é uma operação insegura. Isso protege o usuário contra rastreamento não autorizado por esses sites e contra ataques de CSRF.

P3 - semelhante ao P2 , apenas o evento de clique / envio foi acionado por um script externo. O contexto fica vazio (uma sequência aleatória de bytes é enviada), o que protege sites de terceiros do rastreamento do site (redes de banners).

P7 - semelhante ao P6 , apenas o link / formulário foi criado / modificado por um script externo.

PB - semelhante ao PA , apenas o link / formulário foi criado / modificado por um script externo.

PF - semelhante ao PE , apenas o roteiro provocativo era externo.

P4 - o navegador recarregou a página como resultado do processamento da tag <META>. A tag estava originalmente na página. Redirecionamento legal. O contexto persistirá da página original. Como é o caso do PE .

P8 - o navegador recarregou a página como resultado do processamento da tag <META>. Mas a tag foi criada / modificada por seu próprio script. Isso é válido, mas o contexto persistirá da página original. Como é o caso do PE . Não será possível atrair o token legal do usuário dessa maneira.

PC - semelhante ao P8 , apenas script externo. O site aberto receberá um número aleatório como contexto.

PG - navegador abre links sob comando no sistema operacional. Pode ser que você clique em um link de outro programa, abra um atalho na área de trabalho. Este pode ser um comando de outro programa, sem o seu conhecimento. Nesse caso, a fonte não é confiável e o campo Contexto permanecerá vazio durante qualquer manipulação do usuário.

Isso é feito para proteger ataques CSRF de outros programas.

Se o próprio navegador abrir as guias salvas anteriormente, o Contexto da página será definido igual ao valor desta página no momento do fechamento do navegador.

Além disso, esta categoria inclui todas as situações em que o navegador é redirecionado pelo servidor para outra página (de seu domínio ou de outra pessoa) como resultado do processamento do cabeçalho HTTP do cabeçalho. Se o redirecionamento for para sua própria página, o valor de Contexto será herdado. Se o redirecionamento for para o de outra pessoa, ele será redefinido.

Isso é feito para proteger contra o rastreamento de ataques de servidores da web.

A propósito, essa regra pode causar problemas com a implementação atual da autorização entre domínios. Se após a autorização, o servidor SSO redirecionar o usuário de volta ao site de destino, o último será anônimo lá.

Para impedir que o usuário "perca" a autorização original no site de destino, é necessário transmitir informações de autenticação entre as solicitações do servidor. O algoritmo pode ser o seguinte:

1. o usuário cria e ativa uma chave permanente para o site de destino;
2. Vai do site de destino para o servidor SSO, clicando no link apropriado;
3. ativa a chave permanente existente do servidor SSO;
4. Após receber a chave Changed-To, o servidor SSO envia uma solicitação entre servidores para o site de destino;
5. o usuário clica no botão "Continuar" na página de autorização, que o retorna de volta ao site de destino;
6. para cumprir a regra P1 , o site de destino oferece ao usuário que clique no botão de link novamente, levando a ele (por exemplo, para a página inicial de um participante autorizado).
7. o usuário clica no botão de link, a página é recarregada e o usuário já está autorizado no site de destino.

A descrição do algoritmo parece realmente mais complicada do que sua implementação. Uma implementação de interface do usuário pode ter esta aparência:

A reintrodução no site de destino não requer mais autorização do SSO do usuário. É o suficiente para ativar a chave permanente.

Agora, vamos examinar mais de perto as opções de carregamento de conteúdo nas páginas e qual valor de contexto será obtido mediante solicitação.

R1 - o recurso é carregado pelo navegador como resultado da análise da página (o navegador encontrou uma etiqueta de recurso). O valor de contexto ao gerar uma solicitação para um recurso é obtido na página Contexto que contém a marca do recurso.

Por exemplo, se site.net tiver um quadro adriver.ru no qual a imagem de img.disk.com é carregada, ao gerar uma solicitação HTTP para img.disk.com, o navegador utilizará o valor calculado como o Contexto da página site.net.

R4 é o mesmo que R1 . Somente a tag de recurso foi criada / modificada por seu próprio script, como resultado do qual o Analisador DOM do navegador funcionou. Por exemplo, na página site.net/index.html, nosso próprio script site.net/require.js inseriu outro script personalizado (<script src = ...> tag) site.net/min.js, que forçou o navegador a gerar uma solicitação de download de arquivo main.js. O campo Contexto nesta solicitação será definido como o valor calculado para a página site.net.

R7 é o mesmo que R1 . Porém, como a tag do recurso foi criada / modificada por um script externo, quando o recurso é solicitado, o navegador gera um token com base em um Contexto vazio e uma sequência aleatória de 256 bits. Como resultado, o script externo do invasor evil.com/drop.js, incorporado na página do domínio site.net atacado, tentando atender a uma solicitação ao site.net de destino em nome da vítima falhará, porque o servidor receberá uma solicitação com um token aleatório e não poderá identificar o remetente da solicitação.

O analisador de RA baixa o conteúdo como resultado da análise de outro conteúdo. Por exemplo, a folha de estilo site.net/css/common.css, baixada para a página site.net/index.html, importa a folha de estilo fonts.google.com/fonts/Roboto.css, que força o navegador a solicitar fonts.google .com em nome de Referrer = site.net/css/common.css. O valor do contexto neste caso será igual ao referenciador. Em seguida, o arquivo de estilos Roboto.css importa a fonte Roboto.ttf, que força o navegador a solicitar fonts.google.com/fonts/Roboto.ttf em nome de Referrer = fonts.google.com/fonts/Roboto.css. O valor do contexto será igual a Referrer neste caso, mas é diferente.

Suponha, hipoteticamente, que o arquivo Roboto.css (recurso externo) não importe uma fonte / estilo, mas tente realizar um ataque CSRF com esta instrução:

@import "https://site.net/api/payment?victim_params" 

esperando atender à solicitação no site.net em nome de um usuário autorizado. Mas o problema do invasor é que o site.net espera receber um token do usuário:

$$

Então, como em uma solicitação CSRF, o navegador criará um token:

$$

E uma solicitação para o site virá em nome de um site anônimo que não possui direitos de acesso para executar essas operações.

RB - o conteúdo é carregado pelo próprio script do site. Nesse caso, o contexto é usado para calcular o token de solicitação, que é igual à página que contém o script. Para o script site.net/1.js da página de contexto site.net, será igual ao contexto da própria página.

Observe que o contexto da página em si nem sempre é igual ao nome de domínio da página e depende de como foi aberto originalmente.

Suponha que o site do atacante evil.com abra a página do site atacado site.net, onde o script site.net/util.js executa uma solicitação com parâmetros passados ​​pelo URL da página. O invasor espera, ao passar "seus parâmetros" pela URL, forçar seu próprio script site.net/util.js a executar uma solicitação ajax para executar ações importantes em nome da vítima.

Suponha que o próprio usuário tenha acessado o evil.com por um link direto. Então o contexto para evil.com será evil.com. Então, evil.com abre site.net/api/payment?victim_params com um script , na esperança de iniciar um ataque, mas o campo Contexto para site.net estará vazio (caso de PE / PF). O script site.net/utils.js, executando uma solicitação ajax, forçará o navegador a obter o Contexto da página site.net. E está vazio conosco. Mas o site.net receberá uma solicitação ajax com este token:

$$

considerando que para um usuário autorizado, é esperado:

$$

site.net verá um token desconhecido e não poderá identificar o usuário. A proteção funcionou.

A propósito, por causa desse esquema, a realização de autorização entre domínios por meio de pop-ups será irrealista.

Para implementar o SSO sob o protocolo, você deve abrir uma nova guia para a página do servidor de autorização. E, ao mesmo tempo, o usuário deve abrir essa guia. A melhor opção é abrir ao usuário o link apropriado no site de destino.

RC - o conteúdo é carregado com um script de site externo. Nesse caso, o contexto é usado para calcular o token de solicitação, que é igual ao campo Referenciador de solicitação.

Apesar do RA , RB e RC protegerem contra ataques CSRF, eles levam à geração de tokens constantes. E isso permite implementar a autenticação entre domínios e a autenticação de usuário entre domínios (quando você precisar determinar que várias solicitações para servidores diferentes vieram desse usuário). O que pode ser implementado para fornecer a ele autoridade igual em um grupo de domínios relacionados.

Se a página do site foi aberta automaticamente a partir de outro site, você não poderá fazer login lá, mesmo se você mesmo recarregar o site. Porque a origem herdará de um valor nulo. O navegador deve sinalizar para o usuário sobre esse fato (Fonte = Aleatório):

Isso é feito para proteger contra sites que forçam a abertura de outras janelas pop-up (eles mesmos ou seus scripts externos) e, nos sites que abrirem, eles serão reinicializados ou criarão falsos botões "fechar" em toda a tela, levando aos mesmos sites. I.e. isso evita uma tentativa de rastrear você, na esperança de obter um token válido.

Qualquer tentativa do site de imitar suas ações com um script externo , ou uma tentativa de um script externo de criar direta ou indiretamente uma tag inicial e enviá-la para você, levará a uma Origem vazia e à adição de bytes aleatórios no momento do cálculo do hash do token.

O truque para criar ou modificar a tag <script> na página atacada no DOM não ajudará. O campo Origem permanecerá em branco.

Mas, nas mesmas condições, os scripts internos levarão a consultas com o Source igual ao seu valor anterior. E se a página original tivesse Source = Domain, tudo ficaria bem. O usuário permanecerá autorizado para tais solicitações.

Porém, com scripts baixados de recursos de terceiros (CDN), alguns problemas podem surgir. E está certo, porque A integridade do código CDN não é garantida. Se você não perder a autorização do usuário, mantenha os scripts no seu site e faça o download deles no seu domínio. Isso é algo como a proibição de usar links http em páginas https.

Descrevemos a situação em que um desenvolvedor pode cair. Como resultado das ações do usuário, seu script redireciona um usuário autorizado para uma das páginas do site (por exemplo, isso é feito por um formulário), exigindo que o usuário permaneça autorizado. Seu script chama, por exemplo, $ (form) .submit () usando um script jQuery carregado a partir da CDN. Nesse caso, o navegador vê que na pilha de chamadas que acionou o evento de envio do formulário, há uma função de um script externo. Para evitar ataques XSS / CSRF , o navegador deixa o campo Origem vazio e adiciona bytes aleatórios à geração do token (caso P9 ). Como resultado, o usuário na nova página repentinamente se torna não autorizado e não pode concluir a operação. Isso pode ser confuso para desenvolvedores acostumados a usar CDNs.

2.7 Cenários de protocolo

Aqui estão os principais cenários prováveis ​​do usuário que trabalha com o site, afetando todas as situações possíveis e os estágios de sua implementação (login anônimo, "lembre-se de mim", "esqueça-me"), passe a usar uma chave permanente, autorização e saída, registro e autenticação de dois fatores, exportação / importação de chaves, substituição de chaves etc.)

Um exemplo de configuração de acesso ao token com base no arquivo .htaccess.

 <Directory "/var/www/html"> AuthType CSI AuthName "Restricted Content" AuthTokensFile /etc/apache2/.csi_keys Require valid-user </Directory> 

 cat /etc/apache2/.csi_keys 

 # # Client Self Identification tokens file # # CSI-Domain-Key UserName Role 84bc3da1b3e33a18e8d5e1bdd7a18d7a166d77ac1b46a1ec38aa35ab7e628ab5 MelnikovIN admin 6d7fce9fee471194aa8b5b6e47267f0348a24b70a0b376535542b996af517398 BoshirovAM user 

2.7.1 Algoritmo para calcular possíveis tokens de usuário de um site usando uma chave conhecida

Se conhecermos a chave de domínio K, podemos calcular facilmente o possível token "válido" T do usuário que virá com suas solicitações. Para isso, é necessário que a condição seja atendida: o iniciador das solicitações, o receptor das solicitações e o contexto de execução devem corresponder e ser iguais ao domínio. Em outras palavras, se tivermos o nome de domínio vsphere.local, então:

 Sender = Recipient = Context = vsphere.local 

A partir daqui, o token original (bruto) é calculado como:

$$

Após a transmissão, o token original ficará mais protegido. Os 128 bits inferiores do token serão hash com o sal passado no cabeçalho da solicitação CSI-Salt ^* . Assim, o site verá o seguinte token:

$$

Onde Hi é os 128 bits mais altos, Lo é os 128 bits mais baixos do token original.
Geralmente, para consoles de gerenciamento fechados em uma rede corporativa, os consoles da Web não carregam scripts externos, quadros etc. Portanto, essa condição será atendida na maioria dos casos.

---

^{* Para o método de formação de sal, consulte a seção "Procedimento de troca de sal entre o navegador e o servidor".}

2.8 Processando tokens no servidor

Enviando um token para o servidor (sem chaves)

Permanent

O navegador bloqueia a chave do cliente. O usuário deseja que o site lembre-se do cliente por mais de uma sessão. Se o token do usuário deve ser armazenado em seu banco de dados é uma decisão do servidor. Retornamos CSI-Token-Action: success ou CSI-Token-Action: abort ao cliente.

Enviando um token com uma chave Logout

Indica que o token atual não será mais usado pelo navegador. É enviado quando o usuário clica em "Sair" no navegador ou fecha a guia e a opção é configurada (sair automaticamente ao fechar a guia) ou se recusa a usar uma chave fixa ("esqueça-me neste site").

Autologin, a propósito, não deveria ser. Por razões de segurança.

Enviando um token com uma chave Change-To

Vamos chamar o token antigo T, o novo - T '.

IMPORTANTE: como o novo token T ', o valor real do token é enviado (pela primeira vez, para os não registrados), enquanto o token antigo é enviado com hash (os 128 bits mais baixos).

---

^{* , .}

2.9 -

Como mencionado anteriormente, os sites podem interagir com outros sites parceiros ou seus subdomínios para fornecer ao usuário algumas das funcionalidades. O exemplo mais comum é quando, no site site.ru, alguns recursos são carregados dos subdomínios img.site.ru, parte do download.site.ru e outra parte de outros.

Nesse caso, o site site.ru precisa ser capaz de informar os domínios de seus parceiros sobre quem exatamente solicitações são feitas. De fato, se você está autorizado no site.ru, isso não o autoriza automaticamente em outros sites, incluindo subdomínios do site. Eles verão outros tokens seus.

Vamos ver como o token é calculado e como isso pode nos ajudar.
Permita que o usuário efetue login no site.ru com uma chave permanente e tenha um token:

$$

Todas as solicitações provenientes da página do site site.ru até o domínio site.ru e causadas por:

• tags de recursos da página (estática ou dinâmica nativa)
• scripts próprios

terá um token T ₁ (consulte as regras R1 , R4 , RB ). Essas são solicitações legítimas para site.ru.

Agora deixe o cliente baixar o arquivo restrito da página site.ru, mas o link leva a download.site.ru. Nesse caso, o subdomínio receberá o seguinte token (regras R1 , R4 ):

$$

Exatamente o mesmo token download.site.ru receberá se uma solicitação ajax da página site.ru for executada nele (regras de RB , RC ).

Outro domínio de domínio receberá um token:

$$

Porém, observe que, se as condições para o atendimento de solicitações não forem alteradas, para um determinado pacote de domínios A, B, C, o navegador sempre gerará um token constante. Para que possamos realizar a identificação entre domínios. Por exemplo, assim.

No site.ru, fazemos solicitações ajax para subdomínios. Passamos o ID do identificador! = T1 _do usuário, emitido pelo site.ru. Os subdomínios receberão tokens T _x para o mesmo usuário . Cada um dos subdomínios criará um monte de seu token com o ID do usuário. Os subdomínios já compartilharão informações sobre o ID do usuário e seus direitos com solicitações de servidor para servidor.

O grupo é feito uma vez. Posteriormente, os subdomínios serão guiados por seus próprios tokens, conforme eles também serão permanentes para a chave permanente site.ru.

3 Recomendações de segurança

3.1 Proteção das principais informações contra acesso não autorizado

O protocolo de autorização proposto protege o usuário contra keyloggers que roubam suas senhas, porque o esquema proposto não usa senhas.

Porém, maneiras de proteger chaves de comprometimento devem ser consideradas com mais detalhes.

As chaves podem ser comprometidas por:

• copiar informações importantes por malware (acesso remoto)
• acesso direto ao arquivo com as principais informações "offline" (acesso direto)
• no momento da distribuição entre dispositivos

Supondo que as principais informações sejam armazenadas em um cartão inteligente (consideramos essa opção na seção "Mobilidade da conta" ), a tarefa de proteger as principais informações é transferida para o chip. É verdade que existe uma vulnerabilidade aos keyloggers que podem interceptar o código PIN inserido; Bem, inconveniente de usar.

Além dos cartões inteligentes, a criptografia simétrica pode ser usada para proteger contra o acesso direto às informações principais. Mas a questão é: qual chave levar para criptografia?

Se essa chave é gerada com base na senha do usuário, em primeiro lugar, temos uma vulnerabilidade à seleção da senha “offline” e, em segundo lugar, de fato, do que eles deixaram, chegaram a isso: “novamente algumas senhas”.

Uma opção mais correta é costurar de maneira especial ^*essa chave no conjunto do navegador (ou em uma de suas bibliotecas especializadas). Cada atualização do navegador altera a chave e sua localização no arquivo compilado. Essa abordagem não dará 100% de garantia de proteção, mas complicará seriamente a tarefa de descriptografia. Primeiro, o invasor precisará descobrir a versão exata da montagem, depois encontrá-la, desmontar e descobrir como a chave é montada.

Além disso, as próprias chaves de domínio devem ser armazenadas diretamente em um arquivo separado e não em conjunto com a configuração para uso (ou seja, apenas as chaves e nada mais). Então, sua descriptografia por seleção de chave (de conjuntos conhecidos) será impossível, porque é impossível distinguir uma chave descriptografada corretamente de uma sequência aleatória de bytes. Em seguida, as tentativas de selecionar uma chave mestra sem conhecer a versão exata do conjunto do navegador e desmontar diretamente seu código serão impossíveis.

Você pode usar a opção combinada: criptografia com a chave do navegador + criptografia com a senha do usuário da conta do SO (se a API do SO permitir). Além disso, a chave é sempre gerada em tempo real. Então a força bruta offline se tornará ainda mais cara.

Além disso, depois de alterar a senha do usuário no sistema operacional, a chave também será alterada. E se você não descriptografar a chave antiga, isso será protegido contra situações em que o administrador do computador altere sua senha para obter acesso à sua conta e executar ações em seu nome. Situações do tipo: largou o emprego.

Você primeiro fará uma cópia de backup das chaves (exportará as chaves para um arquivo). A menos, é claro, que você já tenha feito isso antes ao distribuir chaves para outros dispositivos.

---

^{* Por exemplo, uma chave de 32 bytes é distribuída aleatoriamente na seção 64K de um arquivo executável. E apenas o código fonte sabe como coletar a chave estimada desses bytes.}

3.2 Sobre senhas como chaves de domínio

Em uma das versões iniciais do protocolo, a chave do domínio pode ser gerada com base na senha do usuário. O algoritmo foi complicado, excluindo chaves duplicadas para domínios diferentes para a mesma senha.

Isso foi posicionado como uma maneira conveniente de contas de mobilidade. Digite uma senha e não se preocupe com nada. Mas então aconteceu o seguinte:

1. , «» , , . , -, .
   
   (), 8- , , .: ~!@#$%^&. : 26 + 26 + 10 + 8 = 70 . 8- 70 ⁸ .
   
   , , 10 ¹² . 70 ⁸ / 10 ¹² = ~576 . I.e. ~10 . 5 . 10- 15 . 10 , 1-2 .
   
   , .
2. , .
3. , . I.e. ( SHA-2).
4. , , , . .

3.3 /

E se eu perder a chave mestra?

Isso pode acontecer se você alterar sua senha ou reinstalar o sistema operacional. Quais são os riscos?

Bem, você não chegará aos sites onde estava antes. Perca seu histórico de compras em lojas on-line, seus anúncios em sites on-line, carma nos fóruns. Isso não importa.

No entanto, quem impede o procedimento de recadastramento com um novo token e o confirma através do número de telefone indicado no mesmo anúncio? Acontece que o site precisa fazer uma forma de re-registro do token (um análogo de "recuperação de senha")? Onde está a prometida ausência de "todo tipo de formas"?

De fato, um site que precisa não apenas identificar o visitante, mas também saber quem ele realmente é, terá quefaça um formulário de inscrição. Na verdade, este formulário pode ser usado para re-registro. Você especifica exatamente os mesmos dados de antes (email, celular). Confirme se você possui esses dados (carta, SMS). O sistema vê que essa conta já existe, os dados são 100% seus, mas o token é diferente - ele reescreve o token.

Ainda assim, é melhor não perder a chave mestra.

Como prevenir a perda? Crie uma cópia de backup, proteja-a com uma senha e armazene-a em mídia descartável. Além disso, na verdade, como é feito com as chaves do bitcoin. Em princípio, você pode converter as chaves mestras em formato impresso e salvá-las em um pedaço de papel. Para esse assunto. E, em seguida, restaure pela entrada manual. Mas isso é para pessoas bastante "paranóicas" como eu.

Mas e se uma chave mestra for roubada de mim?
Isso já é sério. Embora as recomendações descritas aqui para armazenar a chave mestra (não incluídas no protocolo) as protejam contra violações diretas, keyloggers e trojans, no entanto, o risco de comprometer a chave mestra permanece. Infelizmente, a proteção perfeita não existe. A chave pode ser invadida diretamente da memória do navegador através de uma vulnerabilidade de mecanismo javascript. Como exemplo. Ou você perde seu telefone celular ...

Então, quais são os riscos de roubar uma chave mestra?

É essencial receber informações sobre você e até mesmo agir em seu nome. Obtenção da capacidade de um invasor efetuar login sob você e no modo de leitura para obter acesso a informações confidenciais. Calmo e quieto.Ou baixe todos os seus vídeos particulares de colegas de uma vez. É desagradável para você. Fãs de selos se alegram.

Aqui você precisa se registrar rapidamente com uma nova chave em sites importantes. E, se algo terrível aconteceu, registrar seu novo token no banco de dados do provedor de serviços de uma maneira oficial é a única opção certa. Você pode pensar em vários métodos de registro: desde a fixação em papel em uma carta oficial até um aplicativo através do serviço de suporte técnico do site, com confirmação de sua identidade de maneiras aceitáveis. Mas isso é apenas para sites sérios, como bancos online.

Maneiras de minimizar riscos. O uso de chaves individuais para domínios (mas isso reduz a mobilidade das contas). Autenticação de dois fatores via canais independentes. O site mostra os endereços IP e dispositivos de onde a conexão estava da última vez, para que você ao menos note um comprometimento.

4 Ataques ao regime de autorização

4.1 Rastreamento de usuário

Um site confiável pode mesclar descaradamente informações sobre você com outros sites. Na Internet, existem sites de colecionador que agregam essas informações e as vendem para todos. Métricas Yandex, Google Analytics - um site raro fica sem elas.

Para que dois sites diferentes possam determinar que estão trabalhando com o mesmo cliente, duas técnicas são usadas:

1. ( , ).
2. ( ) .

Há uma pequena desvantagem no Esquema 2: não o usuário é identificado , mas o navegador. Mas muitas vezes o navegador == cliente.

Parece que o token é mais adequado para uso no esquema número 2. Afinal, se o usuário permitir "lembrar-se" de dois sites (atuando como um par), nosso token permanente poderá atuar como uma "impressão digital", não apenas o navegador, mas o próprio usuário. O problema para sites aqui é que eles receberão tokens diferentes .

Mas os sites podem tentar aplicar também o esquema n ° 1. Em seguida, o seguinte será o resultado.

Site 1 recebe do código do navegador H ₁ e Site 2 é realizada no contexto de um site 1 - H Código ₂ . Parece que agora os sites podem formar um par (H ₁ , H₂ ) e até mesmo passá-lo para algum site agregador.
Deixe que haja outro site 3, emparelhado com o site 2, tentando rastrear você. O site 3 receberá o token H ₃ do navegador e o site 2, executado no contexto do site 3, receberá o token H _{2 '} ! = H ₂ (veja como os tokens são formados). Como resultado, é impossível combinar os dados obtidos, porque eles não têm partes sobrepostas.

Mas isso não significa que os sites não poderão usar um navegador de impressões digitais para monitorar . Ele afirma apenas que o próprio esquema de geração de tokens é bastante confiável e protege contra rastreamento.

Opção de proteção:Saia dos sites com os quais você terminou de trabalhar. O navegador pode fazer isso automaticamente quando você fecha a guia.

4.2 Ataque XSS

XSS é um tipo de ataque que envolve a introdução de código malicioso na página do site vítima.com. Por exemplo, por meio de um script afiliado ou de uma CDN invadida de uma estrutura popular.

O código malicioso pode usar a autorização do usuário no site para obter acesso autorizado a ele ou roubar dados de autenticação do usuário. O código malicioso pode ser inserido em uma página por meio de uma vulnerabilidade em um servidor Web (hacking trivial), por meio de redes afiliadas (fontes não confiáveis), por meio de uma vulnerabilidade no computador do usuário (rastreamento por Trojan).

A principal proteção contra esses ataques para o nosso esquema de autorização são regras especiais para gerar o campo Origem ao calcular tokens.

Vulnerabilidade: para XSS armazenado (quando o script é inserido diretamente no site atacado e carregado a partir dele como resultado da invasão do servidor), a proteção não funciona. Porque o navegador não conseguirá identificar um script como "externo". O mesmo problema ocorrerá quando um invasor proxies o tráfego cliente-servidor.

4.3 Ataque do CSRF

A vítima visita o site evil.com, criado por um invasor. Em seu nome, uma solicitação (GET / POST / HEAD / PUT / DELETE) é executada em um site em que o usuário já está autorizado (por exemplo, em um servidor do sistema de pagamento). A solicitação em si realiza algum tipo de operação maliciosa (por exemplo, transferência de dinheiro para a conta do invasor). De acordo com a supervisão dos desenvolvedores, o site não verifica os campos do Referer e não solicita informações de verificação adicionais do usuário. Como resultado, o ataque foi bem sucedido.

O esquema de autorização de site proposto suprime a maioria dos cenários de ataque CSRF, devido ao algoritmo de geração de token. Qualquer solicitação entre sites resultará no site atacado receber um token inválido do usuário. Como resultado, nessa situação, o usuário do site atacado será anônimo e anônimo. Mesmo uma tentativa de executar uma solicitação GET inofensiva de um site atacante para um atacado (upload de uma foto) resultará no recebimento de um token inválido.

Isso deve simplificar bastante a vida dos desenvolvedores de sites.

4.4 Rastreando usando SSO

Dois sites S ₁ e S ₂ , nos quais o usuário confia e possui chaves para eles, decidem aplicar uma tecnologia semelhante ao SSO para rastreamento do usuário. Mas desde você não pode incorporar um site em outro (um deles receberá um token inválido), não pode abrir o site de um parceiro com um script (pelo mesmo motivo) e, em seguida, o site S ₁ decide usar uma técnica complicada.

Em uma das páginas, ele coloca uma etiqueta translúcida A, cobrindo a janela inteira. O link leva ao site S ₂ , e o identificador do usuário (de S ₁ ) e o token H _{1 são} transmitidos no endereço . O usuário não vê o link. Ao clicar em qualquer área do site S ₁ , inicia a abertura de uma nova guia no site S ₂.

Atualmente S ₂ não recebe um token válido. O recarregamento automático com uma tag também não o ajudará

 <meta http-equiv="refresh" content="0"> 

ou script.

Mas o S ₂ pode criar a tag A em toda a página na forma de um botão Fechar falso:

Esse link primeiro recarrega o site e depois o fecha. No momento da reinicialização, o navegador envia o token H ₂ já válido para o site S ₂ (porque a regra 2.4 P1 foi seguida: o usuário abriu pessoalmente os dois links). Como resultado, S ₂ receberá informações sobre as ações de seu usuário no site S ₁ , associará o token H ₁ ao seu H ₂ e enviará ao H _{2 uma} solicitação entre servidores para S ₁ . No futuro, os sites S ₁ e S ₂ poderão trocar qualquer informação sobre o usuário por troca de servidor, conforme agora eles podem identificá-lo de forma única e mutuamente separados um do outro

.

Os usuários móveis são particularmente vulneráveis ​​a esse ataque, pois tentar fechar uma página desnecessária pode clicar acidentalmente em um link falso que ocupa toda a tela do celular.

Método de proteção: interrompa automaticamente a sessão quando a guia estiver fechada. Em seguida, o site S ₂ não pôde receber um token válido até que o próprio usuário efetuasse login nele. É verdade que isso não protege contra situações em que o próprio usuário abriu as guias e efetuou login em S ₁ e S ₂ . E só então os sites conduziram esse ataque.

4.5 Compromisso de chave para SSO

Permita que uma conta de usuário em um servidor de autenticação que suporte SSO seja comprometida. Avaliaremos os possíveis riscos com nosso esquema de autenticação.

Os tokens para cada site são calculados individualmente com base nas chaves de domínio.

Comprometer uma chave de domínio não compromete automaticamente todas as outras.

A maioria dos sites em que você efetuou login anteriormente usando o SSO provavelmente salvará seu token com o seu perfil no servidor SSO no banco de dados. Em nosso esquema, o site simplesmente puxa um token do banco de dados e o reconhece. I.e.O servidor SSO não é mais necessário nesses sites - ele executou sua função no estágio de registro.

Em outras palavras, você não perde automaticamente todos os seus acessos de uma só vez. Um invasor será identificado nos mesmos sites que outra pessoa.

Uma tentativa de reconduzir a autenticação entre domínios também não ajudará o invasor: o site deve bloquear as tentativas de criar uma nova conta com o antigo usuário de ID do SSO e o novo token do site. Ou, tentativas de reescrever o token do usuário para um ID existente no processo SSO devem ser bloqueadas. O fato disso deve causar suspeitas razoáveis ​​no lado do site.
Um token de usuário pode ser alterado legalmente de apenas uma maneira (consulte. “Cenários de operação do protocolo” ).

Risco.Se o site não salvar seu token e perfil em seu banco de dados, mas se basear inteiramente no mecanismo SSO, o invasor precisará executar apenas a autenticação entre domínios para efetuar login usando seu nome.

Minimização de riscos em caso de comprometimento. Curiosamente, mas essa é a preservação pelos sites de tokens e perfis de usuário do lado deles. Uma tentativa de um invasor de realizar autenticação entre domínios pode causar um conflito entre o antigo usuário de ID e seu novo token. A situação em si, quando o usuário alterou o token de qualquer outra maneira que não a especificada no protocolo, deve ser percebida com suspeita ou completamente rejeitada.

Risco máximo:autorização em seu nome em outros sites (onde você não esteve). Acesso aos seus dados de perfil. Cometer atos ilegais em seu nome. E para que o legítimo proprietário não possa retornar nada, um invasor pode alterar seu token no servidor de autorização de maneira legal. Esse risco, no entanto, coincide com os riscos ao usar os esquemas de autorização tradicionais.

Maneiras de proteção. Recusa em usar o SSO (especialmente porque o esquema proposto foi concebido como uma maneira de se afastar dos esquemas de autenticação centralizados). Use vários SSOs (não guarde todos os ovos em uma cesta!).

Se o SSO suportar autenticação de dois fatores com autenticação por outros atributos (email, telefone), existe a possibilidade de recuperar o controle sobre a conta do servidor de autorização.

4.6 Compromisso de token durante a transferência

É claro que o mecanismo proposto para os tokens de hash durante a transferência não oferece uma garantia de 100% de sua proteção. Um invasor pode interceptar o tráfego da vítima no momento da transferência de um token inseguro (no momento do registro primário da chave permanente), como exemplo. E então use-o.

Portanto, o uso de SSL é incentivado. Mas não tome HTTPS como uma panacéia. Este protocolo também é exposto, assim como HTTP. Só um pouco mais.

É verdade que uma transferência tão rara de um token aberto, bem como o uso de um token individual para cada domínio, reduz o risco de explorar a vulnerabilidade. No entanto.

Outro perigo é a interceptação e reutilização do token na sessão atual do usuário. Como eu disse anteriormente, o ideal é que o token seja hash com um novo sal a cada solicitação do cliente. No entanto, isso eliminará a possibilidade de processamento paralelo de solicitações no servidor e impossibilitará o envio de solicitações paralelas do cliente. Calcular e verificar hashes geralmente é uma operação cara que reduz o desempenho.

Além disso, o token passado no cabeçalho nunca deve estar disponível no Javascript. Semelhante ao Cookie com o sinalizador HttpOnly. Mesmo ao receber solicitações de ajax por scripts.

Método de operação: interceptando a solicitação de um usuário, extraindo o valor atual do token, enviando outra operação com o mesmo token (como em nome do mesmo usuário). É verdade que o sistema clássico baseado em cookies de sessão também é vulnerável a esse tipo de ataque.

Método de proteção: confirmação de operações significativas através de outros canais de comunicação, por exemplo, via SMS ou correio; pré-registro do token por outros canais de comunicação (certificado em papel, como exemplo).

4.7 Hackeando um site e comprometendo tokens

Sites de hackers ocorrem constantemente. Até sites grandes e bem protegidos quebram. Existem muitas maneiras de invadir: de uma injeção trivial a um "dreno" interno. Portanto, o comprometimento do seu token em qualquer site é um evento muito provável.

Mas o protocolo proposto, da mesma forma, torna o evento de invasão do site o menos doloroso para você.

O comprometimento do token não leva ao comprometimento da chave do domínio com base na qual foi calculado. Além disso, esse evento não leva ao comprometimento de seus outros tokens . E, nesse caso, o acesso a outros sites permanece inacessível.

Isso é especialmente agradável quando as chaves são feitas para a maioria dos sites usando uma chave mestra: é impossível restaurá-la por engenharia reversa.

Mas, ao mesmo tempo, é impossível usar a chave de domínio cujo token foi comprometido, por razões óbvias. Tem que mudar a chave.

A chave do domínio em que ocorreu o vazamento oficial pode ser feita com base em um número aleatório ou com base em uma chave mestra, com a adição de um número de versão:

$$

Conclusão

Vários de meus amigos a quem mostrei o artigo me fizeram essencialmente a mesma pergunta: "Qual é a principal coisa aqui?"


Oh, não há chip principal! Infelizmente.Mas há vários detalhes que tornam o protocolo mais lucrativo do que o esquema tradicional de login / senha.

1. Você provavelmente notou esse pop-up irritante em muitos sites.

“Nosso site salva cookies! Coloque o capacete e fique vigilante, porque o irmão mais velho está observando você! Clique em "Sim", porque você ainda não tem escolha. "

Este é outro pop-up para muitos outros igualmente intrusivos e muito necessários. E tudo isso graças ao GDPR europeu (um análogo da nossa lei de DP).

Então aqui. Em nosso esquema, os cookies não são mais necessários para fins de identificação! Da palavra "completamente". O usuário decide se o site deve ser identificado e quando e por quanto tempo. Menos um pop-up irritante, +1 no karma do protocolo.

2. O desenvolvedor não precisa mais executar formulários de autorização e recuperação de senha. Não há necessidade de implementar algoritmos SSO complexos e dominar bibliotecas complexas: OAuth, SAML, Kerberos etc., siga o procedimento para registrar seu site, alterar chaves de autorização, monitorar sua segurança; e se algo deu errado com o SSO, entenda urgentemente: "o que deu errado e por quê". Além disso, o servidor de autorização pode bloquear seu site por razões desconhecidas. Vá descobrir isso. Ontem tudo funcionou, mas hoje ... E aqui basta ler o token no cabeçalho e verificar se existe algum em nosso banco de dados. Simples = confiável .



3. O usuário não precisa inserir e lembrar um monte de senhas. Use os serviços de sites de terceiros ou não se sabe por quem e como os programas são escritos. Você não pode ter medo de acessar um computador por terceiros, keyloggers e cavalos de Tróia. Basta fazer uma cópia de segurança da chave mestra, protegê-la com uma senha e armazená-la em algum lugar em uma unidade flash USB. Como uma carteira de bitcoin. O que não é um recurso?

4. Se o site for invadido, você não arrisca nada. Bem, gere novamente a chave. Embora a senha vazada para os crackers do site possa causar muitos problemas.

5. O protocolo foi criado levando em consideração a experiência de ataques de rede conhecidos. Sua arquitetura já inclui proteção básica contra XSS, CSRF. Novamente, os webmasters acharão mais fácil desenvolver sites. E seus usuários - mais calmos.

6. Independência do protocolo de um provedor de serviços específico e seus caprichos. O protocolo te liberta.

7. Finalmente, o protocolo proposto reivindica o futuro padrão aberto . E o padrão, se adotado pelos participantes, impõe obrigações de implementar a funcionalidade de acordo com a especificação e de não cercar o farm coletivo de suas próprias decisões de autorização, inventando novamente a forma de login, registro, recuperação de senha e logout. E não mexa com hash de senha ou injeção de SQL.

E o mais importante, como qualquer padrão aberto, ele pode e deve ser verificadoespecialistas independentes. Mesmo que o autor da versão original do protocolo tenha “estragado” os detalhes, a comunidade online pode identificar oportunamente essa correção. Bem, ou envie meu protocolo para o recado. Infelizmente para mim, e "malvado" para todos os outros.

Acho que devo parar com isso
E. Wiles

---

PS
Você pode se familiarizar com a opção de um artigo completo em um formato offline. Ao escrever o material em Habr, eu poderia fazer erros de digitação. Se você tiver comentários sérios, é melhor verificar o original e deixar comentários no artigo (revisões) nesse arquivo . Envie-me suas alterações no mail sergey201991 [] gmail. Não sou polvo, mas tentarei responder. Vou adicionar vários comentários correspondentes / interessantes a este artigo. Juntamente com as respostas para eles. Uma variante de um artigo de comentário separado não é descartada.

Sim, eu sei que o protocolo pode ter problemas:

1. não há como fazer login na sua conta no dispositivo de outra pessoa se você não tiver uma chave em mãos, mas precisar dela com urgência; senhas são mais convenientes aqui
2. ; , SSO
3. «», - : - ( )
4. -

Em relação à página 1 - Eu estava pensando seriamente em voltar à idéia de gerar uma chave de domínio com base em uma senha, protegendo contra a força bruta, complicando o processo de geração da chave: digamos, aumentando o número de rodadas de hash para 1000. Mas o problema com a possível colisão de senhas para diferentes usuários em um O site me assombra.

Em relação à página 2 - isso é tratado pelo tempo. Você precisa se acostumar com as novas interfaces. No início, não ficará claro, depois será simples. Dê a um homem dos anos 80 um smartphone moderno, ele também não teria descoberto como gerenciá-lo.

Muito obrigado se você ler até o final!