Ferramentas para desenvolvedores · SHA calculadora de hash
Integridade de sub-recursos: como os navegadores usam SHA-384 para verificar scripts
· Fundo
sha-256 base64 APIs do navegador segurança
O atributo de integridade permite que um navegador recuse um script CDN cujos bytes foram alterados. Esta postagem explica o formato do atributo, por que SHA-384 em base64 é a escolha comum e contra o que SRI não pode proteger.
O CDN que pode servir para qualquer coisa — o risco da cadeia de suprimentos SRI foi projetado para
Uma tag de script em uma página da web pode conter um atributo de integridade: `<script src="https://cdn.example.com/lib.js" integrity="sha384-..."></script>`. O valor de integridade é um resumo criptográfico dos bytes do script. Quando o navegador baixa o script, ele calcula o resumo dos bytes recebidos e compara com o atributo de integridade. Se corresponderem, o script será carregado. Se não corresponderem, o navegador se recusa a carregá-lo e relata a falha no console. Isso protege contra um CDN comprometido servindo código modificado ou contra um invasor de rede interceptando e alterando a resposta.
Integridade de sub-recursos (SRI) é uma especificação W3C que se aplica a scripts e folhas de estilo. É a única garantia criptográfica que um navegador pode oferecer sobre o conteúdo de um recurso de origem cruzada: os bytes devem corresponder ao resumo ou o recurso será rejeitado. Isto não prova quem criou o recurso, apenas que não mudou desde que o resumo foi calculado. Para um recurso servido em HTTPS por um CDN respeitável, o resumo fornece uma proteção contra o comprometimento de CDN ou o fornecimento de conteúdo obsoleto em cache especificamente para você.
O atributo de integridade – prefixo do algoritmo, hífen, resumo base64 e suporte para vários hashes
O atributo de integridade possui um formato específico: nome do algoritmo, hífen, resumo em base64. Exemplo: `integrity="sha384-JZDdQnrrAMe+sxxpn47in+PwhkxrCrt4SNvt+xWqV3zPJUkeFF0Qq/wNtuvNqPP5"`. O nome do algoritmo pode ser SHA-256, SHA-384 ou SHA-512. Base64 é a codificação, não hexadecimal; esta é uma escolha deliberada da especificação SRI. Base64 é mais compacto que hexadecimal (cerca de 33% mais curto para o mesmo resumo), o que é importante ao incorporar atributos HTML. O hífen separa o nome do algoritmo do resumo. Vários valores de integridade podem ser listados, separados por espaços: se algum deles corresponder, o recurso será aceito.
Por que SHA-384? A especificação SRI permite SHA-256, SHA-384 e SHA-512. SHA-384 tornou-se o padrão da comunidade porque oferece um saldo size/security. SHA-256 é menor (32 bytes, 44 caracteres em base64), mas SHA-384 é mais largo (48 bytes, 64 caracteres em base64) e não aumentou significativamente o tamanho do atributo em comparação com SHA-256. SHA-512 está disponível, mas raramente é usado porque seu resumo maior não parecia necessário para este caso de uso. A escolha de SHA-384 é histórica e pragmática, não um reflexo de propriedades de segurança superiores (todos os três são criptograficamente fortes para este propósito).
SHA-384 é oferecido e produz o material base64 necessário; a preferência da comunidade não é inferida da ferramenta
A codificação Base64 em SRI é base64 padrão, não base64url. Base64 padrão usa caracteres + e /, que são válidos em atributos HTML sem codificação percentual, embora tenham significados especiais em URLs e dados de formulário. O formato SRI foi projetado para atributos HTML, não para URLs, portanto o base64 padrão é apropriado. Se você estiver construindo um valor de integridade manualmente, você calcula o resumo SHA-384 (uma sequência de bytes), codifica esses bytes como base64 padrão, acrescenta `sha384-` e cola no atributo de integridade.
O navegador executa as mesmas etapas ao contrário: extrai o base64 do atributo de integridade, decodifica em bytes para recuperar o resumo, calcula SHA-384 dos bytes do script baixados e compara os dois valores do resumo. Eles devem corresponder exatamente; uma diferença de um único bit no resumo causa rejeição. Não há correspondência difusa ou crédito parcial: a integridade é binária.
O comportamento SRI de origem cruzada requer documentação do navegador além desta calculadora de hash
SRI requer CORS em respostas de origem cruzada. Se você carregar um script de uma origem diferente, o servidor deverá responder com `Access-Control-Allow-Origin: *` ou um cabeçalho de origem específico que inclua o seu. Sem os cabeçalhos CORS, o navegador não pode verificar o SRI, porque sem CORS ele não pode confirmar se o corpo da resposta corresponde ao que o servidor pretendia enviar. Os cabeçalhos CORS são a declaração do servidor de que esta resposta é segura para verificação; SRI é a sua verificação de que os bytes estão corretos. Juntos, eles formam um compromisso na cadeia de suprimentos: o servidor permite que você verifique o conteúdo, e você o faz.
Se um script de origem cruzada não tiver cabeçalhos CORS e tiver um atributo de integridade, o navegador fará o download dele (se os scripts dessa origem forem permitidos pelo CSP do site), mas não verificará a integridade. O script será carregado como se o atributo de integridade estivesse ausente. Isto não é uma falha de SRI; é um limite de segurança: você não pode verificar uma resposta que não consegue ler.
O que acontece em caso de incompatibilidade — o navegador bloqueia o recurso e reporta no console
Quando o navegador detecta uma incompatibilidade de integridade, ele se recusa a executar o script e registra uma mensagem no console do navegador. A mensagem normalmente nomeia URL, o hash esperado e o hash computado. A falha é atômica: ou o recurso é carregado como está ou é totalmente rejeitado. Não há carregamento parcial ou fallback. Se um site se basear nesse script e for rejeitado, o site poderá quebrar. Isto é intencional: entregar código errado é pior do que não entregar nenhum código, e falhas silenciosas permitem que os ataques persistam indefinidamente.
Testar uma configuração SRI é simples: abra o console do navegador, carregue a página e procure mensagens sobre incompatibilidades de integridade. Se você encontrar uma incompatibilidade, compare o hash computado mostrado no console com aquele no seu atributo de integridade. Se não corresponderem, recalcule: o script pode ter sido atualizado e você precisa de um novo resumo.
Exemplo resolvido – calcular um resumo para um script e formatá-lo em um valor de integridade, incluindo a etapa base64
Calcular um resumo SRI manualmente requer apenas os bytes de script e uma ferramenta de hash. Baixe o script, cole-o na calculadora de hash ToolAcre SHA, selecione SHA-384, copie a saída base64 (não o hexadecimal), acrescente `sha384-` e cole no atributo de integridade. Se o script for grande, usar curl ou wget para salvá-lo em um arquivo e depois ler o arquivo será mais rápido do que colar. Para scripts embutidos (em uma tag `<script>` em HTML em vez de em URL), SRI não é aplicável; scripts embutidos são sempre confiáveis por definição. SRI é para recursos externos.
Um exemplo resolvido: suponha que você queira carregar o jQuery de um CDN com SRI. Encontre o script URL, baixe-o (ou use curl para buscá-lo), cole os bytes na calculadora ou use `sha384sum` na linha de comando, obtenha o resumo SHA-384 como base64 e formate como `sha384-[base64-digest]`. Cole no atributo de integridade da tag de script. Carregue a página e verifique se nenhum erro de console aparece.
O que isso não cobre: scripts que mudam intencionalmente e sites como ToolAcre que não carregam nenhum script externo e, portanto, não têm nada para fixar
SRI não protege contra todos os ataques à cadeia de suprimentos. Ele protege contra a alteração de bytes após o cálculo do resumo, mas não contra o cálculo do resumo a partir do código comprometido. Se um CDN for comprometido antes de você calcular o resumo, SRI não poderá ajudar. O resumo é tão confiável quanto a fonte a partir da qual você o computou. Para obter garantia máxima, calcule resumos da fonte original (as versões do GitHub da biblioteca, por exemplo) e use esses resumos ao carregar de um CDN. O resumo se torna um compromisso do mantenedor durante o processo de lançamento.
SRI também não protege contra uma rede comprometida no momento em que você calcula o resumo ou contra uma máquina de desenvolvimento comprometida. Ele protege apenas contra alterações no script entre o momento em que o resumo é criado e o momento em que o navegador carrega o script. Para garantia contínua, algumas implantações usam assinatura de versão além de SRI: a versão é assinada por uma chave do mantenedor, você verifica a assinatura, calcula o resumo dos bytes verificados e usa isso em SRI.
Este artigo não afirma o inventário de scripts externos de todo o site de ToolAcre a partir de fontes de hash
A calculadora de hash ToolAcre SHA emite o resumo em base64 padrão diretamente (como saída `base64` da função `toBase64()`). Para converter para o formato SRI, acrescente o nome do algoritmo e um hífen: `sha256-`, `sha384-` ou `sha512-`. A calculadora não aplica esse prefixo automaticamente porque os hashes aparecem em muitos contextos (git, Docker, npm, URLs) onde o nome do algoritmo é separado ou codificado de forma diferente. O limite é claro: a calculadora faz hash do texto UTF-8 que você cola, não de arquivos ou chaves binárias. Ele gera hexadecimal e base64. Você escolhe qual usar com base no seu contexto. Para SRI, base64 é exigido pela especificação. Para git e outras ferramentas, hex é convencional. Para npm e Go, base64 é usado. A escolha da codificação é sua; os bytes de resumo são os mesmos.
SRI continua sendo uma das poucas verificações criptográficas que um navegador pode realizar no lado do cliente sem uma autoridade centralizada. A computação se resume a uma ferramenta confiável como a calculadora SHA de ToolAcre e verificá-los em relação aos recursos carregados é uma maneira acessível de proteger um site contra certos ataques à cadeia de suprimentos. A proteção é tão boa quanto o resumo; recalcular após cada atualização do recurso externo e testar se o navegador carrega o script sem rejeitá-lo.