Aprender
Conceitos de redes e segurança, explicados com clareza.
Explicações práticas dos conceitos por trás das ferramentas. Cada artigo é escrito para construir entendimento genuíno, não apenas para definir um termo.
F5 hub do fabricante →Fortinet hub do fabricante →Netskope hub do fabricante →Extreme Networks hub do fabricante →
Certificados e PKI (14)
Anatomia de um Certificado X.509
O que vive dentro de um certificado TLS, como os bytes ASN.1/DER são estruturados, o que as extensões v3 de fato controlam, e por que decodificar um certificado não é o mesmo que confiar nele.
Certificados e PKILerPEM, DER e os formatos de arquivo de certificado
Por que o mesmo certificado vem em tantas formas de arquivo, o que PEM e DER de fato são, e o que .crt, .pem, .pfx e .p12 realmente contêm.
Certificados e PKILerRequisições de assinatura de certificado e como certificados são emitidos
O que uma CSR contém, por que sua chave privada nunca deixa sua máquina, como uma CA valida e emite, e como o ACME automatiza toda a troca.
Certificados e PKILerComo a validação de certificados de fato funciona
Os passos que um cliente executa para decidir que um certificado é confiável: construir a cadeia, checar assinaturas e datas, casar o nome e impor restrições.
Certificados e PKILerRevogação de certificados: CRL, OCSP e certificados de vida curta
Por que um certificado às vezes precisa ser cancelado antes de expirar, por que os sistemas clássicos de revogação funcionam mal, e por que a indústria está encolhendo os tempos de vida dos certificados em vez disso.
Certificados e PKILerAuthority Information Access: As URLs de OCSP e CA Issuers
A extensão AIA carrega dois tipos de ponteiro: onde perguntar se um certificado foi revogado (OCSP) e onde buscar o certificado do próprio emissor (CA Issuers). Para que serve cada um, por que são fáceis de confundir e o que o inspetor mostra.
Certificados e PKILerOCSP Must-Staple: Fechando a Brecha do Soft-Fail
A checagem OCSP em tempo real tem uma fraqueza fatal: quando o respondedor está inacessível, os clientes geralmente prosseguem mesmo assim. O OCSP stapling e o sinalizador Must-Staple são a correção. O que a extensão TLS Feature declara, e o risco operacional que ela carrega.
Certificados e PKILerA era dos 47 dias: como os tempos de vida dos certificados TLS estão encolhendo
O cronograma SC-081v3 do CA/Browser Forum reduz a validade máxima de certificados TLS públicos de 398 para 47 dias até 2029, em três etapas. Quais são as fases, por que 47, e o que isso faz com o volume de renovações.
Certificados e PKILerACME: como os certificados se emitem e se renovam sozinhos
Como o protocolo ACME automatiza a emissão de certificados de ponta a ponta: a conta, o pedido, os três tipos de desafio, o registro dns-01 que você publica e a etapa de finalizar e baixar que produz o certificado.
Certificados e PKILerJanelas de validade: notBefore, notAfter e a antecedência da renovação
Como o tempo de vida de um certificado é definido por dois carimbos de tempo, como esse tamanho é medido contra o limite, por que validade não é o mesmo que tempo restante, e como escolher uma antecedência para a renovação.
Certificados e PKILerLet's Encrypt: a CA gratuita e seus limites de emissão
O que é a Let's Encrypt, por que seus certificados são de vida curta e como seus limites de emissão realmente funcionam: os limites por domínio registrado e por conta, os limites por conjunto exato e por falha de autorização, e por que as renovações por ARI são isentas de todos eles.
Certificados e PKILerReutilização de DCV e SII: a cadência de validação por trás da renovação
Emitir um certificado significa provar o controle do domínio e, para OV/EV, a identidade da organização. A SC-081v3 encurta por quanto tempo essas provas podem ser reutilizadas, o DCV para 10 dias até 2029, o que remodela a renovação tanto quanto a validade.
Certificados e PKILerRenovar antes da expiração: antecedência, ACME e ARI
Por que a renovação tardia causa quedas, como o ACME automatiza a emissão e a renovação, como a extensão ARI permite que uma AC guie a janela de renovação, e como escolher uma antecedência que deixe espaço para tentar de novo.
Certificados e PKILerPKI pública e privada: quais certificados a SC-081v3 governa
O cronograma dos 47 dias vincula apenas certificados TLS publicamente confiáveis. O que separa a PKI pública da privada, por que as ACs internas estão isentas, e como ler o veredito de conformidade do planejador para um certificado interno.
Certificados e PKILer
| Artigo | Tema | Resumo |
|---|---|---|
| Anatomia de um Certificado X.509 | Certificados e PKI | O que vive dentro de um certificado TLS, como os bytes ASN.1/DER são estruturados, o que as extensões v3 de fato controlam, e por que decodificar um certificado não é o mesmo que confiar nele. |
| PEM, DER e os formatos de arquivo de certificado | Certificados e PKI | Por que o mesmo certificado vem em tantas formas de arquivo, o que PEM e DER de fato são, e o que .crt, .pem, .pfx e .p12 realmente contêm. |
| Requisições de assinatura de certificado e como certificados são emitidos | Certificados e PKI | O que uma CSR contém, por que sua chave privada nunca deixa sua máquina, como uma CA valida e emite, e como o ACME automatiza toda a troca. |
| Como a validação de certificados de fato funciona | Certificados e PKI | Os passos que um cliente executa para decidir que um certificado é confiável: construir a cadeia, checar assinaturas e datas, casar o nome e impor restrições. |
| Revogação de certificados: CRL, OCSP e certificados de vida curta | Certificados e PKI | Por que um certificado às vezes precisa ser cancelado antes de expirar, por que os sistemas clássicos de revogação funcionam mal, e por que a indústria está encolhendo os tempos de vida dos certificados em vez disso. |
| Authority Information Access: As URLs de OCSP e CA Issuers | Certificados e PKI | A extensão AIA carrega dois tipos de ponteiro: onde perguntar se um certificado foi revogado (OCSP) e onde buscar o certificado do próprio emissor (CA Issuers). Para que serve cada um, por que são fáceis de confundir e o que o inspetor mostra. |
| OCSP Must-Staple: Fechando a Brecha do Soft-Fail | Certificados e PKI | A checagem OCSP em tempo real tem uma fraqueza fatal: quando o respondedor está inacessível, os clientes geralmente prosseguem mesmo assim. O OCSP stapling e o sinalizador Must-Staple são a correção. O que a extensão TLS Feature declara, e o risco operacional que ela carrega. |
| A era dos 47 dias: como os tempos de vida dos certificados TLS estão encolhendo | Certificados e PKI | O cronograma SC-081v3 do CA/Browser Forum reduz a validade máxima de certificados TLS públicos de 398 para 47 dias até 2029, em três etapas. Quais são as fases, por que 47, e o que isso faz com o volume de renovações. |
| ACME: como os certificados se emitem e se renovam sozinhos | Certificados e PKI | Como o protocolo ACME automatiza a emissão de certificados de ponta a ponta: a conta, o pedido, os três tipos de desafio, o registro dns-01 que você publica e a etapa de finalizar e baixar que produz o certificado. |
| Janelas de validade: notBefore, notAfter e a antecedência da renovação | Certificados e PKI | Como o tempo de vida de um certificado é definido por dois carimbos de tempo, como esse tamanho é medido contra o limite, por que validade não é o mesmo que tempo restante, e como escolher uma antecedência para a renovação. |
| Let's Encrypt: a CA gratuita e seus limites de emissão | Certificados e PKI | O que é a Let's Encrypt, por que seus certificados são de vida curta e como seus limites de emissão realmente funcionam: os limites por domínio registrado e por conta, os limites por conjunto exato e por falha de autorização, e por que as renovações por ARI são isentas de todos eles. |
| Reutilização de DCV e SII: a cadência de validação por trás da renovação | Certificados e PKI | Emitir um certificado significa provar o controle do domínio e, para OV/EV, a identidade da organização. A SC-081v3 encurta por quanto tempo essas provas podem ser reutilizadas, o DCV para 10 dias até 2029, o que remodela a renovação tanto quanto a validade. |
| Renovar antes da expiração: antecedência, ACME e ARI | Certificados e PKI | Por que a renovação tardia causa quedas, como o ACME automatiza a emissão e a renovação, como a extensão ARI permite que uma AC guie a janela de renovação, e como escolher uma antecedência que deixe espaço para tentar de novo. |
| PKI pública e privada: quais certificados a SC-081v3 governa | Certificados e PKI | O cronograma dos 47 dias vincula apenas certificados TLS publicamente confiáveis. O que separa a PKI pública da privada, por que as ACs internas estão isentas, e como ler o veredito de conformidade do planejador para um certificado interno. |
Codificação e dados (38)
A Anatomia de uma URL
Toda URL é construída a partir do mesmo punhado de partes definidas pela RFC 3986: esquema, autoridade (userinfo, host, porta), caminho, query e fragmento. O que cada parte significa, como um parser as distingue e onde os limites realmente caem.
Codificação e dadosWeb e HTTPLerA Gramática JSON: Seis Tipos e Algumas Regras Estritas
JSON é menor do que parece. O formato inteiro são seis tipos de valor e um punhado de caracteres estruturais, governados por regras mais estritas do que a maioria lembra: sem comentários, sem vírgulas finais e chaves que precisam ser strings entre aspas.
Codificação e dadosLerBytes, pontos de código e UTF-8
A diferença entre um caractere e um byte, por que existem o Unicode e o UTF-8, e o que isso tem a ver com o Base64.
Codificação e dadosLerJSON vs YAML: O Que Converte Limpo e o Que Não Converte
O YAML foi projetado para que todo documento JSON também seja YAML válido, e é por isso que a conversão entre eles geralmente simplesmente funciona. A parte interessante são as bordas: comentários, âncoras, múltiplos documentos e tipos exclusivos do YAML que não têm equivalente em JSON.
Codificação e dadosLerO Que o Tempo Unix Realmente É
O tempo Unix é um único inteiro: o número de segundos desde 1970-01-01T00:00:00Z, a época (epoch). É independente de fuso horário, compacto e ordenável, e por isso sustenta quase todo relógio de sistema, linha de log e timestamp de API. Convertê-lo em uma data de calendário é pura aritmética.
Codificação e dadosLerBase64 e Base64URL, explicados
Como dados binários viram texto seguro para transmitir, por que existe o preenchimento e o que muda na variante segura para URL.
Codificação e dadosLerCoerção de Tipos no YAML e o Problema da Noruega
O YAML adivinha o tipo de todo escalar sem aspas, e seus palpites são surpreendentes: o código de país NO vira false, uma versão como 1.0 vira número, e um código com zeros à esquerda perde os zeros. Conhecer a regra é a chave para uma conversão segura.
Codificação e dadosLerNúmeros JSON e a Armadilha da Precisão
O JSON não impõe limite ao tamanho ou à precisão de um número, mas a maioria dos parsers converte silenciosamente todo número para um float de 64 bits. Essa incompatibilidade corrompe silenciosamente inteiros grandes e decimais exatos, e por isso um formatador deveria preservar os dígitos originais.
Codificação e dadosLerQuery Strings: Parâmetros, Sinais de Mais e Chaves Repetidas
A parte de uma URL após o ponto de interrogação parece simples mas esconde ambiguidade real: como os parâmetros são separados, por que um sinal de mais às vezes significa espaço, como chaves repetidas se comportam e por que não há um único padrão governante.
Codificação e dadosWeb e HTTPLerSegundos, Milissegundos, Microssegundos, Nanossegundos: Distinguindo Unidades de Época
O mesmo instante pode ser escrito como 1700000000, 1700000000000 ou maior, dependendo de o timestamp contar segundos, milissegundos, microssegundos ou nanossegundos. Confundi-los é um bug clássico. Quase sempre dá para saber qual é qual pela magnitude do número.
Codificação e dadosLerBase64URL e o alfabeto seguro para URLs
Por que JWTs e PKCE usam um alfabeto Base64 diferente, os dois caracteres que mudam e o que acontece com o preenchimento.
Codificação e dadosLerChaves Duplicadas em JSON: Legais, Perigosas e Dignas de Detecção
A sintaxe JSON permite que a mesma chave apareça mais de uma vez em um objeto, mas a especificação não diz o que isso significa. Parsers diferentes resolvem isso de formas diferentes, o que torna chaves duplicadas uma fonte silenciosa de bugs e até de problemas de segurança.
Codificação e dadosLerCodificação de URL e Hosts Internacionalizados
URLs são restritas a um pequeno conjunto de caracteres ASCII, então todo o resto é codificado. A codificação percent cuida de caminhos e queries; o punycode cuida de nomes de host não-ASCII. Como ambos funcionam, e por que hosts internacionalizados são uma preocupação de phishing.
Codificação e dadosWeb e HTTPLerJSON e YAML na Prática: APIs, Declarações e Orquestração
A divisão não é aleatória: APIs e declarações máquina-a-máquina tendem a ser JSON, enquanto arquivos de orquestração e pipeline escritos por humanos tendem a ser YAML. Entender por que cada domínio escolheu o que escolheu explica quando converter entre eles é útil.
Codificação e dadosLerO Problema do Ano 2038
Um inteiro de 32 bits com sinal só consegue contar segundos até 2147483647, que cai em 2038-01-19T03:14:07Z. Um segundo depois ele transborda e dá a volta para um número negativo, jogando os sistemas afetados de volta a 1901. É o sucessor mais silencioso do Y2K, e a correção é um inteiro mais largo.
Codificação e dadosLerÂncoras, aliases e merge keys em YAML
O YAML pode definir um valor uma vez e reutilizá-lo com uma âncora e um alias, e mesclar um mapping em outro com uma merge key. Nada disso existe em JSON, então a conversão expande e duplica tudo. Este artigo cobre a sintaxe, o que acontece na conversão, e a armadilha de negação de serviço que eles habilitam.
Codificação e dadosLerEscapes de string e Unicode em JSON
Dentro de uma string JSON, alguns caracteres precisam ser escritos como escapes, e qualquer caractere pode ser escrito como \uXXXX. As regras são poucas mas estritas, e a que pega as pessoas é como caracteres além do plano básico, como emoji, precisam de um par substituto (surrogate pair).
Codificação e dadosLerISO 8601, RFC 3339 e a Data HTTP
Depois que um timestamp Unix é convertido de volta em uma data humana, ele é escrito em um de poucos formatos de texto padrão. O ISO 8601 é o padrão amplo, o RFC 3339 é seu perfil estrito para a internet, e a data HTTP é a exceção. Saber a diferença evita muita dor de cabeça com parsing.
Codificação e dadosLerOnde o Base64 aparece: data URIs, MIME, PEM e Basic auth
Os lugares reais em que binário é embrulhado em texto, o custo de tamanho de fazer isso e por que Base64 em um cabeçalho de autenticação não é criptografia.
Codificação e dadosLerBase32, explicado
Por que o Base32 troca tamanho por um alfabeto sem ambiguidades e insensível a maiúsculas, como funciona seu agrupamento de 5 bits, e onde ele aparece (segredos TOTP, endereços onion, DNS).
Codificação e dadosIdentidade e tokensLerBlock scalars e strings multilinha em YAML
O YAML tem duas formas de escrever uma string multilinha, e elas tratam quebras de linha de modo diferente: o estilo literal as mantém, o estilo folded as transforma em espaços. Indicadores de chomping então decidem o que acontece com a quebra de linha final. Errar isso é por que um script ou certificado embutido sai sutilmente corrompido.
Codificação e dadosLerPor Que o Tempo Unix Ignora os Segundos Bissextos
O UTC ocasionalmente insere um segundo bissexto para se manter alinhado com a rotação da Terra, mas o tempo Unix finge que todo dia tem exatamente 86.400 segundos. Essa simplificação deliberada significa que um timestamp Unix não é uma contagem verdadeira de segundos decorridos desde a época — e é a escolha certa para o tempo civil.
Codificação e dadosLerVírgulas finais, comentários e a família JSON5
O JSON estrito não tem comentários nem vírgulas finais, o que surpreende quem usa um editor que aceita ambos. A razão é que o JSON é um formato mínimo de interchange, e as variantes tolerantes (JSONC, JSON5) são coisas separadas. Saber qual é qual evita arquivos de config que quebram em outra ferramenta.
Codificação e dadosLerCodificação hexadecimal (Base16), explicada
Como o hexadecimal representa cada byte com dois caracteres, por que é a forma padrão de imprimir bytes brutos, e como ele se compara ao Base64 e ao Base32.
Codificação e dadosLerFormatação, minificação e JSON canônico
O espaço em branco não muda o que o JSON significa, então JSON identado e minificado são o mesmo dado. Mas quando o JSON é assinado ou hasheado, os bytes exatos importam, e é aí que entra o JSON canônico: uma forma determinística de serializar o mesmo dado exatamente na mesma string toda vez.
Codificação e dadosLerURLs relativas e como elas resolvem
Uma URL relativa deixa de fora o esquema e o host e é completada contra uma URL base. As regras de como um navegador preenche o resto, e como ./ e ../ e uma barra inicial mudam o resultado, explicam muitos links quebrados e algumas surpresas de segurança.
Codificação e dadosWeb e HTTPLerCodificação por porcentagem (codificação de URL), explicada
Por que as URLs escapam certos caracteres como %XX, quais caracteres é seguro deixar como estão, e em que a codificação por porcentagem difere do Base64.
Codificação e dadosLerURLs enganosas: lendo além dos truques
URLs são uma ferramenta favorita para phishing porque o destino real é fácil de disfarçar. O truque do userinfo, os parâmetros de redirecionamento e os caracteres parecidos, todos fazem um link hostil parecer amigável. Este artigo mostra os disfarces comuns e o único hábito confiável para encontrar o host real.
Codificação e dadosWeb e HTTPLerBase16, Base32, Base64 e codificação por porcentagem comparadas
Um olhar lado a lado para as quatro codificações de texto: seus alfabetos, sobrecarga de tamanho, legibilidade, e quando recorrer a cada uma.
Codificação e dadosLerComo funciona o diff de texto
Um diff encontra o menor conjunto de inserções e remoções que transforma um texto em outro. Por baixo está a maior subsequência comum: as linhas que as duas versões compartilham, na mesma ordem, formam a espinha dorsal inalterada, e todo o resto é uma adição ou uma remoção.
Codificação e dadosTexto e utilitáriosLerComo ler um diff
Como ler um diff linha a linha: linhas inalteradas, adicionadas e removidas, os marcadores de mais e menos, os números de linha dos dois lados, o destaque palavra a palavra e o que ignorar espaços e ignorar maiúsculas realmente mudam. Mais o que um diff não consegue dizer.
Codificação e dadosTexto e utilitáriosLerDiffs em nível de palavra e de caractere
Um diff de linha marca a linha inteira como alterada mesmo quando um único caractere mudou. Diffs em nível de palavra e de caractere destacam exatamente a parte da linha que mudou, o que é muito mais fácil de ler para prosa, linhas longas e edições pequenas. Este artigo cobre a diferença e quando cada lente é a certa.
Codificação e dadosTexto e utilitáriosLerDiffs de três vias e conflitos de merge
Um diff normal compara duas versões e não consegue dizer qual delas mudou. Um diff de três vias adiciona um ancestral comum, que é o que torna o merge automático possível e o que produz os marcadores de conflito <<<<<<< ======= >>>>>>>. Este artigo explica o terceiro insumo e como ler e resolver um conflito.
Codificação e dadosTexto e utilitáriosLerEdições mínimas: por que um diff pode parecer errado
Um diff mostra o menor conjunto de inserções e remoções que transforma um texto no outro. Como o menor conjunto não é único e o algoritmo precisa escolher, um diff pode alinhar linhas de formas contraintuitivas, culpando o bloco errado ou dividindo uma seção movida. Saber disso torna diffs estranhos legíveis.
Codificação e dadosTexto e utilitáriosLerLendo a estrutura do XML
XML é uma árvore de elementos construída a partir de um punhado de partes: uma declaração opcional, elementos com atributos, texto e algumas construções especiais. Uma vez que você consegue nomear cada parte e ver como elas se aninham, ler um documento desconhecido de cima a baixo vira rotina em vez de um jogo de adivinhação.
Codificação e dadosSegurança e WAFLerNamespaces XML explicados
Quando dois vocabulários XML usam o mesmo nome de elemento para coisas diferentes, namespaces os mantêm separados vinculando um prefixo a uma URI única. O prefixo é apenas um atalho local; a URI é a identidade real. Entender essa divisão resolve a maior parte da confusão com namespaces.
Codificação e dadosSegurança e WAFLerXML bem formado vs válido
Boa formação é a linha de base do XML: uma raiz, tags aninhadas e correspondidas corretamente, atributos entre aspas e especiais escapados. Validade é uma afirmação mais forte e separada de que um documento também segue um schema. Um parser rejeita XML mal formado de imediato, que é por que estas regras vêm primeiro.
Codificação e dadosSegurança e WAFLerCDATA, comentários e instruções de processamento
Nem tudo em XML é um elemento. Seções CDATA guardam texto cru que de outra forma precisaria de escape, comentários anotam sem afetar o conteúdo, e instruções de processamento carregam direções para uma aplicação. Reconhecer estas três impede que pareçam ruído misterioso.
Codificação e dadosSegurança e WAFLer
| Artigo | Tema | Resumo |
|---|---|---|
| A Anatomia de uma URL | Codificação e dadosWeb e HTTP | Toda URL é construída a partir do mesmo punhado de partes definidas pela RFC 3986: esquema, autoridade (userinfo, host, porta), caminho, query e fragmento. O que cada parte significa, como um parser as distingue e onde os limites realmente caem. |
| A Gramática JSON: Seis Tipos e Algumas Regras Estritas | Codificação e dados | JSON é menor do que parece. O formato inteiro são seis tipos de valor e um punhado de caracteres estruturais, governados por regras mais estritas do que a maioria lembra: sem comentários, sem vírgulas finais e chaves que precisam ser strings entre aspas. |
| Bytes, pontos de código e UTF-8 | Codificação e dados | A diferença entre um caractere e um byte, por que existem o Unicode e o UTF-8, e o que isso tem a ver com o Base64. |
| JSON vs YAML: O Que Converte Limpo e o Que Não Converte | Codificação e dados | O YAML foi projetado para que todo documento JSON também seja YAML válido, e é por isso que a conversão entre eles geralmente simplesmente funciona. A parte interessante são as bordas: comentários, âncoras, múltiplos documentos e tipos exclusivos do YAML que não têm equivalente em JSON. |
| O Que o Tempo Unix Realmente É | Codificação e dados | O tempo Unix é um único inteiro: o número de segundos desde 1970-01-01T00:00:00Z, a época (epoch). É independente de fuso horário, compacto e ordenável, e por isso sustenta quase todo relógio de sistema, linha de log e timestamp de API. Convertê-lo em uma data de calendário é pura aritmética. |
| Base64 e Base64URL, explicados | Codificação e dados | Como dados binários viram texto seguro para transmitir, por que existe o preenchimento e o que muda na variante segura para URL. |
| Coerção de Tipos no YAML e o Problema da Noruega | Codificação e dados | O YAML adivinha o tipo de todo escalar sem aspas, e seus palpites são surpreendentes: o código de país NO vira false, uma versão como 1.0 vira número, e um código com zeros à esquerda perde os zeros. Conhecer a regra é a chave para uma conversão segura. |
| Números JSON e a Armadilha da Precisão | Codificação e dados | O JSON não impõe limite ao tamanho ou à precisão de um número, mas a maioria dos parsers converte silenciosamente todo número para um float de 64 bits. Essa incompatibilidade corrompe silenciosamente inteiros grandes e decimais exatos, e por isso um formatador deveria preservar os dígitos originais. |
| Query Strings: Parâmetros, Sinais de Mais e Chaves Repetidas | Codificação e dadosWeb e HTTP | A parte de uma URL após o ponto de interrogação parece simples mas esconde ambiguidade real: como os parâmetros são separados, por que um sinal de mais às vezes significa espaço, como chaves repetidas se comportam e por que não há um único padrão governante. |
| Segundos, Milissegundos, Microssegundos, Nanossegundos: Distinguindo Unidades de Época | Codificação e dados | O mesmo instante pode ser escrito como 1700000000, 1700000000000 ou maior, dependendo de o timestamp contar segundos, milissegundos, microssegundos ou nanossegundos. Confundi-los é um bug clássico. Quase sempre dá para saber qual é qual pela magnitude do número. |
| Base64URL e o alfabeto seguro para URLs | Codificação e dados | Por que JWTs e PKCE usam um alfabeto Base64 diferente, os dois caracteres que mudam e o que acontece com o preenchimento. |
| Chaves Duplicadas em JSON: Legais, Perigosas e Dignas de Detecção | Codificação e dados | A sintaxe JSON permite que a mesma chave apareça mais de uma vez em um objeto, mas a especificação não diz o que isso significa. Parsers diferentes resolvem isso de formas diferentes, o que torna chaves duplicadas uma fonte silenciosa de bugs e até de problemas de segurança. |
| Codificação de URL e Hosts Internacionalizados | Codificação e dadosWeb e HTTP | URLs são restritas a um pequeno conjunto de caracteres ASCII, então todo o resto é codificado. A codificação percent cuida de caminhos e queries; o punycode cuida de nomes de host não-ASCII. Como ambos funcionam, e por que hosts internacionalizados são uma preocupação de phishing. |
| JSON e YAML na Prática: APIs, Declarações e Orquestração | Codificação e dados | A divisão não é aleatória: APIs e declarações máquina-a-máquina tendem a ser JSON, enquanto arquivos de orquestração e pipeline escritos por humanos tendem a ser YAML. Entender por que cada domínio escolheu o que escolheu explica quando converter entre eles é útil. |
| O Problema do Ano 2038 | Codificação e dados | Um inteiro de 32 bits com sinal só consegue contar segundos até 2147483647, que cai em 2038-01-19T03:14:07Z. Um segundo depois ele transborda e dá a volta para um número negativo, jogando os sistemas afetados de volta a 1901. É o sucessor mais silencioso do Y2K, e a correção é um inteiro mais largo. |
| Âncoras, aliases e merge keys em YAML | Codificação e dados | O YAML pode definir um valor uma vez e reutilizá-lo com uma âncora e um alias, e mesclar um mapping em outro com uma merge key. Nada disso existe em JSON, então a conversão expande e duplica tudo. Este artigo cobre a sintaxe, o que acontece na conversão, e a armadilha de negação de serviço que eles habilitam. |
| Escapes de string e Unicode em JSON | Codificação e dados | Dentro de uma string JSON, alguns caracteres precisam ser escritos como escapes, e qualquer caractere pode ser escrito como \uXXXX. As regras são poucas mas estritas, e a que pega as pessoas é como caracteres além do plano básico, como emoji, precisam de um par substituto (surrogate pair). |
| ISO 8601, RFC 3339 e a Data HTTP | Codificação e dados | Depois que um timestamp Unix é convertido de volta em uma data humana, ele é escrito em um de poucos formatos de texto padrão. O ISO 8601 é o padrão amplo, o RFC 3339 é seu perfil estrito para a internet, e a data HTTP é a exceção. Saber a diferença evita muita dor de cabeça com parsing. |
| Onde o Base64 aparece: data URIs, MIME, PEM e Basic auth | Codificação e dados | Os lugares reais em que binário é embrulhado em texto, o custo de tamanho de fazer isso e por que Base64 em um cabeçalho de autenticação não é criptografia. |
| Base32, explicado | Codificação e dadosIdentidade e tokens | Por que o Base32 troca tamanho por um alfabeto sem ambiguidades e insensível a maiúsculas, como funciona seu agrupamento de 5 bits, e onde ele aparece (segredos TOTP, endereços onion, DNS). |
| Block scalars e strings multilinha em YAML | Codificação e dados | O YAML tem duas formas de escrever uma string multilinha, e elas tratam quebras de linha de modo diferente: o estilo literal as mantém, o estilo folded as transforma em espaços. Indicadores de chomping então decidem o que acontece com a quebra de linha final. Errar isso é por que um script ou certificado embutido sai sutilmente corrompido. |
| Por Que o Tempo Unix Ignora os Segundos Bissextos | Codificação e dados | O UTC ocasionalmente insere um segundo bissexto para se manter alinhado com a rotação da Terra, mas o tempo Unix finge que todo dia tem exatamente 86.400 segundos. Essa simplificação deliberada significa que um timestamp Unix não é uma contagem verdadeira de segundos decorridos desde a época — e é a escolha certa para o tempo civil. |
| Vírgulas finais, comentários e a família JSON5 | Codificação e dados | O JSON estrito não tem comentários nem vírgulas finais, o que surpreende quem usa um editor que aceita ambos. A razão é que o JSON é um formato mínimo de interchange, e as variantes tolerantes (JSONC, JSON5) são coisas separadas. Saber qual é qual evita arquivos de config que quebram em outra ferramenta. |
| Codificação hexadecimal (Base16), explicada | Codificação e dados | Como o hexadecimal representa cada byte com dois caracteres, por que é a forma padrão de imprimir bytes brutos, e como ele se compara ao Base64 e ao Base32. |
| Formatação, minificação e JSON canônico | Codificação e dados | O espaço em branco não muda o que o JSON significa, então JSON identado e minificado são o mesmo dado. Mas quando o JSON é assinado ou hasheado, os bytes exatos importam, e é aí que entra o JSON canônico: uma forma determinística de serializar o mesmo dado exatamente na mesma string toda vez. |
| URLs relativas e como elas resolvem | Codificação e dadosWeb e HTTP | Uma URL relativa deixa de fora o esquema e o host e é completada contra uma URL base. As regras de como um navegador preenche o resto, e como ./ e ../ e uma barra inicial mudam o resultado, explicam muitos links quebrados e algumas surpresas de segurança. |
| Codificação por porcentagem (codificação de URL), explicada | Codificação e dados | Por que as URLs escapam certos caracteres como %XX, quais caracteres é seguro deixar como estão, e em que a codificação por porcentagem difere do Base64. |
| URLs enganosas: lendo além dos truques | Codificação e dadosWeb e HTTP | URLs são uma ferramenta favorita para phishing porque o destino real é fácil de disfarçar. O truque do userinfo, os parâmetros de redirecionamento e os caracteres parecidos, todos fazem um link hostil parecer amigável. Este artigo mostra os disfarces comuns e o único hábito confiável para encontrar o host real. |
| Base16, Base32, Base64 e codificação por porcentagem comparadas | Codificação e dados | Um olhar lado a lado para as quatro codificações de texto: seus alfabetos, sobrecarga de tamanho, legibilidade, e quando recorrer a cada uma. |
| Como funciona o diff de texto | Codificação e dadosTexto e utilitários | Um diff encontra o menor conjunto de inserções e remoções que transforma um texto em outro. Por baixo está a maior subsequência comum: as linhas que as duas versões compartilham, na mesma ordem, formam a espinha dorsal inalterada, e todo o resto é uma adição ou uma remoção. |
| Como ler um diff | Codificação e dadosTexto e utilitários | Como ler um diff linha a linha: linhas inalteradas, adicionadas e removidas, os marcadores de mais e menos, os números de linha dos dois lados, o destaque palavra a palavra e o que ignorar espaços e ignorar maiúsculas realmente mudam. Mais o que um diff não consegue dizer. |
| Diffs em nível de palavra e de caractere | Codificação e dadosTexto e utilitários | Um diff de linha marca a linha inteira como alterada mesmo quando um único caractere mudou. Diffs em nível de palavra e de caractere destacam exatamente a parte da linha que mudou, o que é muito mais fácil de ler para prosa, linhas longas e edições pequenas. Este artigo cobre a diferença e quando cada lente é a certa. |
| Diffs de três vias e conflitos de merge | Codificação e dadosTexto e utilitários | Um diff normal compara duas versões e não consegue dizer qual delas mudou. Um diff de três vias adiciona um ancestral comum, que é o que torna o merge automático possível e o que produz os marcadores de conflito <<<<<<< ======= >>>>>>>. Este artigo explica o terceiro insumo e como ler e resolver um conflito. |
| Edições mínimas: por que um diff pode parecer errado | Codificação e dadosTexto e utilitários | Um diff mostra o menor conjunto de inserções e remoções que transforma um texto no outro. Como o menor conjunto não é único e o algoritmo precisa escolher, um diff pode alinhar linhas de formas contraintuitivas, culpando o bloco errado ou dividindo uma seção movida. Saber disso torna diffs estranhos legíveis. |
| Lendo a estrutura do XML | Codificação e dadosSegurança e WAF | XML é uma árvore de elementos construída a partir de um punhado de partes: uma declaração opcional, elementos com atributos, texto e algumas construções especiais. Uma vez que você consegue nomear cada parte e ver como elas se aninham, ler um documento desconhecido de cima a baixo vira rotina em vez de um jogo de adivinhação. |
| Namespaces XML explicados | Codificação e dadosSegurança e WAF | Quando dois vocabulários XML usam o mesmo nome de elemento para coisas diferentes, namespaces os mantêm separados vinculando um prefixo a uma URI única. O prefixo é apenas um atalho local; a URI é a identidade real. Entender essa divisão resolve a maior parte da confusão com namespaces. |
| XML bem formado vs válido | Codificação e dadosSegurança e WAF | Boa formação é a linha de base do XML: uma raiz, tags aninhadas e correspondidas corretamente, atributos entre aspas e especiais escapados. Validade é uma afirmação mais forte e separada de que um documento também segue um schema. Um parser rejeita XML mal formado de imediato, que é por que estas regras vêm primeiro. |
| CDATA, comentários e instruções de processamento | Codificação e dadosSegurança e WAF | Nem tudo em XML é um elemento. Seções CDATA guardam texto cru que de outra forma precisaria de escape, comentários anotam sem afetar o conteúdo, e instruções de processamento carregam direções para uma aplicação. Reconhecer estas três impede que pareçam ruído misterioso. |
Hashing e cripto (15)
Hash, criptografia e codificação: três coisas diferentes
Três operações constantemente confundidas, separadas de forma limpa por duas perguntas: é reversível e precisa de uma chave?
Hashing e criptoCodificação e dadosLerHash criptográfico: SHA-256 e a família SHA-2
O que uma função de hash garante, as propriedades que a tornam criptográfica e por que um resumo não é criptografia.
Hashing e criptoLerEscolhendo um hash: MD5, SHA-1, SHA-2, SHA-3 e BLAKE
Quais funções de hash ainda são seguras, quais estão quebradas, quais são seus tamanhos de saída e como escolher a certa.
Hashing e criptoLerColisões, resistência à pré-imagem e o limite do aniversário
As três propriedades de segurança que um hash criptográfico deve ter, por que colisões importam e a matemática do aniversário que define a força real.
Hashing e criptoLerArmazenando senhas: bcrypt, scrypt e Argon2
Por que um hash rápido como o SHA-256 é a ferramenta errada para senhas, e o que o sal e os fatores de trabalho de fato fazem.
Hashing e criptoLerHMAC: hash com chave para autenticação de mensagens
Por que um hash simples prova integridade mas não autenticidade, como uma chave secreta resolve isso e por que a estrutura do HMAC importa.
Hashing e criptoIdentidade e tokensLerPor que HMAC, e não hash(chave + mensagem)
O ataque de extensão de comprimento que quebra o hashing com chave ingênuo, e a construção aninhada que o HMAC usa para derrotá-lo.
Hashing e criptoLerAutenticando requisições de API com HMAC
Como um segredo compartilhado e um hash permitem que um servidor confie em uma requisição que não viu ser feita, e como a proteção contra repetição se encaixa.
Hashing e criptoLerVerificando um HMAC com segurança: tempo constante e repetição
Por que comparar assinaturas com == vaza um canal lateral de tempo, e por que uma assinatura válida sozinha não impede uma requisição repetida.
Hashing e criptoLerPor Que Hashes Criptográficos São de Mão Única
Um hash criptográfico mapeia qualquer entrada para um resumo de tamanho fixo e é projetado para que recuperar a entrada a partir do resumo seja inviável. Essa propriedade, resistência à pré-imagem, é o motivo pelo qual você não pode descriptografar um hash. Só há duas formas de revertê-lo: consultar uma tabela ou tentar e verificar — ambas são busca, não inversão.
Hashing e criptoLerForça Bruta vs Tabelas de Consulta: Duas Formas de Reverter um Hash
Como um hash não pode ser invertido, revertê-lo significa buscar, e há duas famílias. Pré-computar uma tabela gigante de pares entrada-para-hash e consultar o resumo (o que o CrackStation faz), ou gerar candidatos em tempo real e aplicar hash em cada um até um coincidir (força bruta). Elas trocam armazenamento por processamento em direções opostas.
Hashing e criptoLerPor Que o Salt Derrota Tabelas Pré-computadas
Um salt é um valor aleatório único armazenado com cada hash de senha e misturado antes de aplicar o hash. Ele faz senhas idênticas gerarem hashes diferentes, o que destrói a economia das tabelas pré-computadas: um atacante precisaria de uma tabela separada para cada salt. O salt é a defesa específica que neutraliza serviços de consulta e tabelas rainbow.
Hashing e criptoLerKDFs Lentas: bcrypt, scrypt e Argon2
O salt derrota a pré-computação, mas não um ataque direcionado de tentar e verificar; um hash rápido ainda permite bilhões de candidatos por segundo. Funções de derivação de chave lentas resolvem isso tornando cada tentativa deliberadamente cara e ajustável, cortando a taxa do atacante em muitas ordens de grandeza. É com elas que você deve armazenar senhas.
Hashing e criptoLerEspaço de Chaves, Entropia e Tempo de Quebra
Se a força bruta pode reverter um hash se resume ao tamanho do espaço de chaves versus a taxa de hash do atacante. O espaço de chaves cresce exponencialmente com comprimento e alfabeto, então alguns caracteres a mais levam um segredo de quebrado em segundos a inviável por milênios. É a aritmética por trás de por que comprimento e aleatoriedade importam mais.
Hashing e criptoLerEscolhendo um Hash de Senha
Armazenar senhas com segurança é um problema resolvido: use um hash de senha dedicado, com sal e lento, não um resumo cru. Este é um guia curto de decisão, do algoritmo a escolher aos parâmetros a definir e aos erros a evitar, alinhado às diretrizes da OWASP e do NIST.
Hashing e criptoLer
| Artigo | Tema | Resumo |
|---|---|---|
| Hash, criptografia e codificação: três coisas diferentes | Hashing e criptoCodificação e dados | Três operações constantemente confundidas, separadas de forma limpa por duas perguntas: é reversível e precisa de uma chave? |
| Hash criptográfico: SHA-256 e a família SHA-2 | Hashing e cripto | O que uma função de hash garante, as propriedades que a tornam criptográfica e por que um resumo não é criptografia. |
| Escolhendo um hash: MD5, SHA-1, SHA-2, SHA-3 e BLAKE | Hashing e cripto | Quais funções de hash ainda são seguras, quais estão quebradas, quais são seus tamanhos de saída e como escolher a certa. |
| Colisões, resistência à pré-imagem e o limite do aniversário | Hashing e cripto | As três propriedades de segurança que um hash criptográfico deve ter, por que colisões importam e a matemática do aniversário que define a força real. |
| Armazenando senhas: bcrypt, scrypt e Argon2 | Hashing e cripto | Por que um hash rápido como o SHA-256 é a ferramenta errada para senhas, e o que o sal e os fatores de trabalho de fato fazem. |
| HMAC: hash com chave para autenticação de mensagens | Hashing e criptoIdentidade e tokens | Por que um hash simples prova integridade mas não autenticidade, como uma chave secreta resolve isso e por que a estrutura do HMAC importa. |
| Por que HMAC, e não hash(chave + mensagem) | Hashing e cripto | O ataque de extensão de comprimento que quebra o hashing com chave ingênuo, e a construção aninhada que o HMAC usa para derrotá-lo. |
| Autenticando requisições de API com HMAC | Hashing e cripto | Como um segredo compartilhado e um hash permitem que um servidor confie em uma requisição que não viu ser feita, e como a proteção contra repetição se encaixa. |
| Verificando um HMAC com segurança: tempo constante e repetição | Hashing e cripto | Por que comparar assinaturas com == vaza um canal lateral de tempo, e por que uma assinatura válida sozinha não impede uma requisição repetida. |
| Por Que Hashes Criptográficos São de Mão Única | Hashing e cripto | Um hash criptográfico mapeia qualquer entrada para um resumo de tamanho fixo e é projetado para que recuperar a entrada a partir do resumo seja inviável. Essa propriedade, resistência à pré-imagem, é o motivo pelo qual você não pode descriptografar um hash. Só há duas formas de revertê-lo: consultar uma tabela ou tentar e verificar — ambas são busca, não inversão. |
| Força Bruta vs Tabelas de Consulta: Duas Formas de Reverter um Hash | Hashing e cripto | Como um hash não pode ser invertido, revertê-lo significa buscar, e há duas famílias. Pré-computar uma tabela gigante de pares entrada-para-hash e consultar o resumo (o que o CrackStation faz), ou gerar candidatos em tempo real e aplicar hash em cada um até um coincidir (força bruta). Elas trocam armazenamento por processamento em direções opostas. |
| Por Que o Salt Derrota Tabelas Pré-computadas | Hashing e cripto | Um salt é um valor aleatório único armazenado com cada hash de senha e misturado antes de aplicar o hash. Ele faz senhas idênticas gerarem hashes diferentes, o que destrói a economia das tabelas pré-computadas: um atacante precisaria de uma tabela separada para cada salt. O salt é a defesa específica que neutraliza serviços de consulta e tabelas rainbow. |
| KDFs Lentas: bcrypt, scrypt e Argon2 | Hashing e cripto | O salt derrota a pré-computação, mas não um ataque direcionado de tentar e verificar; um hash rápido ainda permite bilhões de candidatos por segundo. Funções de derivação de chave lentas resolvem isso tornando cada tentativa deliberadamente cara e ajustável, cortando a taxa do atacante em muitas ordens de grandeza. É com elas que você deve armazenar senhas. |
| Espaço de Chaves, Entropia e Tempo de Quebra | Hashing e cripto | Se a força bruta pode reverter um hash se resume ao tamanho do espaço de chaves versus a taxa de hash do atacante. O espaço de chaves cresce exponencialmente com comprimento e alfabeto, então alguns caracteres a mais levam um segredo de quebrado em segundos a inviável por milênios. É a aritmética por trás de por que comprimento e aleatoriedade importam mais. |
| Escolhendo um Hash de Senha | Hashing e cripto | Armazenar senhas com segurança é um problema resolvido: use um hash de senha dedicado, com sal e lento, não um resumo cru. Este é um guia curto de decisão, do algoritmo a escolher aos parâmetros a definir e aos erros a evitar, alinhado às diretrizes da OWASP e do NIST. |
Identidade e tokens (21)
Anatomia de um JSON Web Token
Os três segmentos de um JWT, como a assinatura o torna confiável e por que decodificar um token não é o mesmo que verificá-lo.
Identidade e tokensLerJWKS e Rotação de Chaves: Como os Provedores Publicam suas Chaves
Um JWKS é a lista pública de chaves de assinatura que um provedor de identidade publica para que qualquer um possa verificar seus tokens. Entender o array keys, o kid que nomeia cada chave e por que um provedor mantém mais de uma chave ao mesmo tempo é a base da verificação de tokens.
Identidade e tokensLerOpenID Connect: Uma Camada de Identidade sobre o OAuth 2.0
O que o OpenID Connect adiciona ao OAuth 2.0, o ID token no centro de tudo, os papéis de relying party e provedor, como o fluxo de código de autorização entrega um ID token, e por que um ID token é apenas um JWT que você pode decodificar e ler.
Identidade e tokensLerAlgoritmos de assinatura de JWT: HMAC, RSA e ECDSA
Por que o cabeçalho alg de um JWT importa, a diferença entre assinatura simétrica e assimétrica, e como escolher.
Identidade e tokensLerAs Claims do ID Token, e o Que uma Relying Party Verifica
As claims dentro de um ID token OIDC: as obrigatórias iss, sub, aud, exp e iat; o nonce que impede repetição; azp quando há múltiplas audiências; acr e amr para a força da autenticação; auth_time; e as claims de vínculo at_hash e c_hash, com a validação que uma relying party realiza em cada uma.
Identidade e tokensLerTipos de Chave JWK: RSA, EC, OKP e oct
Toda JSON Web Key declara um kty, e esse único campo decide quais parâmetros a chave carrega. Quatro tipos cobrem quase tudo o que você encontrará: RSA, curva elíptica, as curvas de Edwards e Montgomery, e a sequência de octetos simétrica. A divisão crucial em todos eles é público versus privado.
Identidade e tokensLerArmadilhas de segurança em JWT: alg:none, confusão de chave e verificações ausentes
O punhado de erros que transforma um verificador de JWT em uma máquina de falsificação, e a validação que um verificador correto deve fazer.
Identidade e tokensLerOIDC vs OAuth 2.0: Autenticação vs Autorização
Por que o OAuth 2.0 é sobre autorização e o OpenID Connect é sobre autenticação, a diferença entre um access token e um ID token, por que usar OAuth puro como mecanismo de login é um antipadrão conhecido, e como saber qual token é qual.
Identidade e tokensLerVerificando um JWT com um JWKS: do kid à Assinatura
Verificar um token assinado é uma sequência curta e rigorosa: ler o cabeçalho, encontrar a chave cujo kid corresponde no JWKS do provedor, confirmar o algoritmo e checar a assinatura. Cada passo tem uma armadilha clássica, e pular o rigor é como acontecem os bypasses de verificação.
Identidade e tokensLerOIDC Discovery: O Documento openid-configuration
Como o documento .well-known/openid-configuration permite a uma relying party descobrir automaticamente os endpoints e capacidades de um provedor, o que significam os campos issuer, jwks_uri e de algoritmo de assinatura, por que anunciar o algoritmo none é perigoso, e por que o suporte a PKCE S256 importa.
Identidade e tokensLerParâmetros e thumbprints de JWK
Uma JWK é um objeto JSON que descreve uma chave, e seus parâmetros dizem para que a chave serve e como identificá-la. Além do material da chave, kid a nomeia e um thumbprint (RFC 7638) dá a ela um identificador estável e computado. Este artigo cobre os parâmetros comuns e como um thumbprint é derivado e usado.
Identidade e tokensLerTokens de acesso, tokens de atualização e tokens de ID
Três tokens do OAuth e do OpenID Connect que vivem sendo confundidos, para que cada um de fato serve, e por que enviar o errado ao lugar errado é um bug de verdade.
Identidade e tokensLerAtaques de confusão de algoritmo em JWT
Duas falhas clássicas de verificação de JWT vêm de confiar no algoritmo declarado pelo próprio token: aceitar alg none, e ser enganado a verificar um token RS256 como HS256 usando a chave pública como segredo. Ambas são derrotadas fixando o algoritmo esperado no servidor em vez de lê-lo do token.
Identidade e tokensLerClientes públicos vs confidenciais, e onde o PKCE se encaixa
Se um cliente OAuth consegue guardar um segredo decide todo o seu modelo de segurança. Por que SPAs e apps móveis são clientes públicos, e por que o PKCE agora é recomendado para todos eles.
Identidade e tokensLerO fluxo authorization code do OIDC
O fluxo authorization code é a forma recomendada de um app obter um ID token: o usuário é redirecionado ao provedor de identidade para logar, o app recebe um código de curta duração, e o troca em um token endpoint de back-channel pelos tokens. Manter o token fora do navegador é o objetivo inteiro.
Identidade e tokensLerO fluxo de código de autorização do OAuth 2.0
Os quatro papéis, a dança de redirecionar e trocar, e por que o código é trocado por um token no canal de fundo.
Identidade e tokensLerPKCE: protegendo o fluxo de código de autorização do OAuth
O ataque de interceptação que o PKCE derrota, como o verificador e o desafio se encaixam, e por que o S256 é obrigatório.
Identidade e tokensLerOpenID Connect: identidade sobre o OAuth 2.0
Como o OIDC adiciona autenticação à autorização do OAuth, o que é o token de ID e por que o fluxo de código com PKCE é o caminho recomendado.
Identidade e tokensLerComo funcionam as senhas de uso único TOTP e HOTP
Ambas transformam um segredo compartilhado em um código curto que prova posse sem transmitir o segredo. O HOTP conta eventos; o TOTP conta tempo. O motor por baixo é o mesmo HMAC mais uma etapa de truncamento.
Identidade e tokensLerValidando senhas de uso único: desvio, janelas e repetição
Gerar um código é a metade fácil. Aceitar um exige tolerar o desvio de relógio, limitar a janela, rejeitar a reutilização e conter as tentativas, cada um um compromisso entre usabilidade e segurança.
Identidade e tokensLerProvisionando autenticadores: URIs otpauth e QR codes
Antes de um app autenticador poder gerar códigos, ele precisa do segredo compartilhado e dos parâmetros que o acompanham. Isso é carregado em uma URI otpauth, normalmente mostrada como um QR code para escanear. Conhecer os campos da URI explica o que o QR code de fato contém e por que o segredo está em base32.
Identidade e tokensLer
| Artigo | Tema | Resumo |
|---|---|---|
| Anatomia de um JSON Web Token | Identidade e tokens | Os três segmentos de um JWT, como a assinatura o torna confiável e por que decodificar um token não é o mesmo que verificá-lo. |
| JWKS e Rotação de Chaves: Como os Provedores Publicam suas Chaves | Identidade e tokens | Um JWKS é a lista pública de chaves de assinatura que um provedor de identidade publica para que qualquer um possa verificar seus tokens. Entender o array keys, o kid que nomeia cada chave e por que um provedor mantém mais de uma chave ao mesmo tempo é a base da verificação de tokens. |
| OpenID Connect: Uma Camada de Identidade sobre o OAuth 2.0 | Identidade e tokens | O que o OpenID Connect adiciona ao OAuth 2.0, o ID token no centro de tudo, os papéis de relying party e provedor, como o fluxo de código de autorização entrega um ID token, e por que um ID token é apenas um JWT que você pode decodificar e ler. |
| Algoritmos de assinatura de JWT: HMAC, RSA e ECDSA | Identidade e tokens | Por que o cabeçalho alg de um JWT importa, a diferença entre assinatura simétrica e assimétrica, e como escolher. |
| As Claims do ID Token, e o Que uma Relying Party Verifica | Identidade e tokens | As claims dentro de um ID token OIDC: as obrigatórias iss, sub, aud, exp e iat; o nonce que impede repetição; azp quando há múltiplas audiências; acr e amr para a força da autenticação; auth_time; e as claims de vínculo at_hash e c_hash, com a validação que uma relying party realiza em cada uma. |
| Tipos de Chave JWK: RSA, EC, OKP e oct | Identidade e tokens | Toda JSON Web Key declara um kty, e esse único campo decide quais parâmetros a chave carrega. Quatro tipos cobrem quase tudo o que você encontrará: RSA, curva elíptica, as curvas de Edwards e Montgomery, e a sequência de octetos simétrica. A divisão crucial em todos eles é público versus privado. |
| Armadilhas de segurança em JWT: alg:none, confusão de chave e verificações ausentes | Identidade e tokens | O punhado de erros que transforma um verificador de JWT em uma máquina de falsificação, e a validação que um verificador correto deve fazer. |
| OIDC vs OAuth 2.0: Autenticação vs Autorização | Identidade e tokens | Por que o OAuth 2.0 é sobre autorização e o OpenID Connect é sobre autenticação, a diferença entre um access token e um ID token, por que usar OAuth puro como mecanismo de login é um antipadrão conhecido, e como saber qual token é qual. |
| Verificando um JWT com um JWKS: do kid à Assinatura | Identidade e tokens | Verificar um token assinado é uma sequência curta e rigorosa: ler o cabeçalho, encontrar a chave cujo kid corresponde no JWKS do provedor, confirmar o algoritmo e checar a assinatura. Cada passo tem uma armadilha clássica, e pular o rigor é como acontecem os bypasses de verificação. |
| OIDC Discovery: O Documento openid-configuration | Identidade e tokens | Como o documento .well-known/openid-configuration permite a uma relying party descobrir automaticamente os endpoints e capacidades de um provedor, o que significam os campos issuer, jwks_uri e de algoritmo de assinatura, por que anunciar o algoritmo none é perigoso, e por que o suporte a PKCE S256 importa. |
| Parâmetros e thumbprints de JWK | Identidade e tokens | Uma JWK é um objeto JSON que descreve uma chave, e seus parâmetros dizem para que a chave serve e como identificá-la. Além do material da chave, kid a nomeia e um thumbprint (RFC 7638) dá a ela um identificador estável e computado. Este artigo cobre os parâmetros comuns e como um thumbprint é derivado e usado. |
| Tokens de acesso, tokens de atualização e tokens de ID | Identidade e tokens | Três tokens do OAuth e do OpenID Connect que vivem sendo confundidos, para que cada um de fato serve, e por que enviar o errado ao lugar errado é um bug de verdade. |
| Ataques de confusão de algoritmo em JWT | Identidade e tokens | Duas falhas clássicas de verificação de JWT vêm de confiar no algoritmo declarado pelo próprio token: aceitar alg none, e ser enganado a verificar um token RS256 como HS256 usando a chave pública como segredo. Ambas são derrotadas fixando o algoritmo esperado no servidor em vez de lê-lo do token. |
| Clientes públicos vs confidenciais, e onde o PKCE se encaixa | Identidade e tokens | Se um cliente OAuth consegue guardar um segredo decide todo o seu modelo de segurança. Por que SPAs e apps móveis são clientes públicos, e por que o PKCE agora é recomendado para todos eles. |
| O fluxo authorization code do OIDC | Identidade e tokens | O fluxo authorization code é a forma recomendada de um app obter um ID token: o usuário é redirecionado ao provedor de identidade para logar, o app recebe um código de curta duração, e o troca em um token endpoint de back-channel pelos tokens. Manter o token fora do navegador é o objetivo inteiro. |
| O fluxo de código de autorização do OAuth 2.0 | Identidade e tokens | Os quatro papéis, a dança de redirecionar e trocar, e por que o código é trocado por um token no canal de fundo. |
| PKCE: protegendo o fluxo de código de autorização do OAuth | Identidade e tokens | O ataque de interceptação que o PKCE derrota, como o verificador e o desafio se encaixam, e por que o S256 é obrigatório. |
| OpenID Connect: identidade sobre o OAuth 2.0 | Identidade e tokens | Como o OIDC adiciona autenticação à autorização do OAuth, o que é o token de ID e por que o fluxo de código com PKCE é o caminho recomendado. |
| Como funcionam as senhas de uso único TOTP e HOTP | Identidade e tokens | Ambas transformam um segredo compartilhado em um código curto que prova posse sem transmitir o segredo. O HOTP conta eventos; o TOTP conta tempo. O motor por baixo é o mesmo HMAC mais uma etapa de truncamento. |
| Validando senhas de uso único: desvio, janelas e repetição | Identidade e tokens | Gerar um código é a metade fácil. Aceitar um exige tolerar o desvio de relógio, limitar a janela, rejeitar a reutilização e conter as tentativas, cada um um compromisso entre usabilidade e segurança. |
| Provisionando autenticadores: URIs otpauth e QR codes | Identidade e tokens | Antes de um app autenticador poder gerar códigos, ele precisa do segredo compartilhado e dos parâmetros que o acompanham. Isso é carregado em uma URI otpauth, normalmente mostrada como um QR code para escanear. Conhecer os campos da URI explica o que o QR code de fato contém e por que o segredo está em base32. |
Identificadores (5)
UUIDs: v4 aleatório e v7 ordenado por tempo
Como um identificador de 128 bits permanece único sem uma autoridade central, e por que o v7 está se tornando o padrão para chaves de banco de dados.
IdentificadoresLerVersões de UUID explicadas: v1 até v8
Toda a família UUID em um só lugar, da v1 com tempo-e-MAC à v4 aleatória e à v7 com ordenação temporal, além das versões baseadas em nome e como se leem os bits de versão e variante.
IdentificadoresLerUUIDs vão colidir? Probabilidade e o limite do aniversário
Quantos bits aleatórios um UUID realmente tem, a matemática do aniversário para uma colisão e quando você quer UUIDs determinísticos.
IdentificadoresLerUUIDs como chaves de banco de dados: v4, v7 e localidade de índice
O verdadeiro compromisso entre UUIDs e inteiros autoincrementais, e por que chaves v4 aleatórias prejudicam silenciosamente o desempenho do banco.
IdentificadoresLerULID, KSUID, Snowflake e outros IDs ordenáveis
As alternativas populares aos UUIDs para identificadores ordenados no tempo, como cada um é construído e por que o UUIDv7 agora cobre a maior parte daquilo para que foram inventados.
IdentificadoresLer
| Artigo | Tema | Resumo |
|---|---|---|
| UUIDs: v4 aleatório e v7 ordenado por tempo | Identificadores | Como um identificador de 128 bits permanece único sem uma autoridade central, e por que o v7 está se tornando o padrão para chaves de banco de dados. |
| Versões de UUID explicadas: v1 até v8 | Identificadores | Toda a família UUID em um só lugar, da v1 com tempo-e-MAC à v4 aleatória e à v7 com ordenação temporal, além das versões baseadas em nome e como se leem os bits de versão e variante. |
| UUIDs vão colidir? Probabilidade e o limite do aniversário | Identificadores | Quantos bits aleatórios um UUID realmente tem, a matemática do aniversário para uma colisão e quando você quer UUIDs determinísticos. |
| UUIDs como chaves de banco de dados: v4, v7 e localidade de índice | Identificadores | O verdadeiro compromisso entre UUIDs e inteiros autoincrementais, e por que chaves v4 aleatórias prejudicam silenciosamente o desempenho do banco. |
| ULID, KSUID, Snowflake e outros IDs ordenáveis | Identificadores | As alternativas populares aos UUIDs para identificadores ordenados no tempo, como cada um é construído e por que o UUIDv7 agora cobre a maior parte daquilo para que foram inventados. |
Redes (44)
Como funcionam os endereços IPv4
Os 32 bits por trás de todo endereço em quad pontilhado, e o que faixas privadas, de loopback e especiais significam.
RedesLerO PRI do Syslog: Um Número, Dois Significados
Toda mensagem de syslog começa com um PRI, um número entre colchetes angulares que empacota uma facility e uma severity em um único valor. A fórmula é pequena e a aritmética é fácil depois que você a vê: PRI é igual a facility vezes oito mais severity.
RedesLerFacilities e Severities do Syslog, Explicadas
O syslog define 24 facilities e 8 severities. As severities são uma escala limpa de urgência, de emergency até debug; as facilities são uma mistura de categorias genuinamente úteis e resquícios históricos do Unix, mais oito slots locais nos quais os dispositivos de rede se apoiam bastante.
RedesLerFundamentos de sub-redes
Como dividir uma rede em sub-redes menores, e por que tomar emprestado bits de host é todo o truque.
RedesLerNotação CIDR explicada
O que a barra em 192.168.1.0/24 de fato significa, e como um comprimento de prefixo define um bloco de endereços IP.
RedesLerSyslog em Dispositivos de Rede: Qual Facility Faz o Quê
Firewalls, balanceadores de carga e switches quase sempre registram nas facilities locais, mas cada fabricante escolhe um padrão diferente. Saber que o FortiGate usa local7 por padrão, o Cisco ASA usa local4 e o F5 BIG-IP usa local0 transforma uma parede de números de PRI em um mapa de qual caixa disse o quê.
RedesLerFormatos de mensagem syslog: RFC 3164 vs RFC 5424
O PRI é o mesmo em todo lugar, mas o que vem depois não é. O syslog BSD legado (RFC 3164) tem um formato solto e sem ano, enquanto o formato moderno (RFC 5424) é preciso e estruturado. Saber qual você está vendo explica timestamps ausentes, campos ambíguos e por que parsers discordam.
RedesLerVLSM: dividindo um bloco em sub-redes desiguais
Como recortar um bloco de endereços em sub-redes de tamanhos diferentes sem desperdiçar espaço, e a regra do maior primeiro que mantém tudo organizado.
RedesLerComo o syslog viaja: UDP, TCP e TLS
O syslog pode trafegar sobre UDP puro, sobre TCP, ou sobre TLS, e a escolha decide se as mensagens podem ser silenciosamente perdidas, reordenadas ou lidas em trânsito. Este artigo cobre os três transportes, as portas envolvidas, e por que qualquer coisa da qual você depende para auditoria não deveria ser enviada sobre UDP.
RedesLerUma atribuição VLSM, resolvida do início ao fim
Uma atribuição completa de sub-redes de comprimento variável para uma rede realista: dimensionar cada segmento, ordenar do maior para o menor, atribuir os endereços reais e contabilizar o espaço que sobra.
RedesLerA Primeira Hora: Isolamento de Falhas Orientado por Hipóteses
A diferença entre um incidente de duas horas e um de dois dias costuma ser decidida na primeira hora, e raramente é decidida por ferramentas. É decidida por método: alinhar o início com a mudança, isolar por escopo, ler assinaturas de camada e tratar toda explicação como uma hipótese que a evidência precisa sustentar ou enfraquecer antes que alguém aja sobre ela.
RedesOperações e fieldcraftLerSupernetting e agregação de rotas
Como prefixos contíguos se combinam em um mais curto, a regra de alinhamento que decide se dois blocos podem se fundir, e a diferença entre a agregação exata e uma única super-rede que os cubra.
RedesLerSumarização de rotas
Por que uma única rota resumo pode substituir muitas específicas, a atribuição contígua e alinhada da qual ela depende, e o risco de buraco negro ao sumarizar uma faixa que você não possui por completo.
RedesLerSobreposições e lacunas de sub-redes
O que significa dois prefixos se sobreporem ou um conter o outro, por que a correspondência de prefixo mais longo torna algumas sobreposições intencionais, e como encontrar as lacunas não atribuídas de um plano de endereços.
RedesLerEspaço de endereços IPv4 privados e a RFC 1918
As três faixas privadas, por que não são roteáveis na Internet e os outros blocos especiais que a ferramenta CIDR sinaliza.
RedesLerEntendendo o endereçamento IPv6
Como um endereço IPv6 de 128 bits é estruturado e escrito, as regras para comprimi-lo canonicamente, o que os tipos de endereço e escopos significam, e como identificadores de interface e DNS reverso funcionam.
RedesLerComo hosts IPv6 obtêm endereços: SLAAC e DHCPv6
Como um host IPv6 se configura a partir do link-local para cima, o que os anúncios de roteador decidem, e a diferença entre SLAAC, endereços de privacidade, e DHCPv6.
RedesLerSub-redes IPv6 e a fronteira /64
Por que as sub-redes IPv6 são sobre estrutura em vez de escassez, por que uma única sub-rede é quase sempre um /64, e como a delegação de prefixo distribui espaço de endereços.
RedesLerSufixos públicos e o domínio registrado (eTLD+1)
O que são um sufixo público (eTLD) e um domínio registrado (eTLD+1), por que você não pode calculá-los pegando os dois últimos rótulos, como o algoritmo da Public Suffix List os resolve, e onde a fronteira importa: limites de emissão de certificados, cookies e same-site.
RedesCertificados e PKILerDescoberta de Vizinhos: como o IPv6 substitui o ARP
Como o IPv6 encontra vizinhos em um enlace usando ICMPv6 e multicast em vez do ARP por broadcast, as cinco mensagens de Descoberta de Vizinhos, e por que o broadcast se foi.
RedesLerRodando IPv6 e IPv4 juntos: dual-stack e tradução
Como a internet faz a ponte entre duas famílias de endereços incompatíveis: dual-stack, Happy Eyeballs, NAT64, e os endereços com IPv4 embutido que fazem isso funcionar.
RedesLerLendo a saída do dig de cima a baixo
Uma resposta do dig tem uma forma fixa: uma linha de versão, o cabeçalho, a linha de flags, a pseudo-seção OPT, as quatro seções e as estatísticas da consulta. Depois que você conhece cada bloco, consegue ler qualquer resposta num relance e identificar a única linha que explica um problema de resolução.
RedesLerO cabeçalho DNS: opcode, status e flags
Duas linhas carregam todo o estado de uma mensagem DNS: que tipo de consulta é, se ela teve sucesso e sete flags de um único bit (qr, aa, tc, rd, ra, ad, cd) que dizem quem respondeu e como. Lê-las corretamente é a diferença entre um diagnóstico de dois minutos e uma hora de adivinhação.
RedesLerLendo os registros em uma resposta do dig
Todo registro em uma seção do dig são cinco colunas: nome, TTL, classe, tipo e rdata. Este artigo percorre as colunas e depois o rdata dos tipos de registro que você realmente encontra, de A e CNAME a MX, SOA, SRV e CAA, para que uma parede de registros se leia como fatos simples.
RedesLerO EDNS e a pseudo-seção OPT
A pseudo-seção OPT não é um registro e não é algo que você consultou: é metadado do EDNS(0) que o dig mostra perto do topo de uma resposta. Ela carrega o tamanho do payload UDP, a flag DO que solicita DNSSEC e opções como COOKIE, e explica silenciosamente toda uma classe de falhas de resolução.
RedesLerRegistros DNSSEC na saída do dig
Adicione +dnssec e uma resposta do dig ganha uma nova família de registros: RRSIG, DNSKEY, DS e os registros de negação NSEC ou NSEC3. Este artigo explica o que é cada um, como eles se encadeiam da raiz até uma zona, e o que a flag ad realmente certifica.
RedesLerLendo a saída do nslookup
O nslookup imprime um cabeçalho Server / Address para o resolvedor usado, um marcador opcional Non-authoritative answer, e então a resposta em um formato de prosa por tipo. Conhecer essa forma permite ler qualquer resultado rapidamente e ver num relance se ele teve sucesso, de onde veio e o que significa.
RedesLernslookup vs dig: qual usar
O nslookup e o dig ambos consultam DNS, mas o nslookup é mais enxuto e esconde as flags do cabeçalho e os TTLs que o dig mostra por completo. Este artigo mapeia uma saída sobre a outra e dá uma regra simples para saber qual usar.
RedesLerComo o nslookup imprime cada tipo de registro
Em vez das colunas fixas do dig, o nslookup rotula cada registro em prosa: mail exchanger =, canonical name =, nameserver = e um bloco de várias linhas para o SOA. Um guia curto para ler a linha de cada tipo.
RedesLerRespostas autoritativas vs não autoritativas
O marcador Non-authoritative answer no nslookup significa que o resultado veio do cache de um resolvedor, não de um servidor que de fato mantém a zona. Este artigo explica a diferença, por que ela normalmente não é problema, e como obter uma resposta autoritativa quando você precisa.
RedesLerErros do nslookup e o que significam
Quando uma consulta falha, o nslookup imprime uma linha como ** server can't find NAME: CODE. O código é o diagnóstico inteiro. Este artigo cobre NXDOMAIN, SERVFAIL, REFUSED e timeouts, o que cada um diz, e a primeira coisa a verificar para cada.
RedesLerConsultas DNS reversas com o nslookup
O DNS reverso mapeia um endereço IP de volta para um nome por meio de registros PTR que ficam sob in-addr.arpa para IPv4 e ip6.arpa para IPv6. O nslookup faz isso automaticamente quando você lhe passa um endereço. Este artigo cobre como o nome reverso especial é construído, por que os servidores de e-mail se importam, e por que o direto e o reverso podem legitimamente discordar.
RedesLerModo interativo do nslookup
Execute o nslookup sem argumentos e ele entra em um prompt interativo onde você pode trocar de resolvedor, mudar o tipo de registro, ligar a saída de debug e consultar vários nomes em uma única sessão. Este artigo cobre o punhado de comandos que vale a pena conhecer e quando o interativo vence uma consulta única.
RedesLerOpções de consulta e controle de saída do dig
O verdadeiro poder do dig está em suas opções: escolher qual servidor perguntar, o tipo de registro e exatamente quanto da resposta imprimir. Este artigo cobre o punhado que você realmente usará todo dia, de @servidor e -t a +short e a combinação +noall +answer que reduz o dig a apenas os registros.
RedesLerSeguindo a delegação com dig +trace
O dig +trace resolve um nome da forma como a internet de fato faz: começando na raiz, seguindo a delegação para o TLD e então para os próprios servidores autoritativos do domínio, imprimindo cada salto. É a melhor forma de ver onde a resolução quebra e de entender como o DNS é costurado.
RedesLerLendo um comando curl
Um comando curl é um comando de shell: a palavra curl, um conjunto de opções e uma URL. Lê-lo é ver como o shell primeiro divide a linha (aspas, contrabarras, continuações de linha) e depois como o curl lê sinalizadores curtos, longos e agrupados.
RedesWeb e HTTPLerSinalizadores de dados do curl e a armadilha do Content-Type
O curl tem várias formas de anexar um corpo, e elas diferem na codificação e no Content-Type padrão. A grande surpresa é que -d usa codificação de formulário por padrão, não JSON, então um corpo JSON pode ser rotulado errado e recusado.
RedesWeb e HTTPLerTraduzindo curl para fetch()
A API fetch do navegador e o curl descrevem a mesma requisição de formas diferentes. Método, cabeçalhos e corpo se mapeiam de forma limpa, mas algumas diferenças (Content-Type de formulário implícito, cookies e verificação TLS) exigem cuidado.
RedesWeb e HTTPLerCabeçalhos, autenticação e cookies no curl
Cabeçalhos, autenticação e cookies são como uma requisição se identifica e se autoriza. -H adiciona cabeçalhos, -u é HTTP Basic, um token bearer é apenas um cabeçalho, e -b/-c cuidam de cookies. Todos são sensíveis.
RedesWeb e HTTPLerComo o curl infere o método HTTP
O curl nem sempre precisa de -X para escolher um método. Dados no corpo implicam POST, -I implica HEAD, -G força GET, e um -X explícito sempre vence. Conhecer as regras diz num relance o que uma requisição fará.
RedesWeb e HTTPLerSinalizadores do curl que mudam a postura de segurança
Alguns sinalizadores do curl mudam o quão segura é uma requisição: -k desativa a verificação TLS, http envia tudo em texto puro, e credenciais na URL podem vazar. Nenhum torna uma requisição maliciosa, mas cada um vale a leitura antes de executar ou compartilhar um comando.
RedesWeb e HTTPLerO Proxy TCP: O Que um Middlebox de Camada 4 Vê e o Que Não Vê
Um proxy TCP termina a conexão TCP do cliente e abre uma separada para o servidor, unindo dois fluxos independentes na Camada 4. Ele reescreve endereços e portas, pode agrupar e reutilizar conexões, e não vê nada do payload da aplicação acima do cabeçalho de transporte. Este artigo explica full-proxy versus encaminhamento de pacotes, por que o IP de origem desaparece, e como o Proxy Protocol o traz de volta.
RedesWeb e HTTPLerProxies HTTP: Forward vs Reverse, Explícito vs Transparente
Um proxy HTTP parseia requisições na Camada 7, então pode rotear por URL, reescrever cabeçalhos e impor política sobre conteúdo que um proxy TCP não consegue ver. Dois eixos descrevem toda implantação: forward vs reverse (para qual lado ele trabalha) e explícito vs transparente (se o cliente sabe que ele está lá). Este artigo cobre o método CONNECT, o X-Forwarded-For e o Via, e onde cada combinação é usada.
RedesWeb e HTTPLerOs 27 protocolos que o curl fala
O curl é conhecido como ferramenta de HTTP, mas a versão atual fala 27 esquemas de URL: transferência de arquivos por FTP, SFTP e SMB, e-mail por SMTP, POP3 e IMAP, publish-subscribe MQTT, consultas LDAP e relíquias como Gopher, DICT e Telnet. Conhecer o mapa, e saber quais esquemas começam em texto claro, muda a forma de usar a ferramenta.
RedesWeb e HTTPLer
| Artigo | Tema | Resumo |
|---|---|---|
| Como funcionam os endereços IPv4 | Redes | Os 32 bits por trás de todo endereço em quad pontilhado, e o que faixas privadas, de loopback e especiais significam. |
| O PRI do Syslog: Um Número, Dois Significados | Redes | Toda mensagem de syslog começa com um PRI, um número entre colchetes angulares que empacota uma facility e uma severity em um único valor. A fórmula é pequena e a aritmética é fácil depois que você a vê: PRI é igual a facility vezes oito mais severity. |
| Facilities e Severities do Syslog, Explicadas | Redes | O syslog define 24 facilities e 8 severities. As severities são uma escala limpa de urgência, de emergency até debug; as facilities são uma mistura de categorias genuinamente úteis e resquícios históricos do Unix, mais oito slots locais nos quais os dispositivos de rede se apoiam bastante. |
| Fundamentos de sub-redes | Redes | Como dividir uma rede em sub-redes menores, e por que tomar emprestado bits de host é todo o truque. |
| Notação CIDR explicada | Redes | O que a barra em 192.168.1.0/24 de fato significa, e como um comprimento de prefixo define um bloco de endereços IP. |
| Syslog em Dispositivos de Rede: Qual Facility Faz o Quê | Redes | Firewalls, balanceadores de carga e switches quase sempre registram nas facilities locais, mas cada fabricante escolhe um padrão diferente. Saber que o FortiGate usa local7 por padrão, o Cisco ASA usa local4 e o F5 BIG-IP usa local0 transforma uma parede de números de PRI em um mapa de qual caixa disse o quê. |
| Formatos de mensagem syslog: RFC 3164 vs RFC 5424 | Redes | O PRI é o mesmo em todo lugar, mas o que vem depois não é. O syslog BSD legado (RFC 3164) tem um formato solto e sem ano, enquanto o formato moderno (RFC 5424) é preciso e estruturado. Saber qual você está vendo explica timestamps ausentes, campos ambíguos e por que parsers discordam. |
| VLSM: dividindo um bloco em sub-redes desiguais | Redes | Como recortar um bloco de endereços em sub-redes de tamanhos diferentes sem desperdiçar espaço, e a regra do maior primeiro que mantém tudo organizado. |
| Como o syslog viaja: UDP, TCP e TLS | Redes | O syslog pode trafegar sobre UDP puro, sobre TCP, ou sobre TLS, e a escolha decide se as mensagens podem ser silenciosamente perdidas, reordenadas ou lidas em trânsito. Este artigo cobre os três transportes, as portas envolvidas, e por que qualquer coisa da qual você depende para auditoria não deveria ser enviada sobre UDP. |
| Uma atribuição VLSM, resolvida do início ao fim | Redes | Uma atribuição completa de sub-redes de comprimento variável para uma rede realista: dimensionar cada segmento, ordenar do maior para o menor, atribuir os endereços reais e contabilizar o espaço que sobra. |
| A Primeira Hora: Isolamento de Falhas Orientado por Hipóteses | RedesOperações e fieldcraft | A diferença entre um incidente de duas horas e um de dois dias costuma ser decidida na primeira hora, e raramente é decidida por ferramentas. É decidida por método: alinhar o início com a mudança, isolar por escopo, ler assinaturas de camada e tratar toda explicação como uma hipótese que a evidência precisa sustentar ou enfraquecer antes que alguém aja sobre ela. |
| Supernetting e agregação de rotas | Redes | Como prefixos contíguos se combinam em um mais curto, a regra de alinhamento que decide se dois blocos podem se fundir, e a diferença entre a agregação exata e uma única super-rede que os cubra. |
| Sumarização de rotas | Redes | Por que uma única rota resumo pode substituir muitas específicas, a atribuição contígua e alinhada da qual ela depende, e o risco de buraco negro ao sumarizar uma faixa que você não possui por completo. |
| Sobreposições e lacunas de sub-redes | Redes | O que significa dois prefixos se sobreporem ou um conter o outro, por que a correspondência de prefixo mais longo torna algumas sobreposições intencionais, e como encontrar as lacunas não atribuídas de um plano de endereços. |
| Espaço de endereços IPv4 privados e a RFC 1918 | Redes | As três faixas privadas, por que não são roteáveis na Internet e os outros blocos especiais que a ferramenta CIDR sinaliza. |
| Entendendo o endereçamento IPv6 | Redes | Como um endereço IPv6 de 128 bits é estruturado e escrito, as regras para comprimi-lo canonicamente, o que os tipos de endereço e escopos significam, e como identificadores de interface e DNS reverso funcionam. |
| Como hosts IPv6 obtêm endereços: SLAAC e DHCPv6 | Redes | Como um host IPv6 se configura a partir do link-local para cima, o que os anúncios de roteador decidem, e a diferença entre SLAAC, endereços de privacidade, e DHCPv6. |
| Sub-redes IPv6 e a fronteira /64 | Redes | Por que as sub-redes IPv6 são sobre estrutura em vez de escassez, por que uma única sub-rede é quase sempre um /64, e como a delegação de prefixo distribui espaço de endereços. |
| Sufixos públicos e o domínio registrado (eTLD+1) | RedesCertificados e PKI | O que são um sufixo público (eTLD) e um domínio registrado (eTLD+1), por que você não pode calculá-los pegando os dois últimos rótulos, como o algoritmo da Public Suffix List os resolve, e onde a fronteira importa: limites de emissão de certificados, cookies e same-site. |
| Descoberta de Vizinhos: como o IPv6 substitui o ARP | Redes | Como o IPv6 encontra vizinhos em um enlace usando ICMPv6 e multicast em vez do ARP por broadcast, as cinco mensagens de Descoberta de Vizinhos, e por que o broadcast se foi. |
| Rodando IPv6 e IPv4 juntos: dual-stack e tradução | Redes | Como a internet faz a ponte entre duas famílias de endereços incompatíveis: dual-stack, Happy Eyeballs, NAT64, e os endereços com IPv4 embutido que fazem isso funcionar. |
| Lendo a saída do dig de cima a baixo | Redes | Uma resposta do dig tem uma forma fixa: uma linha de versão, o cabeçalho, a linha de flags, a pseudo-seção OPT, as quatro seções e as estatísticas da consulta. Depois que você conhece cada bloco, consegue ler qualquer resposta num relance e identificar a única linha que explica um problema de resolução. |
| O cabeçalho DNS: opcode, status e flags | Redes | Duas linhas carregam todo o estado de uma mensagem DNS: que tipo de consulta é, se ela teve sucesso e sete flags de um único bit (qr, aa, tc, rd, ra, ad, cd) que dizem quem respondeu e como. Lê-las corretamente é a diferença entre um diagnóstico de dois minutos e uma hora de adivinhação. |
| Lendo os registros em uma resposta do dig | Redes | Todo registro em uma seção do dig são cinco colunas: nome, TTL, classe, tipo e rdata. Este artigo percorre as colunas e depois o rdata dos tipos de registro que você realmente encontra, de A e CNAME a MX, SOA, SRV e CAA, para que uma parede de registros se leia como fatos simples. |
| O EDNS e a pseudo-seção OPT | Redes | A pseudo-seção OPT não é um registro e não é algo que você consultou: é metadado do EDNS(0) que o dig mostra perto do topo de uma resposta. Ela carrega o tamanho do payload UDP, a flag DO que solicita DNSSEC e opções como COOKIE, e explica silenciosamente toda uma classe de falhas de resolução. |
| Registros DNSSEC na saída do dig | Redes | Adicione +dnssec e uma resposta do dig ganha uma nova família de registros: RRSIG, DNSKEY, DS e os registros de negação NSEC ou NSEC3. Este artigo explica o que é cada um, como eles se encadeiam da raiz até uma zona, e o que a flag ad realmente certifica. |
| Lendo a saída do nslookup | Redes | O nslookup imprime um cabeçalho Server / Address para o resolvedor usado, um marcador opcional Non-authoritative answer, e então a resposta em um formato de prosa por tipo. Conhecer essa forma permite ler qualquer resultado rapidamente e ver num relance se ele teve sucesso, de onde veio e o que significa. |
| nslookup vs dig: qual usar | Redes | O nslookup e o dig ambos consultam DNS, mas o nslookup é mais enxuto e esconde as flags do cabeçalho e os TTLs que o dig mostra por completo. Este artigo mapeia uma saída sobre a outra e dá uma regra simples para saber qual usar. |
| Como o nslookup imprime cada tipo de registro | Redes | Em vez das colunas fixas do dig, o nslookup rotula cada registro em prosa: mail exchanger =, canonical name =, nameserver = e um bloco de várias linhas para o SOA. Um guia curto para ler a linha de cada tipo. |
| Respostas autoritativas vs não autoritativas | Redes | O marcador Non-authoritative answer no nslookup significa que o resultado veio do cache de um resolvedor, não de um servidor que de fato mantém a zona. Este artigo explica a diferença, por que ela normalmente não é problema, e como obter uma resposta autoritativa quando você precisa. |
| Erros do nslookup e o que significam | Redes | Quando uma consulta falha, o nslookup imprime uma linha como ** server can't find NAME: CODE. O código é o diagnóstico inteiro. Este artigo cobre NXDOMAIN, SERVFAIL, REFUSED e timeouts, o que cada um diz, e a primeira coisa a verificar para cada. |
| Consultas DNS reversas com o nslookup | Redes | O DNS reverso mapeia um endereço IP de volta para um nome por meio de registros PTR que ficam sob in-addr.arpa para IPv4 e ip6.arpa para IPv6. O nslookup faz isso automaticamente quando você lhe passa um endereço. Este artigo cobre como o nome reverso especial é construído, por que os servidores de e-mail se importam, e por que o direto e o reverso podem legitimamente discordar. |
| Modo interativo do nslookup | Redes | Execute o nslookup sem argumentos e ele entra em um prompt interativo onde você pode trocar de resolvedor, mudar o tipo de registro, ligar a saída de debug e consultar vários nomes em uma única sessão. Este artigo cobre o punhado de comandos que vale a pena conhecer e quando o interativo vence uma consulta única. |
| Opções de consulta e controle de saída do dig | Redes | O verdadeiro poder do dig está em suas opções: escolher qual servidor perguntar, o tipo de registro e exatamente quanto da resposta imprimir. Este artigo cobre o punhado que você realmente usará todo dia, de @servidor e -t a +short e a combinação +noall +answer que reduz o dig a apenas os registros. |
| Seguindo a delegação com dig +trace | Redes | O dig +trace resolve um nome da forma como a internet de fato faz: começando na raiz, seguindo a delegação para o TLD e então para os próprios servidores autoritativos do domínio, imprimindo cada salto. É a melhor forma de ver onde a resolução quebra e de entender como o DNS é costurado. |
| Lendo um comando curl | RedesWeb e HTTP | Um comando curl é um comando de shell: a palavra curl, um conjunto de opções e uma URL. Lê-lo é ver como o shell primeiro divide a linha (aspas, contrabarras, continuações de linha) e depois como o curl lê sinalizadores curtos, longos e agrupados. |
| Sinalizadores de dados do curl e a armadilha do Content-Type | RedesWeb e HTTP | O curl tem várias formas de anexar um corpo, e elas diferem na codificação e no Content-Type padrão. A grande surpresa é que -d usa codificação de formulário por padrão, não JSON, então um corpo JSON pode ser rotulado errado e recusado. |
| Traduzindo curl para fetch() | RedesWeb e HTTP | A API fetch do navegador e o curl descrevem a mesma requisição de formas diferentes. Método, cabeçalhos e corpo se mapeiam de forma limpa, mas algumas diferenças (Content-Type de formulário implícito, cookies e verificação TLS) exigem cuidado. |
| Cabeçalhos, autenticação e cookies no curl | RedesWeb e HTTP | Cabeçalhos, autenticação e cookies são como uma requisição se identifica e se autoriza. -H adiciona cabeçalhos, -u é HTTP Basic, um token bearer é apenas um cabeçalho, e -b/-c cuidam de cookies. Todos são sensíveis. |
| Como o curl infere o método HTTP | RedesWeb e HTTP | O curl nem sempre precisa de -X para escolher um método. Dados no corpo implicam POST, -I implica HEAD, -G força GET, e um -X explícito sempre vence. Conhecer as regras diz num relance o que uma requisição fará. |
| Sinalizadores do curl que mudam a postura de segurança | RedesWeb e HTTP | Alguns sinalizadores do curl mudam o quão segura é uma requisição: -k desativa a verificação TLS, http envia tudo em texto puro, e credenciais na URL podem vazar. Nenhum torna uma requisição maliciosa, mas cada um vale a leitura antes de executar ou compartilhar um comando. |
| O Proxy TCP: O Que um Middlebox de Camada 4 Vê e o Que Não Vê | RedesWeb e HTTP | Um proxy TCP termina a conexão TCP do cliente e abre uma separada para o servidor, unindo dois fluxos independentes na Camada 4. Ele reescreve endereços e portas, pode agrupar e reutilizar conexões, e não vê nada do payload da aplicação acima do cabeçalho de transporte. Este artigo explica full-proxy versus encaminhamento de pacotes, por que o IP de origem desaparece, e como o Proxy Protocol o traz de volta. |
| Proxies HTTP: Forward vs Reverse, Explícito vs Transparente | RedesWeb e HTTP | Um proxy HTTP parseia requisições na Camada 7, então pode rotear por URL, reescrever cabeçalhos e impor política sobre conteúdo que um proxy TCP não consegue ver. Dois eixos descrevem toda implantação: forward vs reverse (para qual lado ele trabalha) e explícito vs transparente (se o cliente sabe que ele está lá). Este artigo cobre o método CONNECT, o X-Forwarded-For e o Via, e onde cada combinação é usada. |
| Os 27 protocolos que o curl fala | RedesWeb e HTTP | O curl é conhecido como ferramenta de HTTP, mas a versão atual fala 27 esquemas de URL: transferência de arquivos por FTP, SFTP e SMB, e-mail por SMTP, POP3 e IMAP, publish-subscribe MQTT, consultas LDAP e relíquias como Gopher, DICT e Telnet. Conhecer o mapa, e saber quais esquemas começam em texto claro, muda a forma de usar a ferramenta. |
Segurança e WAF (31)
Cabeçalhos de Segurança HTTP: a Camada de Defesa em Profundidade
O que são os cabeçalhos de segurança HTTP, por que formam uma camada de defesa sobre o código seguro em vez de substituí-lo, quais cabeçalhos têm mais peso e como ler a postura de uma resposta rapidamente.
Segurança e WAFLerQuantificadores e Classes de Caracteres em Regex
Uma expressão regular é construída a partir de duas perguntas: qual caractere eu quero e quantos deles? As classes de caracteres respondem à primeira, os quantificadores respondem à segunda. Acerte essas duas e a maior parte das regex se encaixa.
Segurança e WAFWeb e HTTPLerSAML 2.0: Como Funciona o SSO no Navegador
O que é uma asserção SAML, os papéis do provedor de identidade e do provedor de serviço, o fluxo de Web Browser SSO iniciado pelo SP de ponta a ponta, e a diferença entre os bindings HTTP-POST e HTTP-Redirect que transportam as mensagens.
Segurança e WAFIdentidade e tokensLerContent Security Policy, Diretiva por Diretiva
Como a CSP funciona como controle contra cross-site scripting e injeção: a forma de uma política, por que default-src importa, o que 'unsafe-inline' e 'unsafe-eval' entregam, como nonces e hashes permitem código inline específico com segurança e para que serve o modo report-only.
Segurança e WAFLerDentro de uma Asserção SAML: Sujeito, Condições e Audiência
A anatomia de uma asserção SAML: o Subject e os formatos de NameID, a SubjectConfirmation do tipo bearer e as verificações de NotOnOrAfter / Recipient / InResponseTo, a janela de validade das Conditions, a AudienceRestriction e o AuthnStatement, com a validação que um provedor de serviço deve fazer em cada uma.
Segurança e WAFIdentidade e tokensLerGrupos, Retrorreferências e Lookarounds em Regex
Os parênteses fazem muito mais do que definir precedência em uma regex. Eles capturam texto para você reutilizar, nomeiam as partes que importam e — com um prefixo de interrogação — permitem afirmar o que vem antes ou depois sem consumir.
Segurança e WAFWeb e HTTPLerAssinaturas SAML e XML-DSig
Como uma mensagem SAML é assinada com XML Signature: o ds:Signature envelopado, os algoritmos SignatureMethod e DigestMethod, por que o SHA-1 é fraco, a diferença entre assinar a Response e assinar a Assertion, e como funcionam os ataques de signature wrapping em XML.
Segurança e WAFIdentidade e tokensLerBacktracking Catastrófico e ReDoS
Alguns padrões de aparência inocente podem levar segundos, minutos ou praticamente uma eternidade em uma string curta. A causa é o backtracking catastrófico, e quando um atacante controla a entrada ele vira uma falha de negação de serviço. Eis por que acontece e como escrever padrões que não podem travar.
Segurança e WAFWeb e HTTPLerHSTS e a Exigência de HTTPS
Como o Strict-Transport-Security fecha a janela de downgrade para HTTP, o que max-age, includeSubDomains e preload fazem, a brecha de confiança no primeiro uso que o preload remove e os erros de configuração que silenciosamente o desativam.
Segurança e WAFLerÂncoras e limites em regex
Âncoras casam uma posição, não um caractere: o início ou o fim da string, ou a borda de uma palavra. São a diferença entre um padrão que casa em qualquer lugar e um que casa só onde você quer. Este artigo cobre ^, $, \b e seu comportamento em modo multilinha, além dos erros que causam.
Segurança e WAFWeb e HTTPLerFlags de Segurança de Cookies
Como Secure, HttpOnly e SameSite protegem os cookies de sessão, o que cada valor de SameSite significa, por que SameSite=None exige Secure e como os prefixos __Host- e __Secure- impõem essas garantias no nível do navegador.
Segurança e WAFLerXXE e Por Que um Parser SAML Rejeita DOCTYPE
Como funcionam os ataques de Entidade Externa de XML (XXE), a negação de serviço billion laughs, por que ambos dependem de uma DTD, e por que um decodificador SAML reforçado rejeita qualquer DOCTYPE ou declaração de entidade de imediato em vez de tentar interpretá-lo com segurança.
Segurança e WAFIdentidade e tokensLerBindings SAML e iniciação por SP vs IdP
Um fluxo SAML pode começar no serviço ou no provedor de identidade, e as mensagens podem viajar por dois bindings diferentes: um redirect HTTP com a mensagem compactada na URL, ou um formulário HTML de auto-submit que a envia por POST. Qual binding carrega qual mensagem, e onde o fluxo começa, explica muito do comportamento do SSO.
Segurança e WAFIdentidade e tokensLerClickjacking e Controle de Enquadramento
O que é clickjacking, como o enquadramento o torna possível, a diferença entre o cabeçalho legado X-Frame-Options e a diretiva moderna CSP frame-ancestors, por que ALLOW-FROM é obsoleto e como os dois controles interagem.
Segurança e WAFLerFlags e modos em regex
Uma flag muda como o padrão inteiro casa: sensibilidade a maiúsculas, se ^ e $ enxergam linhas, se o ponto cruza quebras de linha e se o espaço em branco no padrão é ignorado. O mesmo regex pode casar coisas completamente diferentes dependendo de suas flags, então conhecê-las evita muita confusão.
Segurança e WAFWeb e HTTPLerO SAML Proxy: Inserindo uma Camada de Identidade numa Sessão
Um SAML proxy fica no fluxo de SSO em vez do caminho dos pacotes: ele termina a requisição do usuário, força a autenticação contra um provedor de identidade, e só então deixa a sessão passar, usando o modelo de redirecionamento por navegador do SAML. Ele pode agir como provedor de serviço para o IdP e provedor de identidade para a aplicação ao mesmo tempo (um proxy ou broker), que é como um único login federa muitos sistemas downstream. Este artigo explica os papéis, o fluxo, e por que ele é um proxy afinal.
Segurança e WAFIdentidade e tokensLerXXE e entidades externas
XML permite que um documento declare entidades, e uma entidade externa pode apontar para um arquivo ou URL. Um parser que resolve uma pode ser enganado a ler arquivos locais ou fazer requisições no lado do servidor, a vulnerabilidade XXE. A correção é direta e eficaz: não processar um DOCTYPE de forma alguma.
Segurança e WAFLerBillion laughs e expansão de entidades
Entidades podem referenciar outras entidades, e se cada uma multiplica a anterior, um documento minúsculo pode expandir para gigabytes e exaurir a memória. O ataque billion laughs transforma isso em uma negação de serviço. A defesa é limitar a expansão ou recusar o DOCTYPE de imediato.
Segurança e WAFLerComo Funciona a Pontuação CVSS
O CVSS transforma uma string de vetor curta em um número de severidade de 0 a 10 usando uma fórmula fixa. A pontuação Base é construída a partir de duas subpontuações: Explorabilidade (quão acessível e fácil é a falha) e Impacto (quão grave é o resultado). Todo o resto refina essa base. Isso é aritmética, não opinião, e por isso uma calculadora reproduz exatamente qualquer pontuação publicada.
Segurança e WAFLerAs Métricas Base do CVSS, Explicadas
A pontuação Base vem de oito métricas em duas famílias. Quatro métricas de explorabilidade (Vetor de Ataque, Complexidade do Ataque, Privilégios Necessários, Interação do Usuário) descrevem quão difícil é o ataque, e quatro métricas de impacto (Escopo, mais Confidencialidade, Integridade e Disponibilidade) descrevem o dano. O Escopo é a sutil: é o que permite que uma pontuação ultrapasse a fronteira do próprio componente vulnerável.
Segurança e WAFLerPontuações Temporal e Ambiental do CVSS
A pontuação Base é apenas o ponto de partida. As métricas Temporais a reduzem conforme os fatos surgem, como o lançamento de um patch, e só podem diminuir a pontuação. As métricas Ambientais permitem que uma organização recalcule a falha para seus próprios sistemas, elevando ou reduzindo a importância de confidencialidade, integridade e disponibilidade e sobrescrevendo métricas base. Ambas são opcionais, mas produzem um número mais honesto.
Segurança e WAFLerLendo uma String de Vetor CVSS
Um vetor CVSS é uma string compacta e autodescritiva: um prefixo de versão seguido de pares métrica:valor separados por barras. Aprender a lê-la diretamente, em vez de confiar em uma pontuação renderizada, permite detectar erros de transcrição e entender exatamente o que um fornecedor afirmou. As métricas Base são obrigatórias e o resto é opcional.
Segurança e WAFLerFaixas de Severidade do CVSS, e o Que a Pontuação Não Diz
O número de 0 a 10 é mapeado para cinco faixas qualitativas, de Nenhuma a Crítica. Esse mapeamento é útil para triagem, mas uma pontuação Base do CVSS mede severidade, não risco. Ela não diz nada sobre uma falha estar sendo explorada, quão valioso é o ativo, ou quais controles você tem. Tratar o número base como uma fila de prioridade é a forma mais comum de as equipes usarem mal o CVSS.
Segurança e WAFLerCVSS v3.0, v3.1 e v4.0: O Que Mudou
Este decodificador calcula CVSS v3.0 e v3.1. As duas versões v3 compartilham uma fórmula mas diferem no arredondamento e em um termo ambiental, então as pontuações podem diferir em um décimo. O CVSS v4.0, lançado em 2023, é um redesenho maior, com novos grupos de métricas e sem a métrica Escopo, e seus vetores não são compatíveis com ferramentas v3. O CVSS v2 está descontinuado.
Segurança e WAFLerO Que É Server-Side Request Forgery (SSRF)
SSRF é uma vulnerabilidade em que um atacante faz o servidor emitir uma requisição HTTP para um destino escolhido por ele. Como a requisição parte de dentro da rede do servidor, ela alcança serviços internos, metadados de nuvem e endereços de loopback que o atacante jamais alcançaria diretamente. A correção é validar o destino, não o texto da URL.
Segurança e WAFLerFaixas de IP Privadas, Reservadas e Públicas
Um filtro de SSRF precisa saber quais endereços são internos. Este é o mapa: espaço privado RFC 1918, loopback, link-local, NAT de operadora, as faixas de documentação e todo o resto que é público e roteável. Conhecer as faixas é o que transforma um endereço bruto em uma decisão de seguro-ou-não.
Segurança e WAFLerTruques de Ofuscação de Endereço IP
Um endereço IP pode ser escrito de muitas formas: decimal simples, octal, hexadecimal, forma abreviada e IPv6 mapeado em IPv4. Cada forma volta a apontar para o mesmo endereço, e é assim que atacantes passam um alvo interno por um filtro que só bloqueia a grafia decimal pontuada. Por isso verificações de SSRF precisam decodificar, não comparar texto.
Segurança e WAFLerEndpoints de Metadados de Nuvem e SSRF
Toda nuvem grande dá a uma instância um serviço de metadados em um endereço link-local fixo, e ele pode devolver credenciais temporárias do papel da instância. Isso o torna o alvo de SSRF de maior valor. Conhecer os endpoints, e as defesas no estilo IMDSv2, é essencial tanto para entender o ataque quanto para a defesa.
Segurança e WAFLerDefendendo-se de SSRF com Allow-Lists
A defesa durável contra SSRF é uma allow-list de destinos pretendidos, combinada com resolver o endereço antes de confiar nele e reverificar após redirecionamentos. Block-lists de faixas internas ajudam, mas perdem para ofuscação e DNS rebinding. Esta é a abordagem em camadas que se sustenta.
Segurança e WAFLerEsquemas de URL Perigosos em SSRF
SSRF não se limita a http. Esquemas como file, gopher, dict e ftp permitem a um atacante ler arquivos locais ou forjar bytes brutos para serviços internos como Redis e SMTP. Um buscador de URL que não restringe o esquema entrega ao atacante uma primitiva muito mais poderosa do que uma simples requisição web.
Segurança e WAFLerSSL Forward Proxy: Como Funciona a Interceptação de TLS de Saída e o Que a Quebra
Para inspecionar tráfego de saída criptografado, um forward proxy realiza um man-in-the-middle controlado: ele termina a sessão TLS do usuário, abre a sua própria para o servidor real, e forja um certificado para aquele servidor assinado por uma CA privada em que os próprios dispositivos da organização confiam. Este artigo explica a mecânica, o modelo de confiança que o torna seguro (e perigoso), e por que pinning, HSTS e TLS mútuo o derrotam.
Segurança e WAFCertificados e PKITLS e transporteLer
| Artigo | Tema | Resumo |
|---|---|---|
| Cabeçalhos de Segurança HTTP: a Camada de Defesa em Profundidade | Segurança e WAF | O que são os cabeçalhos de segurança HTTP, por que formam uma camada de defesa sobre o código seguro em vez de substituí-lo, quais cabeçalhos têm mais peso e como ler a postura de uma resposta rapidamente. |
| Quantificadores e Classes de Caracteres em Regex | Segurança e WAFWeb e HTTP | Uma expressão regular é construída a partir de duas perguntas: qual caractere eu quero e quantos deles? As classes de caracteres respondem à primeira, os quantificadores respondem à segunda. Acerte essas duas e a maior parte das regex se encaixa. |
| SAML 2.0: Como Funciona o SSO no Navegador | Segurança e WAFIdentidade e tokens | O que é uma asserção SAML, os papéis do provedor de identidade e do provedor de serviço, o fluxo de Web Browser SSO iniciado pelo SP de ponta a ponta, e a diferença entre os bindings HTTP-POST e HTTP-Redirect que transportam as mensagens. |
| Content Security Policy, Diretiva por Diretiva | Segurança e WAF | Como a CSP funciona como controle contra cross-site scripting e injeção: a forma de uma política, por que default-src importa, o que 'unsafe-inline' e 'unsafe-eval' entregam, como nonces e hashes permitem código inline específico com segurança e para que serve o modo report-only. |
| Dentro de uma Asserção SAML: Sujeito, Condições e Audiência | Segurança e WAFIdentidade e tokens | A anatomia de uma asserção SAML: o Subject e os formatos de NameID, a SubjectConfirmation do tipo bearer e as verificações de NotOnOrAfter / Recipient / InResponseTo, a janela de validade das Conditions, a AudienceRestriction e o AuthnStatement, com a validação que um provedor de serviço deve fazer em cada uma. |
| Grupos, Retrorreferências e Lookarounds em Regex | Segurança e WAFWeb e HTTP | Os parênteses fazem muito mais do que definir precedência em uma regex. Eles capturam texto para você reutilizar, nomeiam as partes que importam e — com um prefixo de interrogação — permitem afirmar o que vem antes ou depois sem consumir. |
| Assinaturas SAML e XML-DSig | Segurança e WAFIdentidade e tokens | Como uma mensagem SAML é assinada com XML Signature: o ds:Signature envelopado, os algoritmos SignatureMethod e DigestMethod, por que o SHA-1 é fraco, a diferença entre assinar a Response e assinar a Assertion, e como funcionam os ataques de signature wrapping em XML. |
| Backtracking Catastrófico e ReDoS | Segurança e WAFWeb e HTTP | Alguns padrões de aparência inocente podem levar segundos, minutos ou praticamente uma eternidade em uma string curta. A causa é o backtracking catastrófico, e quando um atacante controla a entrada ele vira uma falha de negação de serviço. Eis por que acontece e como escrever padrões que não podem travar. |
| HSTS e a Exigência de HTTPS | Segurança e WAF | Como o Strict-Transport-Security fecha a janela de downgrade para HTTP, o que max-age, includeSubDomains e preload fazem, a brecha de confiança no primeiro uso que o preload remove e os erros de configuração que silenciosamente o desativam. |
| Âncoras e limites em regex | Segurança e WAFWeb e HTTP | Âncoras casam uma posição, não um caractere: o início ou o fim da string, ou a borda de uma palavra. São a diferença entre um padrão que casa em qualquer lugar e um que casa só onde você quer. Este artigo cobre ^, $, \b e seu comportamento em modo multilinha, além dos erros que causam. |
| Flags de Segurança de Cookies | Segurança e WAF | Como Secure, HttpOnly e SameSite protegem os cookies de sessão, o que cada valor de SameSite significa, por que SameSite=None exige Secure e como os prefixos __Host- e __Secure- impõem essas garantias no nível do navegador. |
| XXE e Por Que um Parser SAML Rejeita DOCTYPE | Segurança e WAFIdentidade e tokens | Como funcionam os ataques de Entidade Externa de XML (XXE), a negação de serviço billion laughs, por que ambos dependem de uma DTD, e por que um decodificador SAML reforçado rejeita qualquer DOCTYPE ou declaração de entidade de imediato em vez de tentar interpretá-lo com segurança. |
| Bindings SAML e iniciação por SP vs IdP | Segurança e WAFIdentidade e tokens | Um fluxo SAML pode começar no serviço ou no provedor de identidade, e as mensagens podem viajar por dois bindings diferentes: um redirect HTTP com a mensagem compactada na URL, ou um formulário HTML de auto-submit que a envia por POST. Qual binding carrega qual mensagem, e onde o fluxo começa, explica muito do comportamento do SSO. |
| Clickjacking e Controle de Enquadramento | Segurança e WAF | O que é clickjacking, como o enquadramento o torna possível, a diferença entre o cabeçalho legado X-Frame-Options e a diretiva moderna CSP frame-ancestors, por que ALLOW-FROM é obsoleto e como os dois controles interagem. |
| Flags e modos em regex | Segurança e WAFWeb e HTTP | Uma flag muda como o padrão inteiro casa: sensibilidade a maiúsculas, se ^ e $ enxergam linhas, se o ponto cruza quebras de linha e se o espaço em branco no padrão é ignorado. O mesmo regex pode casar coisas completamente diferentes dependendo de suas flags, então conhecê-las evita muita confusão. |
| O SAML Proxy: Inserindo uma Camada de Identidade numa Sessão | Segurança e WAFIdentidade e tokens | Um SAML proxy fica no fluxo de SSO em vez do caminho dos pacotes: ele termina a requisição do usuário, força a autenticação contra um provedor de identidade, e só então deixa a sessão passar, usando o modelo de redirecionamento por navegador do SAML. Ele pode agir como provedor de serviço para o IdP e provedor de identidade para a aplicação ao mesmo tempo (um proxy ou broker), que é como um único login federa muitos sistemas downstream. Este artigo explica os papéis, o fluxo, e por que ele é um proxy afinal. |
| XXE e entidades externas | Segurança e WAF | XML permite que um documento declare entidades, e uma entidade externa pode apontar para um arquivo ou URL. Um parser que resolve uma pode ser enganado a ler arquivos locais ou fazer requisições no lado do servidor, a vulnerabilidade XXE. A correção é direta e eficaz: não processar um DOCTYPE de forma alguma. |
| Billion laughs e expansão de entidades | Segurança e WAF | Entidades podem referenciar outras entidades, e se cada uma multiplica a anterior, um documento minúsculo pode expandir para gigabytes e exaurir a memória. O ataque billion laughs transforma isso em uma negação de serviço. A defesa é limitar a expansão ou recusar o DOCTYPE de imediato. |
| Como Funciona a Pontuação CVSS | Segurança e WAF | O CVSS transforma uma string de vetor curta em um número de severidade de 0 a 10 usando uma fórmula fixa. A pontuação Base é construída a partir de duas subpontuações: Explorabilidade (quão acessível e fácil é a falha) e Impacto (quão grave é o resultado). Todo o resto refina essa base. Isso é aritmética, não opinião, e por isso uma calculadora reproduz exatamente qualquer pontuação publicada. |
| As Métricas Base do CVSS, Explicadas | Segurança e WAF | A pontuação Base vem de oito métricas em duas famílias. Quatro métricas de explorabilidade (Vetor de Ataque, Complexidade do Ataque, Privilégios Necessários, Interação do Usuário) descrevem quão difícil é o ataque, e quatro métricas de impacto (Escopo, mais Confidencialidade, Integridade e Disponibilidade) descrevem o dano. O Escopo é a sutil: é o que permite que uma pontuação ultrapasse a fronteira do próprio componente vulnerável. |
| Pontuações Temporal e Ambiental do CVSS | Segurança e WAF | A pontuação Base é apenas o ponto de partida. As métricas Temporais a reduzem conforme os fatos surgem, como o lançamento de um patch, e só podem diminuir a pontuação. As métricas Ambientais permitem que uma organização recalcule a falha para seus próprios sistemas, elevando ou reduzindo a importância de confidencialidade, integridade e disponibilidade e sobrescrevendo métricas base. Ambas são opcionais, mas produzem um número mais honesto. |
| Lendo uma String de Vetor CVSS | Segurança e WAF | Um vetor CVSS é uma string compacta e autodescritiva: um prefixo de versão seguido de pares métrica:valor separados por barras. Aprender a lê-la diretamente, em vez de confiar em uma pontuação renderizada, permite detectar erros de transcrição e entender exatamente o que um fornecedor afirmou. As métricas Base são obrigatórias e o resto é opcional. |
| Faixas de Severidade do CVSS, e o Que a Pontuação Não Diz | Segurança e WAF | O número de 0 a 10 é mapeado para cinco faixas qualitativas, de Nenhuma a Crítica. Esse mapeamento é útil para triagem, mas uma pontuação Base do CVSS mede severidade, não risco. Ela não diz nada sobre uma falha estar sendo explorada, quão valioso é o ativo, ou quais controles você tem. Tratar o número base como uma fila de prioridade é a forma mais comum de as equipes usarem mal o CVSS. |
| CVSS v3.0, v3.1 e v4.0: O Que Mudou | Segurança e WAF | Este decodificador calcula CVSS v3.0 e v3.1. As duas versões v3 compartilham uma fórmula mas diferem no arredondamento e em um termo ambiental, então as pontuações podem diferir em um décimo. O CVSS v4.0, lançado em 2023, é um redesenho maior, com novos grupos de métricas e sem a métrica Escopo, e seus vetores não são compatíveis com ferramentas v3. O CVSS v2 está descontinuado. |
| O Que É Server-Side Request Forgery (SSRF) | Segurança e WAF | SSRF é uma vulnerabilidade em que um atacante faz o servidor emitir uma requisição HTTP para um destino escolhido por ele. Como a requisição parte de dentro da rede do servidor, ela alcança serviços internos, metadados de nuvem e endereços de loopback que o atacante jamais alcançaria diretamente. A correção é validar o destino, não o texto da URL. |
| Faixas de IP Privadas, Reservadas e Públicas | Segurança e WAF | Um filtro de SSRF precisa saber quais endereços são internos. Este é o mapa: espaço privado RFC 1918, loopback, link-local, NAT de operadora, as faixas de documentação e todo o resto que é público e roteável. Conhecer as faixas é o que transforma um endereço bruto em uma decisão de seguro-ou-não. |
| Truques de Ofuscação de Endereço IP | Segurança e WAF | Um endereço IP pode ser escrito de muitas formas: decimal simples, octal, hexadecimal, forma abreviada e IPv6 mapeado em IPv4. Cada forma volta a apontar para o mesmo endereço, e é assim que atacantes passam um alvo interno por um filtro que só bloqueia a grafia decimal pontuada. Por isso verificações de SSRF precisam decodificar, não comparar texto. |
| Endpoints de Metadados de Nuvem e SSRF | Segurança e WAF | Toda nuvem grande dá a uma instância um serviço de metadados em um endereço link-local fixo, e ele pode devolver credenciais temporárias do papel da instância. Isso o torna o alvo de SSRF de maior valor. Conhecer os endpoints, e as defesas no estilo IMDSv2, é essencial tanto para entender o ataque quanto para a defesa. |
| Defendendo-se de SSRF com Allow-Lists | Segurança e WAF | A defesa durável contra SSRF é uma allow-list de destinos pretendidos, combinada com resolver o endereço antes de confiar nele e reverificar após redirecionamentos. Block-lists de faixas internas ajudam, mas perdem para ofuscação e DNS rebinding. Esta é a abordagem em camadas que se sustenta. |
| Esquemas de URL Perigosos em SSRF | Segurança e WAF | SSRF não se limita a http. Esquemas como file, gopher, dict e ftp permitem a um atacante ler arquivos locais ou forjar bytes brutos para serviços internos como Redis e SMTP. Um buscador de URL que não restringe o esquema entrega ao atacante uma primitiva muito mais poderosa do que uma simples requisição web. |
| SSL Forward Proxy: Como Funciona a Interceptação de TLS de Saída e o Que a Quebra | Segurança e WAFCertificados e PKITLS e transporte | Para inspecionar tráfego de saída criptografado, um forward proxy realiza um man-in-the-middle controlado: ele termina a sessão TLS do usuário, abre a sua própria para o servidor real, e forja um certificado para aquele servidor assinado por uma CA privada em que os próprios dispositivos da organização confiam. Este artigo explica a mecânica, o modelo de confiança que o torna seguro (e perigoso), e por que pinning, HSTS e TLS mútuo o derrotam. |
TLS e transporte (9)
Anatomia de uma suíte de cifra TLS
O que uma suíte de cifra TLS realmente nomeia, como ler uma suíte como TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 parte por parte, e como o mesmo ponto de código de dois bytes aparece sob três convenções de nomes diferentes.
TLS e transporteLerLendo nomes de suítes de cifra: IANA, OpenSSL e GnuTLS
Por que a mesma suíte de cifra tem três nomes diferentes e um ponto de código de dois bytes, como traduzir entre as convenções da IANA, do OpenSSL e do GnuTLS, e o que a coluna Recommended da IANA, com Y, N e D, realmente significa.
TLS e transporteLerAEAD vs CBC: por que o modo importa
A diferença prática entre uma cifra AEAD como o AES-GCM e uma cifra CBC mais antiga com um HMAC separado, os ataques de oráculo de preenchimento que mataram o MAC-then-encrypt, e a única troca que o AEAD ainda pede.
TLS e transporteLerSigilo de encaminhamento e a troca de chaves
O que o sigilo de encaminhamento garante, por que o transporte de chave RSA estático não o oferece, como ECDHE e DHE oferecem, e por que autenticação e troca de chaves são duas tarefas distintas que o nome de uma suíte mantém separadas.
TLS e transporteLerSuítes de cifra do TLS 1.3: o que mudou
Por que uma suíte de TLS 1.3 nomeia apenas uma cifra e um hash, para onde foram a troca de chaves e a autenticação, e por que a lista de suítes encolheu de centenas para um punhado.
TLS e transporteLerO Que um Computador Quântico Quebraria, e o Que Não Quebraria
Um computador quântico grande não enfraqueceria toda a criptografia por igual. O algoritmo de Shor quebra por completo a matemática de chave pública por trás de RSA, Diffie-Hellman e curvas elípticas; o algoritmo de Grover apenas reduz pela metade a força de cifras simétricas e hashes, o que AES-256 e SHA-384 já suportam. Este artigo explica a divisão, por que 'colher agora, decifrar depois' torna isso um problema de hoje, e por que um candidato quebrado como o SIKE é um lembrete de humildade.
TLS e transporteLerOs Padrões Pós-Quânticos do NIST: ML-KEM, ML-DSA e SLH-DSA
Em agosto de 2024 o NIST finalizou os três primeiros padrões pós-quânticos: FIPS 203 (ML-KEM, do Kyber) para estabelecimento de chaves, e FIPS 204 (ML-DSA, do Dilithium) e FIPS 205 (SLH-DSA, do SPHINCS+) para assinaturas. Este artigo explica para que serve cada um, por que há dois padrões de assinatura sobre matemáticas diferentes, e onde o HQC e o FN-DSA entram como reservas ainda a caminho.
TLS e transporteLerTroca de Chaves Híbrida no TLS 1.3: O Que o X25519MLKEM768 Faz no Fio
A web não trocou a troca de chaves clássica pela pós-quântica; ela roda as duas ao mesmo tempo. O X25519MLKEM768 combina uma curva elíptica dos anos 1990 com o ML-KEM-768 baseado em reticulado num único grupo do TLS 1.3, de modo que a quebra de qualquer um ainda deixa a sessão segura. Este artigo cobre por que híbrido em vez de substituição, o formato no fio e seu problema de tamanho, e onde está a implantação entre navegadores, servidores e os middleboxes que ele quebra.
TLS e transporteLerTLS de Entrada: Offload, Bridging e Passthrough no Reverse Proxy
Um reverse proxy que trata HTTPS de entrada tem três escolhas para a sessão TLS: terminá-la e enviar texto claro ao backend (offload), terminar e recriptografar até o backend (bridging), ou encaminhar os bytes criptografados intocados (passthrough). Cada uma equilibra visibilidade contra confidencialidade e custo de forma diferente. Este artigo explica as três, por que o proxy detém o certificado do servidor, e o que o SNI e o TLS mútuo mudam.
TLS e transporteCertificados e PKILer
| Artigo | Tema | Resumo |
|---|---|---|
| Anatomia de uma suíte de cifra TLS | TLS e transporte | O que uma suíte de cifra TLS realmente nomeia, como ler uma suíte como TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 parte por parte, e como o mesmo ponto de código de dois bytes aparece sob três convenções de nomes diferentes. |
| Lendo nomes de suítes de cifra: IANA, OpenSSL e GnuTLS | TLS e transporte | Por que a mesma suíte de cifra tem três nomes diferentes e um ponto de código de dois bytes, como traduzir entre as convenções da IANA, do OpenSSL e do GnuTLS, e o que a coluna Recommended da IANA, com Y, N e D, realmente significa. |
| AEAD vs CBC: por que o modo importa | TLS e transporte | A diferença prática entre uma cifra AEAD como o AES-GCM e uma cifra CBC mais antiga com um HMAC separado, os ataques de oráculo de preenchimento que mataram o MAC-then-encrypt, e a única troca que o AEAD ainda pede. |
| Sigilo de encaminhamento e a troca de chaves | TLS e transporte | O que o sigilo de encaminhamento garante, por que o transporte de chave RSA estático não o oferece, como ECDHE e DHE oferecem, e por que autenticação e troca de chaves são duas tarefas distintas que o nome de uma suíte mantém separadas. |
| Suítes de cifra do TLS 1.3: o que mudou | TLS e transporte | Por que uma suíte de TLS 1.3 nomeia apenas uma cifra e um hash, para onde foram a troca de chaves e a autenticação, e por que a lista de suítes encolheu de centenas para um punhado. |
| O Que um Computador Quântico Quebraria, e o Que Não Quebraria | TLS e transporte | Um computador quântico grande não enfraqueceria toda a criptografia por igual. O algoritmo de Shor quebra por completo a matemática de chave pública por trás de RSA, Diffie-Hellman e curvas elípticas; o algoritmo de Grover apenas reduz pela metade a força de cifras simétricas e hashes, o que AES-256 e SHA-384 já suportam. Este artigo explica a divisão, por que 'colher agora, decifrar depois' torna isso um problema de hoje, e por que um candidato quebrado como o SIKE é um lembrete de humildade. |
| Os Padrões Pós-Quânticos do NIST: ML-KEM, ML-DSA e SLH-DSA | TLS e transporte | Em agosto de 2024 o NIST finalizou os três primeiros padrões pós-quânticos: FIPS 203 (ML-KEM, do Kyber) para estabelecimento de chaves, e FIPS 204 (ML-DSA, do Dilithium) e FIPS 205 (SLH-DSA, do SPHINCS+) para assinaturas. Este artigo explica para que serve cada um, por que há dois padrões de assinatura sobre matemáticas diferentes, e onde o HQC e o FN-DSA entram como reservas ainda a caminho. |
| Troca de Chaves Híbrida no TLS 1.3: O Que o X25519MLKEM768 Faz no Fio | TLS e transporte | A web não trocou a troca de chaves clássica pela pós-quântica; ela roda as duas ao mesmo tempo. O X25519MLKEM768 combina uma curva elíptica dos anos 1990 com o ML-KEM-768 baseado em reticulado num único grupo do TLS 1.3, de modo que a quebra de qualquer um ainda deixa a sessão segura. Este artigo cobre por que híbrido em vez de substituição, o formato no fio e seu problema de tamanho, e onde está a implantação entre navegadores, servidores e os middleboxes que ele quebra. |
| TLS de Entrada: Offload, Bridging e Passthrough no Reverse Proxy | TLS e transporteCertificados e PKI | Um reverse proxy que trata HTTPS de entrada tem três escolhas para a sessão TLS: terminá-la e enviar texto claro ao backend (offload), terminar e recriptografar até o backend (bridging), ou encaminhar os bytes criptografados intocados (passthrough). Cada uma equilibra visibilidade contra confidencialidade e custo de forma diferente. Este artigo explica as três, por que o proxy detém o certificado do servidor, e o que o SNI e o TLS mútuo mudam. |