From 5a69e3c4779ae88ac45f2cb4ab197a7cb0fde13b Mon Sep 17 00:00:00 2001 From: Victor Hugo Nogueira Lima Date: Sat, 30 May 2026 17:26:31 -0300 Subject: [PATCH 1/2] Add pt-BR translated requirements CSV in docs_pt --- 5.0/docs_pt/OWASP_ASVS_v5_pt-BR.csv | 346 ++++++++++++++++++ 5.0/pt/0x00-Header.yaml | 16 + 5.0/pt/0x01-Frontispiece.md | 46 +++ 5.0/pt/0x02-Preface.md | 29 ++ 5.0/pt/0x03-What-is-the-ASVS.md | 195 ++++++++++ 5.0/pt/0x04-Assessment_and_Certification.md | 47 +++ 5.0/pt/0x05-For-Users-Of-4.0.md | 90 +++++ 5.0/pt/0x10-V1-Encoding-and-Sanitization.md | 103 ++++++ .../0x11-V2-Validation-and-Business-Logic.md | 73 ++++ 5.0/pt/0x12-V3-Web-Frontend-Security.md | 100 +++++ 5.0/pt/0x13-V4-API-and-Web-Service.md | 64 ++++ 5.0/pt/0x14-V5-File-Handling.md | 54 +++ 5.0/pt/0x15-V6-Authentication.md | 166 +++++++++ 5.0/pt/0x16-V7-Session-Management.md | 91 +++++ 5.0/pt/0x17-V8-Authorization.md | 56 +++ 5.0/pt/0x18-V9-Self-contained-Tokens.md | 36 ++ 5.0/pt/0x19-V10-OAuth-and-OIDC.md | 169 +++++++++ 5.0/pt/0x20-V11-Cryptography.md | 107 ++++++ 5.0/pt/0x21-V12-Secure-Communication.md | 57 +++ 5.0/pt/0x22-V13-Configuration.md | 68 ++++ 5.0/pt/0x23-V14-Data-Protection.md | 60 +++ ...0x24-V15-Secure-Coding-and-Architecture.md | 77 ++++ ...V16-Security-Logging-and-Error-Handling.md | 84 +++++ 5.0/pt/0x26-V17-WebRTC.md | 75 ++++ 5.0/pt/0x90-Appendix-A_Glossary.md | 89 +++++ 5.0/pt/0x91-Appendix-B_References.md | 43 +++ 5.0/pt/0x92-Appendix-C_Cryptography.md | 311 ++++++++++++++++ 5.0/pt/0x93-Appendix-D_Recommendations.md | 49 +++ 5.0/pt/0x94-Appendix-E_Contributors.md | 71 ++++ 29 files changed, 2772 insertions(+) create mode 100644 5.0/docs_pt/OWASP_ASVS_v5_pt-BR.csv create mode 100644 5.0/pt/0x00-Header.yaml create mode 100644 5.0/pt/0x01-Frontispiece.md create mode 100644 5.0/pt/0x02-Preface.md create mode 100644 5.0/pt/0x03-What-is-the-ASVS.md create mode 100644 5.0/pt/0x04-Assessment_and_Certification.md create mode 100644 5.0/pt/0x05-For-Users-Of-4.0.md create mode 100644 5.0/pt/0x10-V1-Encoding-and-Sanitization.md create mode 100644 5.0/pt/0x11-V2-Validation-and-Business-Logic.md create mode 100644 5.0/pt/0x12-V3-Web-Frontend-Security.md create mode 100644 5.0/pt/0x13-V4-API-and-Web-Service.md create mode 100644 5.0/pt/0x14-V5-File-Handling.md create mode 100644 5.0/pt/0x15-V6-Authentication.md create mode 100644 5.0/pt/0x16-V7-Session-Management.md create mode 100644 5.0/pt/0x17-V8-Authorization.md create mode 100644 5.0/pt/0x18-V9-Self-contained-Tokens.md create mode 100644 5.0/pt/0x19-V10-OAuth-and-OIDC.md create mode 100644 5.0/pt/0x20-V11-Cryptography.md create mode 100644 5.0/pt/0x21-V12-Secure-Communication.md create mode 100644 5.0/pt/0x22-V13-Configuration.md create mode 100644 5.0/pt/0x23-V14-Data-Protection.md create mode 100644 5.0/pt/0x24-V15-Secure-Coding-and-Architecture.md create mode 100644 5.0/pt/0x25-V16-Security-Logging-and-Error-Handling.md create mode 100644 5.0/pt/0x26-V17-WebRTC.md create mode 100644 5.0/pt/0x90-Appendix-A_Glossary.md create mode 100644 5.0/pt/0x91-Appendix-B_References.md create mode 100644 5.0/pt/0x92-Appendix-C_Cryptography.md create mode 100644 5.0/pt/0x93-Appendix-D_Recommendations.md create mode 100644 5.0/pt/0x94-Appendix-E_Contributors.md diff --git a/5.0/docs_pt/OWASP_ASVS_v5_pt-BR.csv b/5.0/docs_pt/OWASP_ASVS_v5_pt-BR.csv new file mode 100644 index 0000000000..d6e3ad2c7a --- /dev/null +++ b/5.0/docs_pt/OWASP_ASVS_v5_pt-BR.csv @@ -0,0 +1,346 @@ +chapter_id,chapter_name,section_id,section_name,req_id,req_description,L +V1,Codificação e Sanitização,V1.1,Arquitetura de Codificação e Sanitização,V1.1.1,"Verificar que a entrada é decodificada ou sem escape para uma forma canônica apenas uma vez, e somente quando dados codificados nessa forma são esperados, e que isso é feito antes do processamento adicional da entrada — por exemplo, não após validação ou sanitização da entrada.",2 +V1,Codificação e Sanitização,V1.1,Arquitetura de Codificação e Sanitização,V1.1.2,"Verificar que a aplicação realiza codificação e escape de saída como etapa final antes de ser usada pelo interpretador ao qual se destina, ou pelo próprio interpretador.",2 +V1,Codificação e Sanitização,V1.2,Prevenção de Injeção,V1.2.1,"Verificar que a codificação de saída para uma resposta HTTP, documento HTML ou documento XML é adequada ao contexto exigido, como codificar os caracteres relevantes para elementos HTML, atributos HTML, comentários HTML, CSS ou campos de cabeçalho HTTP, a fim de evitar a alteração da estrutura da mensagem ou do documento.",1 +V1,Codificação e Sanitização,V1.2,Prevenção de Injeção,V1.2.2,"Verificar que, ao construir URLs dinamicamente, dados não confiáveis são codificados conforme seu contexto (por exemplo, codificação de URL ou codificação base64url para parâmetros de consulta ou caminho). Garantir que apenas protocolos de URL seguros sejam permitidos (por exemplo, desabilitar javascript: ou data:).",1 +V1,Codificação e Sanitização,V1.2,Prevenção de Injeção,V1.2.3,"Verificar que codificação ou escape de saída é usado ao construir dinamicamente conteúdo JavaScript (incluindo JSON), para evitar a alteração da estrutura da mensagem ou do documento (para evitar injeção de JavaScript e JSON).",1 +V1,Codificação e Sanitização,V1.2,Prevenção de Injeção,V1.2.4,"Verificar que seleção de dados ou consultas a bancos de dados (por exemplo, SQL, HQL, NoSQL, Cypher) utilizam consultas parametrizadas, ORMs, frameworks de entidade ou são protegidas de outra forma contra ataques de Injeção de SQL e outras injeções em banco de dados. Isso também se aplica ao criar stored procedures.",1 +V1,Codificação e Sanitização,V1.2,Prevenção de Injeção,V1.2.5,Verificar que a aplicação protege contra injeção de comandos do sistema operacional e que chamadas ao sistema operacional utilizam consultas de SO parametrizadas ou codificação contextual de saída da linha de comando.,1 +V1,Codificação e Sanitização,V1.2,Prevenção de Injeção,V1.2.6,"Verificar que a aplicação protege contra vulnerabilidades de injeção de LDAP, ou que controles de segurança específicos para prevenir injeção de LDAP foram implementados.",2 +V1,Codificação e Sanitização,V1.2,Prevenção de Injeção,V1.2.7,Verificar que a aplicação está protegida contra ataques de injeção de XPath por meio de parametrização de consultas ou consultas pré-compiladas.,2 +V1,Codificação e Sanitização,V1.2,Prevenção de Injeção,V1.2.8,"Verificar que os processadores LaTeX estão configurados de forma segura (como não usar o sinalizador ""--shell-escape"") e que uma lista de permissões de comandos é utilizada para prevenir ataques de injeção de LaTeX.",2 +V1,Codificação e Sanitização,V1.2,Prevenção de Injeção,V1.2.9,Verificar que a aplicação escapa caracteres especiais em expressões regulares (tipicamente usando barra invertida) para evitar que sejam interpretados como metacaracteres.,2 +V1,Codificação e Sanitização,V1.2,Prevenção de Injeção,V1.2.10,"Verificar que a aplicação está protegida contra Injeção de CSV e Fórmulas. A aplicação deve seguir as regras de escape definidas nas seções 2.6 e 2.7 da RFC 4180 ao exportar conteúdo CSV. Adicionalmente, ao exportar para CSV ou outros formatos de planilha (como XLS, XLSX ou ODF), caracteres especiais (incluindo '=', '+', '-', '@', '\t' (tabulação) e '\0' (caractere nulo)) devem ser escapados com aspas simples se aparecerem como primeiro caractere em um campo.",3 +V1,Codificação e Sanitização,V1.3,Sanitização,V1.3.1,Verificar que toda entrada HTML não confiável proveniente de editores WYSIWYG ou similares é sanitizada usando uma biblioteca de sanitização HTML conhecida e segura ou recurso de framework.,1 +V1,Codificação e Sanitização,V1.3,Sanitização,V1.3.2,"Verificar que a aplicação evita o uso de eval() ou outros recursos de execução dinâmica de código, como Spring Expression Language (SpEL). Quando não houver alternativa, qualquer entrada do usuário incluída deve ser sanitizada antes de ser executada.",1 +V1,Codificação e Sanitização,V1.3,Sanitização,V1.3.3,"Verificar que os dados passados para um contexto potencialmente perigoso são sanitizados previamente para aplicar medidas de segurança, como permitir apenas caracteres seguros para esse contexto e truncar entradas excessivamente longas.",2 +V1,Codificação e Sanitização,V1.3,Sanitização,V1.3.4,"Verificar que o conteúdo scriptável de Scalable Vector Graphics (SVG) fornecido pelo usuário é validado ou sanitizado para conter apenas tags e atributos (como elementos gráficos) que sejam seguros para a aplicação — por exemplo, sem scripts ou foreignObject.",2 +V1,Codificação e Sanitização,V1.3,Sanitização,V1.3.5,"Verificar que a aplicação sanitiza ou desabilita conteúdo scriptável ou em linguagem de template de expressão fornecido pelo usuário, como Markdown, folhas de estilo CSS ou XSL, BBCode ou similares.",2 +V1,Codificação e Sanitização,V1.3,Sanitização,V1.3.6,"Verificar que a aplicação protege contra ataques de Server-side Request Forgery (SSRF), validando dados não confiáveis contra uma lista de permissões de protocolos, domínios, caminhos e portas, e sanitizando caracteres potencialmente perigosos antes de usar os dados para chamar outro serviço.",2 +V1,Codificação e Sanitização,V1.3,Sanitização,V1.3.7,"Verificar que a aplicação protege contra ataques de injeção de templates, não permitindo que templates sejam construídos com base em entradas não confiáveis. Quando não houver alternativa, qualquer entrada não confiável incluída dinamicamente durante a criação do template deve ser sanitizada ou estritamente validada.",2 +V1,Codificação e Sanitização,V1.3,Sanitização,V1.3.8,Verificar que a aplicação sanitiza adequadamente entradas não confiáveis antes de usá-las em consultas JNDI (Java Naming and Directory Interface) e que o JNDI está configurado de forma segura para prevenir ataques de injeção de JNDI.,2 +V1,Codificação e Sanitização,V1.3,Sanitização,V1.3.9,Verificar que a aplicação sanitiza o conteúdo antes de enviá-lo ao memcache para prevenir ataques de injeção.,2 +V1,Codificação e Sanitização,V1.3,Sanitização,V1.3.10,Verificar que strings de formato que possam ser resolvidas de maneira inesperada ou maliciosa são sanitizadas antes de serem processadas.,2 +V1,Codificação e Sanitização,V1.3,Sanitização,V1.3.11,"Verificar que a aplicação sanitiza a entrada do usuário antes de passá-la para sistemas de e-mail, para proteger contra injeção de SMTP ou IMAP.",2 +V1,Codificação e Sanitização,V1.3,Sanitização,V1.3.12,"Verificar que as expressões regulares estão livres de elementos que causem retrocesso exponencial, e garantir que a entrada não confiável seja sanitizada para mitigar ataques ReDoS ou de expressões regulares descontroladas.",3 +V1,Codificação e Sanitização,V1.4,"Memória, Strings e Código Não Gerenciado",V1.4.1,"Verificar que a aplicação usa strings seguras em termos de memória, cópia de memória mais segura e aritmética de ponteiros para detectar ou prevenir estouros de pilha, buffer ou heap.",2 +V1,Codificação e Sanitização,V1.4,"Memória, Strings e Código Não Gerenciado",V1.4.2,"Verificar que técnicas de validação de sinal, intervalo e entrada são usadas para prevenir estouros de inteiros.",2 +V1,Codificação e Sanitização,V1.4,"Memória, Strings e Código Não Gerenciado",V1.4.3,"Verificar que a memória e os recursos alocados dinamicamente são liberados, e que referências ou ponteiros para memória liberada são removidos ou definidos como nulo para prevenir ponteiros pendentes e vulnerabilidades de use-after-free.",2 +V1,Codificação e Sanitização,V1.5,Desserialização Segura,V1.5.1,"Verificar que a aplicação configura os parsers XML para usar uma configuração restritiva e que recursos inseguros, como a resolução de entidades externas, estão desabilitados para prevenir ataques de XML eXternal Entity (XXE).",1 +V1,Codificação e Sanitização,V1.5,Desserialização Segura,V1.5.2,"Verificar que a desserialização de dados não confiáveis aplica tratamento seguro de entrada, como o uso de uma lista de permissões de tipos de objetos ou a restrição de tipos de objetos definidos pelo cliente, para prevenir ataques de desserialização. Mecanismos de desserialização explicitamente definidos como inseguros não devem ser usados com entradas não confiáveis.",2 +V1,Codificação e Sanitização,V1.5,Desserialização Segura,V1.5.3,"Verificar que diferentes parsers usados na aplicação para o mesmo tipo de dado (por exemplo, parsers JSON, XML, URL) realizam o parsing de forma consistente e utilizam o mesmo mecanismo de codificação de caracteres, para evitar problemas como vulnerabilidades de interoperabilidade JSON ou comportamentos diferentes de parsing de URI ou arquivo que possam ser explorados em ataques de Remote File Inclusion (RFI) ou Server-side Request Forgery (SSRF).",3 +V2,Validação e Lógica de Negócio,V2.1,Documentação de Validação e Lógica de Negócio,V2.1.1,"Verificar que a documentação da aplicação define regras de validação de entrada sobre como verificar a validade de itens de dados em relação a uma estrutura esperada. Isso pode incluir formatos de dados comuns, como números de cartão de crédito, endereços de e-mail, números de telefone, ou formatos de dados internos.",1 +V2,Validação e Lógica de Negócio,V2.1,Documentação de Validação e Lógica de Negócio,V2.1.2,"Verificar que a documentação da aplicação define como validar a consistência lógica e contextual de itens de dados combinados, como verificar se o bairro e o CEP correspondem.",2 +V2,Validação e Lógica de Negócio,V2.1,Documentação de Validação e Lógica de Negócio,V2.1.3,"Verificar que as expectativas de limites e validações da lógica de negócio estão documentadas, incluindo tanto por usuário quanto globalmente na aplicação.",2 +V2,Validação e Lógica de Negócio,V2.2,Validação de Entrada,V2.2.1,"Verificar que a entrada é validada para aplicar as expectativas de negócio ou funcionais para essa entrada. Isso deve usar validação positiva com base em uma lista de permissões de valores, padrões e intervalos, ou basear-se na comparação da entrada com uma estrutura esperada e limites lógicos conforme regras predefinidas. Para L1, pode-se focar em entradas usadas para tomar decisões específicas de negócio ou segurança. Para L2 e acima, deve-se aplicar a todas as entradas.",1 +V2,Validação e Lógica de Negócio,V2.2,Validação de Entrada,V2.2.2,"Verificar que a aplicação está projetada para aplicar a validação de entrada em uma camada de serviço confiável. Embora a validação no lado do cliente melhore a usabilidade e deva ser incentivada, ela não deve ser usada como controle de segurança.",1 +V2,Validação e Lógica de Negócio,V2.2,Validação de Entrada,V2.2.3,Verificar que a aplicação garante que combinações de itens de dados relacionados são razoáveis de acordo com as regras predefinidas.,2 +V2,Validação e Lógica de Negócio,V2.3,Segurança da Lógica de Negócio,V2.3.1,"Verificar que a aplicação processa fluxos de lógica de negócio para o mesmo usuário somente na ordem sequencial esperada, sem pular etapas.",1 +V2,Validação e Lógica de Negócio,V2.3,Segurança da Lógica de Negócio,V2.3.2,"Verificar que os limites da lógica de negócio são implementados conforme a documentação da aplicação, para evitar que falhas de lógica de negócio sejam exploradas.",2 +V2,Validação e Lógica de Negócio,V2.3,Segurança da Lógica de Negócio,V2.3.3,"Verificar que transações são usadas no nível da lógica de negócio, de modo que uma operação de lógica de negócio seja bem-sucedida em sua totalidade ou seja revertida ao estado correto anterior.",2 +V2,Validação e Lógica de Negócio,V2.3,Segurança da Lógica de Negócio,V2.3.4,Verificar que mecanismos de bloqueio em nível de lógica de negócio são usados para garantir que recursos de quantidade limitada (como assentos em teatro ou slots de entrega) não possam ser reservados em duplicidade por meio da manipulação da lógica da aplicação.,2 +V2,Validação e Lógica de Negócio,V2.3,Segurança da Lógica de Negócio,V2.3.5,"Verificar que fluxos de lógica de negócio de alto valor exigem aprovação de múltiplos usuários para evitar ações não autorizadas ou acidentais. Isso pode incluir, mas não se limita a, grandes transferências monetárias, aprovações de contratos, acesso a informações classificadas ou substituições de segurança em manufatura.",3 +V2,Validação e Lógica de Negócio,V2.4,Anti-automação,V2.4.1,"Verificar que controles de anti-automação estão implementados para proteger contra chamadas excessivas a funções da aplicação que possam levar à exfiltração de dados, criação de dados inválidos, esgotamento de cotas, violações de limite de taxa, negação de serviço ou uso excessivo de recursos onerosos.",2 +V2,Validação e Lógica de Negócio,V2.4,Anti-automação,V2.4.2,"Verificar que os fluxos de lógica de negócio exigem temporização realista para um humano, prevenindo submissões de transações excessivamente rápidas.",3 +V3,Segurança de Frontend Web,V3.1,Documentação de Segurança de Frontend Web,V3.1.1,"Verificar que a documentação da aplicação declara os recursos de segurança esperados que os navegadores que usam a aplicação devem suportar (como HTTPS, HTTP Strict Transport Security (HSTS), Content Security Policy (CSP) e outros mecanismos relevantes de segurança HTTP). Também deve definir como a aplicação deve se comportar quando alguns desses recursos não estiverem disponíveis (como avisar o usuário ou bloquear o acesso).",3 +V3,Segurança de Frontend Web,V3.2,Interpretação Não Intencional de Conteúdo,V3.2.1,"Verificar que controles de segurança estão implementados para evitar que os navegadores renderizem conteúdo ou funcionalidade em respostas HTTP em um contexto incorreto (por exemplo, quando uma API, arquivo enviado pelo usuário ou outro recurso é solicitado diretamente). Os controles possíveis podem incluir: não servir o conteúdo a menos que campos de cabeçalho HTTP (como Sec-Fetch-*) indiquem que é o contexto correto, usar a diretiva sandbox do cabeçalho Content-Security-Policy ou usar o tipo de disposição de anexo no cabeçalho Content-Disposition.",1 +V3,Segurança de Frontend Web,V3.2,Interpretação Não Intencional de Conteúdo,V3.2.2,"Verificar que o conteúdo destinado a ser exibido como texto, em vez de renderizado como HTML, é tratado usando funções de renderização seguras (como createTextNode ou textContent) para prevenir a execução não intencional de conteúdo como HTML ou JavaScript.",1 +V3,Segurança de Frontend Web,V3.2,Interpretação Não Intencional de Conteúdo,V3.2.3,"Verificar que a aplicação evita o DOM clobbering ao usar JavaScript no lado do cliente, por meio de declarações explícitas de variáveis, verificação de tipo estrita, evitando armazenar variáveis globais no objeto document e implementando isolamento de namespace.",3 +V3,Segurança de Frontend Web,V3.3,Configuração de Cookies,V3.3.1,"Verificar que os cookies têm o atributo 'Secure' definido e que, se o prefixo '__Host-' não for usado para o nome do cookie, o prefixo '__Secure-' deve ser usado.",1 +V3,Segurança de Frontend Web,V3.3,Configuração de Cookies,V3.3.2,"Verificar que o valor do atributo 'SameSite' de cada cookie é definido de acordo com a finalidade do cookie, para limitar a exposição a ataques de redirecionamento de interface de usuário e ataques de falsificação de requisição baseados no navegador, comumente conhecidos como cross-site request forgery (CSRF).",2 +V3,Segurança de Frontend Web,V3.3,Configuração de Cookies,V3.3.3,"Verificar que os cookies possuem o prefixo '__Host-' para o nome do cookie, a menos que sejam explicitamente projetados para ser compartilhados com outros hosts.",2 +V3,Segurança de Frontend Web,V3.3,Configuração de Cookies,V3.3.4,"Verificar que, se o valor de um cookie não deve ser acessível a scripts no lado do cliente (como um token de sessão), o cookie deve ter o atributo 'HttpOnly' definido e o mesmo valor (por exemplo, token de sessão) deve ser transferido ao cliente apenas via campo de cabeçalho 'Set-Cookie'.",2 +V3,Segurança de Frontend Web,V3.3,Configuração de Cookies,V3.3.5,"Verificar que, ao gravar um cookie, o comprimento combinado do nome e valor do cookie não ultrapasse 4096 bytes. Cookies excessivamente grandes não serão armazenados pelo navegador e, portanto, não serão enviados com as requisições, impedindo o usuário de usar funcionalidades da aplicação que dependem desse cookie.",3 +V3,Segurança de Frontend Web,V3.4,Cabeçalhos de Mecanismos de Segurança do Navegador,V3.4.1,"Verificar que um campo de cabeçalho Strict-Transport-Security está incluído em todas as respostas para aplicar uma política de HTTP Strict Transport Security (HSTS). Uma idade máxima de pelo menos 1 ano deve ser definida e, para L2 e acima, a política deve se aplicar a todos os subdomínios.",1 +V3,Segurança de Frontend Web,V3.4,Cabeçalhos de Mecanismos de Segurança do Navegador,V3.4.2,"Verificar que o campo de cabeçalho Access-Control-Allow-Origin do Cross-Origin Resource Sharing (CORS) é um valor fixo definido pela aplicação ou, se o valor do campo de cabeçalho Origin da requisição HTTP for usado, ele é validado em relação a uma lista de permissões de origens confiáveis. Quando 'Access-Control-Allow-Origin: *' precisar ser usado, verificar que a resposta não inclui nenhuma informação sensível.",1 +V3,Segurança de Frontend Web,V3.4,Cabeçalhos de Mecanismos de Segurança do Navegador,V3.4.3,"Verificar que as respostas HTTP incluem um campo de cabeçalho de resposta Content-Security-Policy que define diretivas para garantir que o navegador carregue e execute apenas conteúdo ou recursos confiáveis, a fim de limitar a execução de JavaScript malicioso. No mínimo, uma política global deve ser usada incluindo as diretivas object-src 'none' e base-uri 'none', e deve definir uma lista de permissões ou usar nonces ou hashes. Para uma aplicação L3, uma política por resposta com nonces ou hashes deve ser definida.",2 +V3,Segurança de Frontend Web,V3.4,Cabeçalhos de Mecanismos de Segurança do Navegador,V3.4.4,"Verificar que todas as respostas HTTP contêm um campo de cabeçalho 'X-Content-Type-Options: nosniff'. Isso instrui os navegadores a não usar detecção de conteúdo e adivinhação de tipo MIME para a resposta, exigindo que o valor do campo de cabeçalho Content-Type da resposta corresponda ao recurso de destino. Por exemplo, a resposta a uma requisição de estilo só é aceita se o Content-Type da resposta for 'text/css'. Isso também habilita o uso da funcionalidade Cross-Origin Read Blocking (CORB) pelo navegador.",2 +V3,Segurança de Frontend Web,V3.4,Cabeçalhos de Mecanismos de Segurança do Navegador,V3.4.5,"Verificar que a aplicação define uma política de referrer para prevenir o vazamento de dados tecnicamente sensíveis para serviços de terceiros via campo de cabeçalho HTTP 'Referer'. Isso pode ser feito usando o campo de cabeçalho HTTP de resposta Referrer-Policy ou por meio de atributos de elementos HTML. Dados sensíveis podem incluir dados de caminho e consulta na URL e, para aplicações internas não públicas, também o hostname.",2 +V3,Segurança de Frontend Web,V3.4,Cabeçalhos de Mecanismos de Segurança do Navegador,V3.4.6,"Verificar que a aplicação web usa a diretiva frame-ancestors do cabeçalho Content-Security-Policy em todas as respostas HTTP para garantir que ela não possa ser incorporada por padrão, e que a incorporação de recursos específicos seja permitida apenas quando necessário. Observar que o campo de cabeçalho X-Frame-Options, embora suportado por navegadores, está obsoleto e não deve ser utilizado como referência.",2 +V3,Segurança de Frontend Web,V3.4,Cabeçalhos de Mecanismos de Segurança do Navegador,V3.4.7,Verificar que o campo de cabeçalho Content-Security-Policy especifica um local para reportar violações.,3 +V3,Segurança de Frontend Web,V3.4,Cabeçalhos de Mecanismos de Segurança do Navegador,V3.4.8,"Verificar que todas as respostas HTTP que iniciam a renderização de um documento (como respostas com Content-Type text/html) incluem o campo de cabeçalho Cross-Origin-Opener-Policy com a diretiva same-origin ou a diretiva same-origin-allow-popups conforme necessário. Isso previne ataques que abusam do acesso compartilhado a objetos Window, como tabnabbing e contagem de frames.",3 +V3,Segurança de Frontend Web,V3.5,Separação de Origem do Navegador,V3.5.1,"Verificar que, se a aplicação não depende do mecanismo de preflight de CORS para prevenir requisições cross-origin não permitidas que usem funcionalidades sensíveis, essas requisições são validadas para garantir que se originam da própria aplicação. Isso pode ser feito usando e validando tokens anti-falsificação ou exigindo campos de cabeçalho HTTP extras que não sejam campos de cabeçalho de requisição seguros pelo CORS. Isso serve para defender contra ataques de falsificação de requisição baseados no navegador, comumente conhecidos como cross-site request forgery (CSRF).",1 +V3,Segurança de Frontend Web,V3.5,Separação de Origem do Navegador,V3.5.2,"Verificar que, se a aplicação depende do mecanismo de preflight de CORS para prevenir o uso cross-origin não permitido de funcionalidades sensíveis, não é possível chamar essa funcionalidade com uma requisição que não acione uma requisição de preflight CORS. Isso pode exigir a verificação dos valores dos campos de cabeçalho de requisição 'Origin' e 'Content-Type' ou o uso de um campo de cabeçalho extra que não seja um cabeçalho seguro pelo CORS.",1 +V3,Segurança de Frontend Web,V3.5,Separação de Origem do Navegador,V3.5.3,"Verificar que as requisições HTTP para funcionalidades sensíveis usam métodos HTTP adequados como POST, PUT, PATCH ou DELETE, e não métodos definidos pela especificação HTTP como 'seguros', como HEAD, OPTIONS ou GET. Alternativamente, a validação estrita dos campos de cabeçalho de requisição Sec-Fetch-* pode ser usada para garantir que a requisição não originou de uma chamada cross-origin inadequada, de uma requisição de navegação ou de um carregamento de recurso (como origem de imagem) onde isso não é esperado.",1 +V3,Segurança de Frontend Web,V3.5,Separação de Origem do Navegador,V3.5.4,"Verificar que aplicações separadas são hospedadas em hostnames diferentes para aproveitar as restrições fornecidas pela política de mesma origem, incluindo como documentos ou scripts carregados por uma origem podem interagir com recursos de outra origem, e restrições baseadas em hostname em cookies.",2 +V3,Segurança de Frontend Web,V3.5,Separação de Origem do Navegador,V3.5.5,Verificar que mensagens recebidas pela interface postMessage são descartadas se a origem da mensagem não for confiável ou se a sintaxe da mensagem for inválida.,2 +V3,Segurança de Frontend Web,V3.5,Separação de Origem do Navegador,V3.5.6,Verificar que a funcionalidade JSONP não está habilitada em nenhum lugar da aplicação para evitar ataques de Cross-Site Script Inclusion (XSSI).,3 +V3,Segurança de Frontend Web,V3.5,Separação de Origem do Navegador,V3.5.7,"Verificar que dados que requerem autorização não estão incluídos em respostas de recursos script, como arquivos JavaScript, para prevenir ataques de Cross-Site Script Inclusion (XSSI).",3 +V3,Segurança de Frontend Web,V3.5,Separação de Origem do Navegador,V3.5.8,"Verificar que recursos autenticados (como imagens, vídeos, scripts e outros documentos) só podem ser carregados ou incorporados em nome do usuário quando pretendido. Isso pode ser feito por validação estrita dos campos de cabeçalho HTTP Sec-Fetch-* para garantir que a requisição não originou de uma chamada cross-origin inadequada, ou definindo um campo de cabeçalho HTTP de resposta Cross-Origin-Resource-Policy restritivo para instruir o navegador a bloquear o conteúdo retornado.",3 +V3,Segurança de Frontend Web,V3.6,Integridade de Recursos Externos,V3.6.1,"Verificar que ativos no lado do cliente, como bibliotecas JavaScript, CSS ou fontes web, só são hospedados externamente (por exemplo, em uma Rede de Distribuição de Conteúdo) se o recurso for estático e versionado e se a Subresource Integrity (SRI) for usada para validar a integridade do ativo. Se isso não for possível, deve haver uma decisão de segurança documentada para justificar isso para cada recurso.",3 +V3,Segurança de Frontend Web,V3.7,Outras Considerações de Segurança do Navegador,V3.7.1,"Verificar que a aplicação usa apenas tecnologias do lado do cliente que ainda são suportadas e consideradas seguras. Exemplos de tecnologias que não atendem a esse requisito incluem plugins NSAPI, Flash, Shockwave, ActiveX, Silverlight, NACL ou applets Java no lado do cliente.",2 +V3,Segurança de Frontend Web,V3.7,Outras Considerações de Segurança do Navegador,V3.7.2,Verificar que a aplicação só redireciona automaticamente o usuário para um hostname ou domínio diferente (que não é controlado pela aplicação) quando o destino consta em uma lista de permissões.,2 +V3,Segurança de Frontend Web,V3.7,Outras Considerações de Segurança do Navegador,V3.7.3,"Verificar que a aplicação exibe uma notificação quando o usuário está sendo redirecionado para uma URL fora do controle da aplicação, com opção de cancelar a navegação.",3 +V3,Segurança de Frontend Web,V3.7,Outras Considerações de Segurança do Navegador,V3.7.4,"Verificar que o domínio de nível superior da aplicação (por exemplo, site.tld) foi adicionado à lista de pré-carregamento público de HTTP Strict Transport Security (HSTS). Isso garante que o uso de TLS para a aplicação seja incorporado diretamente nos principais navegadores, em vez de depender apenas do campo de cabeçalho de resposta Strict-Transport-Security.",3 +V3,Segurança de Frontend Web,V3.7,Outras Considerações de Segurança do Navegador,V3.7.5,Verificar que a aplicação se comporta conforme documentado (como avisar o usuário ou bloquear o acesso) se o navegador usado para acessar a aplicação não suportar os recursos de segurança esperados.,3 +V4,API e Serviço Web,V4.1,Segurança Genérica de Serviços Web,V4.1.1,"Verificar que toda resposta HTTP com corpo de mensagem contém um campo de cabeçalho Content-Type que corresponde ao conteúdo real da resposta, incluindo o parâmetro charset para especificar a codificação de caracteres segura (por exemplo, UTF-8, ISO-8859-1) conforme os tipos de mídia IANA, como ""text/"", ""/+xml"" e ""/xml"".",1 +V4,API e Serviço Web,V4.1,Segurança Genérica de Serviços Web,V4.1.2,"Verificar que apenas endpoints voltados ao usuário (destinados ao acesso manual via navegador web) redirecionam automaticamente de HTTP para HTTPS, enquanto outros serviços ou endpoints não implementam redirecionamentos transparentes. Isso evita uma situação em que um cliente envia erroneamente requisições HTTP não criptografadas, mas como as requisições são automaticamente redirecionadas para HTTPS, o vazamento de dados sensíveis passa despercebido.",2 +V4,API e Serviço Web,V4.1,Segurança Genérica de Serviços Web,V4.1.3,"Verificar que qualquer campo de cabeçalho HTTP usado pela aplicação e definido por uma camada intermediária, como um balanceador de carga, proxy web ou serviço backend-for-frontend, não pode ser sobrescrito pelo usuário final. Exemplos de cabeçalhos podem incluir X-Real-IP, X-Forwarded-* ou X-User-ID.",2 +V4,API e Serviço Web,V4.1,Segurança Genérica de Serviços Web,V4.1.4,Verificar que apenas os métodos HTTP explicitamente suportados pela aplicação ou sua API (incluindo OPTIONS durante requisições preflight) podem ser usados e que métodos não utilizados estão bloqueados.,3 +V4,API e Serviço Web,V4.1,Segurança Genérica de Serviços Web,V4.1.5,Verificar que assinaturas digitais por mensagem são usadas para fornecer garantia adicional além das proteções de transporte para requisições ou transações altamente sensíveis ou que atravessam vários sistemas.,3 +V4,API e Serviço Web,V4.2,Validação da Estrutura de Mensagens HTTP,V4.2.1,"Verificar que todos os componentes da aplicação (incluindo balanceadores de carga, firewalls e servidores de aplicação) determinam os limites de mensagens HTTP recebidas usando o mecanismo adequado para a versão HTTP, a fim de prevenir HTTP request smuggling. Em HTTP/1.x, se um campo de cabeçalho Transfer-Encoding estiver presente, o Content-Length deve ser ignorado conforme a RFC 2616. Ao usar HTTP/2 ou HTTP/3, se um campo de cabeçalho Content-Length estiver presente, o receptor deve garantir que seja consistente com o comprimento dos frames DATA.",2 +V4,API e Serviço Web,V4.2,Validação da Estrutura de Mensagens HTTP,V4.2.2,"Verificar que, ao gerar mensagens HTTP, o campo de cabeçalho Content-Length não conflita com o comprimento do conteúdo determinado pelo enquadramento do protocolo HTTP, a fim de prevenir ataques de request smuggling.",3 +V4,API e Serviço Web,V4.2,Validação da Estrutura de Mensagens HTTP,V4.2.3,"Verificar que a aplicação não envia nem aceita mensagens HTTP/2 ou HTTP/3 com campos de cabeçalho específicos de conexão, como Transfer-Encoding, para prevenir ataques de divisão de resposta e injeção de cabeçalho.",3 +V4,API e Serviço Web,V4.2,Validação da Estrutura de Mensagens HTTP,V4.2.4,"Verificar que a aplicação aceita apenas requisições HTTP/2 e HTTP/3 onde os campos de cabeçalho e valores não contêm sequências CR (\r), LF (\n) ou CRLF (\r\n), para prevenir ataques de injeção de cabeçalho.",3 +V4,API e Serviço Web,V4.2,Validação da Estrutura de Mensagens HTTP,V4.2.5,"Verificar que, se a aplicação (backend ou frontend) constrói e envia requisições, ela usa validação, sanitização ou outros mecanismos para evitar a criação de URIs (como para chamadas de API) ou campos de cabeçalho HTTP (como Authorization ou Cookie) que sejam longos demais para serem aceitos pelo componente receptor. Isso poderia causar negação de serviço, como ao enviar uma requisição excessivamente longa (por exemplo, um campo de cabeçalho de cookie longo), que resulta no servidor sempre respondendo com um status de erro.",3 +V4,API e Serviço Web,V4.3,GraphQL,V4.3.1,"Verificar que uma lista de permissões de consultas, limitação de profundidade, limitação de quantidade ou análise de custo de consulta é usada para prevenir Negação de Serviço (DoS) em GraphQL ou em camadas de expressão de dados como resultado de consultas aninhadas caras.",2 +V4,API e Serviço Web,V4.3,GraphQL,V4.3.2,"Verificar que as consultas de introspecção do GraphQL estão desabilitadas no ambiente de produção, a menos que a API GraphQL seja destinada ao uso por outras partes.",2 +V4,API e Serviço Web,V4.4,WebSocket,V4.4.1,Verificar que WebSocket sobre TLS (WSS) é usado para todas as conexões WebSocket.,1 +V4,API e Serviço Web,V4.4,WebSocket,V4.4.2,"Verificar que, durante o handshake HTTP inicial do WebSocket, o campo de cabeçalho Origin é verificado em relação a uma lista de origens permitidas para a aplicação.",2 +V4,API e Serviço Web,V4.4,WebSocket,V4.4.3,"Verificar que, se o gerenciamento de sessão padrão da aplicação não puder ser usado, tokens dedicados estejam sendo usados para isso, em conformidade com os requisitos de segurança de Gerenciamento de Sessão relevantes.",2 +V4,API e Serviço Web,V4.4,WebSocket,V4.4.4,Verificar que tokens dedicados de gerenciamento de sessão WebSocket são inicialmente obtidos ou validados por meio da sessão HTTPS previamente autenticada ao fazer a transição de uma sessão HTTPS existente para um canal WebSocket.,2 +V5,Manipulação de Arquivos,V5.1,Documentação de Manipulação de Arquivos,V5.1.1,"Verificar que a documentação define os tipos de arquivos permitidos, extensões de arquivo esperadas e tamanho máximo (incluindo o tamanho descompactado) para cada funcionalidade de upload. Além disso, garantir que a documentação especifique como os arquivos são tornados seguros para download e processamento pelos usuários finais, como o comportamento da aplicação quando um arquivo malicioso é detectado.",2 +V5,Manipulação de Arquivos,V5.2,Upload de Arquivos e Conteúdo,V5.2.1,Verificar que a aplicação aceitará apenas arquivos de tamanho que ela possa processar sem causar perda de desempenho ou um ataque de negação de serviço.,1 +V5,Manipulação de Arquivos,V5.2,Upload de Arquivos e Conteúdo,V5.2.2,"Verificar que, ao aceitar um arquivo, seja isoladamente ou dentro de um arquivo comprimido como um zip, a aplicação verifica se a extensão do arquivo corresponde a uma extensão esperada e valida que o conteúdo corresponde ao tipo representado pela extensão. Isso inclui, mas não se limita a, verificar os 'bytes mágicos' iniciais, realizar reescrita de imagens e usar bibliotecas especializadas para validação de conteúdo de arquivo. Para L1, isso pode focar apenas em arquivos usados para tomar decisões específicas de negócio ou segurança. Para L2 e acima, deve ser aplicado a todos os arquivos recebidos.",1 +V5,Manipulação de Arquivos,V5.2,Upload de Arquivos e Conteúdo,V5.2.3,"Verificar que a aplicação verifica arquivos comprimidos (por exemplo, zip, gz, docx, odt) em relação ao tamanho máximo permitido descompactado e ao número máximo de arquivos antes de descompactar o arquivo.",2 +V5,Manipulação de Arquivos,V5.2,Upload de Arquivos e Conteúdo,V5.2.4,Verificar que uma cota de tamanho de arquivo e número máximo de arquivos por usuário são aplicados para garantir que um único usuário não possa preencher o armazenamento com muitos arquivos ou arquivos excessivamente grandes.,3 +V5,Manipulação de Arquivos,V5.2,Upload de Arquivos e Conteúdo,V5.2.5,"Verificar que a aplicação não permite o upload de arquivos comprimidos contendo links simbólicos, a menos que isso seja especificamente necessário (caso em que será necessário aplicar uma lista de permissões dos arquivos para os quais links simbólicos podem apontar).",3 +V5,Manipulação de Arquivos,V5.2,Upload de Arquivos e Conteúdo,V5.2.6,"Verificar que a aplicação rejeita imagens enviadas com tamanho em pixels maior que o máximo permitido, para prevenir ataques de pixel flood.",3 +V5,Manipulação de Arquivos,V5.3,Armazenamento de Arquivos,V5.3.1,Verificar que arquivos enviados por usuários ou gerados a partir de entradas não confiáveis e armazenados em uma pasta pública não são executados como código de programa no lado do servidor quando acessados diretamente por uma requisição HTTP.,1 +V5,Manipulação de Arquivos,V5.3,Armazenamento de Arquivos,V5.3.2,"Verificar que, ao criar caminhos de arquivo para operações com arquivos, a aplicação usa dados gerados internamente ou confiáveis, em vez de nomes de arquivos enviados pelo usuário, ou, se nomes de arquivos ou metadados enviados pelo usuário precisarem ser usados, validação e sanitização estritas devem ser aplicadas. Isso serve para proteger contra ataques de path traversal, inclusão de arquivo local ou remoto (LFI, RFI) e Server-side Request Forgery (SSRF).",1 +V5,Manipulação de Arquivos,V5.3,Armazenamento de Arquivos,V5.3.3,"Verificar que o processamento de arquivo no lado do servidor, como descompressão de arquivos, ignora as informações de caminho fornecidas pelo usuário para prevenir vulnerabilidades como zip slip.",3 +V5,Manipulação de Arquivos,V5.4,Download de Arquivos,V5.4.1,"Verificar que a aplicação valida ou ignora nomes de arquivos enviados pelo usuário, incluindo em parâmetros JSON, JSONP ou URL, e especifica um nome de arquivo no campo de cabeçalho Content-Disposition na resposta.",2 +V5,Manipulação de Arquivos,V5.4,Download de Arquivos,V5.4.2,"Verificar que os nomes de arquivos servidos (por exemplo, em campos de cabeçalho de resposta HTTP ou anexos de e-mail) são codificados ou sanitizados (por exemplo, seguindo a RFC 6266) para preservar a estrutura do documento e prevenir ataques de injeção.",2 +V5,Manipulação de Arquivos,V5.4,Download de Arquivos,V5.4.3,Verificar que arquivos obtidos de fontes não confiáveis são verificados por scanners antivírus para prevenir o fornecimento de conteúdo malicioso conhecido.,2 +V6,Autenticação,V6.1,Documentação de Autenticação,V6.1.1,"Verificar que a documentação da aplicação define como controles como limitação de taxa, anti-automação e resposta adaptativa são usados para se defender contra ataques como credential stuffing e força bruta de senha. A documentação deve deixar claro como esses controles são configurados e previnem o bloqueio malicioso de contas.",1 +V6,Autenticação,V6.1,Documentação de Autenticação,V6.1.2,"Verificar que uma lista de palavras específicas ao contexto está documentada para evitar seu uso em senhas. A lista pode incluir permutações de nomes de organização, nomes de produtos, identificadores de sistema, codinomes de projetos, nomes de departamentos ou cargos e similares.",2 +V6,Autenticação,V6.1,Documentação de Autenticação,V6.1.3,"Verificar que, se a aplicação inclui múltiplos caminhos de autenticação, todos estão documentados junto com os controles de segurança e a força de autenticação que deve ser aplicada de forma consistente em todos eles.",2 +V6,Autenticação,V6.2,Segurança de Senhas,V6.2.1,"Verificar que as senhas definidas pelos usuários têm pelo menos 8 caracteres, embora um mínimo de 15 caracteres seja fortemente recomendado.",1 +V6,Autenticação,V6.2,Segurança de Senhas,V6.2.2,Verificar que os usuários podem alterar sua senha.,1 +V6,Autenticação,V6.2,Segurança de Senhas,V6.2.3,Verificar que a funcionalidade de alteração de senha exige a senha atual e a nova senha do usuário.,1 +V6,Autenticação,V6.2,Segurança de Senhas,V6.2.4,"Verificar que as senhas enviadas durante o registro de conta ou alteração de senha são verificadas em relação a um conjunto disponível de, no mínimo, as 3.000 senhas mais comuns que correspondem à política de senha da aplicação — por exemplo, comprimento mínimo.",1 +V6,Autenticação,V6.2,Segurança de Senhas,V6.2.5,"Verificar que senhas de qualquer composição podem ser usadas, sem regras que limitem o tipo de caracteres permitidos. Não deve haver requisito de número mínimo de caracteres maiúsculos ou minúsculos, números ou caracteres especiais.",1 +V6,Autenticação,V6.2,Segurança de Senhas,V6.2.6,Verificar que os campos de entrada de senha usam type=password para mascarar a digitação. As aplicações podem permitir que o usuário visualize temporariamente toda a senha mascarada ou o último caractere digitado da senha.,1 +V6,Autenticação,V6.2,Segurança de Senhas,V6.2.7,"Verificar que a funcionalidade de 'colar', assistentes de senha do navegador e gerenciadores de senha externos são permitidos.",1 +V6,Autenticação,V6.2,Segurança de Senhas,V6.2.8,"Verificar que a aplicação verifica a senha do usuário exatamente como recebida, sem modificações como truncamento ou transformação de maiúsculas/minúsculas.",1 +V6,Autenticação,V6.2,Segurança de Senhas,V6.2.9,Verificar que senhas de pelo menos 64 caracteres são permitidas.,2 +V6,Autenticação,V6.2,Segurança de Senhas,V6.2.10,Verificar que a senha de um usuário permanece válida até que seja descoberta como comprometida ou o usuário a altere. A aplicação não deve exigir rotação periódica de credenciais.,2 +V6,Autenticação,V6.2,Segurança de Senhas,V6.2.11,Verificar que a lista documentada de palavras específicas ao contexto é usada para evitar a criação de senhas fáceis de adivinhar.,2 +V6,Autenticação,V6.2,Segurança de Senhas,V6.2.12,Verificar que as senhas enviadas durante o registro de conta ou alterações de senha são verificadas em relação a um conjunto de senhas comprometidas.,2 +V6,Autenticação,V6.3,Segurança Geral de Autenticação,V6.3.1,Verificar que controles para prevenir ataques como credential stuffing e força bruta de senha são implementados conforme a documentação de segurança da aplicação.,1 +V6,Autenticação,V6.3,Segurança Geral de Autenticação,V6.3.2,"Verificar que contas de usuário padrão (por exemplo, 'root', 'admin' ou 'sa') não estão presentes na aplicação ou estão desabilitadas.",1 +V6,Autenticação,V6.3,Segurança Geral de Autenticação,V6.3.3,"Verificar que um mecanismo de autenticação multifator ou uma combinação de mecanismos de autenticação de fator único deve ser usada para acessar a aplicação. Para L3, um dos fatores deve ser um mecanismo de autenticação baseado em hardware que forneça resistência a comprometimento e impersonificação contra ataques de phishing, verificando a intenção de autenticar ao exigir uma ação iniciada pelo usuário (como o pressionamento de um botão em uma chave de hardware FIDO ou um telefone celular). Flexibilizar qualquer uma das considerações deste requisito exige uma justificativa totalmente documentada e um conjunto abrangente de controles mitigadores.",2 +V6,Autenticação,V6.3,Segurança Geral de Autenticação,V6.3.4,"Verificar que, se a aplicação inclui múltiplos caminhos de autenticação, não há caminhos não documentados e que os controles de segurança e a força de autenticação são aplicados de forma consistente.",2 +V6,Autenticação,V6.3,Segurança Geral de Autenticação,V6.3.5,"Verificar que os usuários são notificados sobre tentativas de autenticação suspeitas (bem-sucedidas ou não). Isso pode incluir tentativas de autenticação de um local ou cliente incomum, autenticação parcialmente bem-sucedida (apenas um de múltiplos fatores), uma tentativa de autenticação após um longo período de inatividade ou uma autenticação bem-sucedida após várias tentativas fracassadas.",3 +V6,Autenticação,V6.3,Segurança Geral de Autenticação,V6.3.6,Verificar que o e-mail não é usado como mecanismo de autenticação de fator único ou multifator.,3 +V6,Autenticação,V6.3,Segurança Geral de Autenticação,V6.3.7,"Verificar que os usuários são notificados após atualizações nos detalhes de autenticação, como resets de credenciais ou modificação do nome de usuário ou endereço de e-mail.",3 +V6,Autenticação,V6.3,Segurança Geral de Autenticação,V6.3.8,"Verificar que usuários válidos não possam ser deduzidos a partir de desafios de autenticação falhos, como com base em mensagens de erro, códigos de resposta HTTP ou tempos de resposta diferentes. A funcionalidade de registro e recuperação de senha também deve ter essa proteção.",3 +V6,Autenticação,V6.4,Ciclo de Vida e Recuperação de Fatores de Autenticação,V6.4.1,"Verificar que senhas iniciais ou códigos de ativação gerados pelo sistema são gerados de forma aleatória e segura, seguem a política de senha existente e expiram após um curto período de tempo ou após o uso inicial. Esses segredos iniciais não devem ser permitidos a se tornarem a senha de longo prazo.",1 +V6,Autenticação,V6.4,Ciclo de Vida e Recuperação de Fatores de Autenticação,V6.4.2,Verificar que dicas de senha ou autenticação baseada em conhecimento (as chamadas 'perguntas secretas') não estão presentes.,1 +V6,Autenticação,V6.4,Ciclo de Vida e Recuperação de Fatores de Autenticação,V6.4.3,"Verificar que um processo seguro para redefinição de senha esquecida está implementado, que não ignora nenhum mecanismo de autenticação multifator habilitado.",2 +V6,Autenticação,V6.4,Ciclo de Vida e Recuperação de Fatores de Autenticação,V6.4.4,"Verificar que, se um fator de autenticação multifator for perdido, a comprovação de identidade é realizada no mesmo nível que durante o cadastro.",2 +V6,Autenticação,V6.4,Ciclo de Vida e Recuperação de Fatores de Autenticação,V6.4.5,"Verificar que as instruções de renovação para mecanismos de autenticação que expiram são enviadas com tempo suficiente para serem executadas antes que o mecanismo de autenticação antigo expire, configurando lembretes automatizados se necessário.",3 +V6,Autenticação,V6.4,Ciclo de Vida e Recuperação de Fatores de Autenticação,V6.4.6,"Verificar que os usuários administrativos podem iniciar o processo de redefinição de senha para o usuário, mas que isso não lhes permite alterar ou escolher a senha do usuário. Isso previne uma situação em que eles conhecem a senha do usuário.",3 +V6,Autenticação,V6.5,Requisitos Gerais de Autenticação Multifator,V6.5.1,"Verificar que segredos de consulta, requisições ou códigos de autenticação fora de banda e senhas de uso único baseadas em tempo (TOTPs) são usáveis com sucesso apenas uma vez.",2 +V6,Autenticação,V6.5,Requisitos Gerais de Autenticação Multifator,V6.5.2,"Verificar que, ao serem armazenados no backend da aplicação, segredos de consulta com menos de 112 bits de entropia (19 caracteres alfanuméricos aleatórios ou 34 dígitos aleatórios) são hasheados com um algoritmo de hash de armazenamento de senhas aprovado que incorpora um salt aleatório de 32 bits. Uma função de hash padrão pode ser usada se o segredo tiver 112 bits de entropia ou mais.",2 +V6,Autenticação,V6.5,Requisitos Gerais de Autenticação Multifator,V6.5.3,"Verificar que segredos de consulta, códigos de autenticação fora de banda e seeds de senha de uso único baseada em tempo são gerados usando um Gerador de Números Pseudoaleatórios Criptograficamente Seguro (CSPRNG) para evitar valores previsíveis.",2 +V6,Autenticação,V6.5,Requisitos Gerais de Autenticação Multifator,V6.5.4,Verificar que segredos de consulta e códigos de autenticação fora de banda têm um mínimo de 20 bits de entropia (tipicamente 4 caracteres alfanuméricos aleatórios ou 6 dígitos aleatórios são suficientes).,2 +V6,Autenticação,V6.5,Requisitos Gerais de Autenticação Multifator,V6.5.5,"Verificar que requisições, códigos ou tokens de autenticação fora de banda, bem como senhas de uso único baseadas em tempo (TOTPs), têm um tempo de vida definido. Requisições fora de banda devem ter um tempo de vida máximo de 10 minutos e, para TOTP, um tempo de vida máximo de 30 segundos.",2 +V6,Autenticação,V6.5,Requisitos Gerais de Autenticação Multifator,V6.5.6,Verificar que qualquer fator de autenticação (incluindo dispositivos físicos) pode ser revogado em caso de roubo ou outra perda.,3 +V6,Autenticação,V6.5,Requisitos Gerais de Autenticação Multifator,V6.5.7,Verificar que os mecanismos de autenticação biométrica são usados apenas como fatores secundários em conjunto com algo que você possui ou algo que você sabe.,3 +V6,Autenticação,V6.5,Requisitos Gerais de Autenticação Multifator,V6.5.8,Verificar que as senhas de uso único baseadas em tempo (TOTPs) são verificadas com base em uma fonte de tempo de um serviço confiável e não de um tempo não confiável ou fornecido pelo cliente.,3 +V6,Autenticação,V6.6,Mecanismos de Autenticação Fora de Banda,V6.6.1,"Verificar que os mecanismos de autenticação que usam a Rede Telefônica Pública Comutada (PSTN) para entregar Senhas de Uso Único (OTPs) via telefone ou SMS são oferecidos apenas quando o número de telefone foi previamente validado, métodos alternativos mais fortes (como Senhas de Uso Único Baseadas em Tempo) também são oferecidos, e o serviço fornece informações sobre seus riscos de segurança aos usuários. Para aplicações L3, telefone e SMS não devem estar disponíveis como opções.",2 +V6,Autenticação,V6.6,Mecanismos de Autenticação Fora de Banda,V6.6.2,"Verificar que requisições, códigos ou tokens de autenticação fora de banda estão vinculados à requisição de autenticação original para a qual foram gerados e não são utilizáveis para uma anterior ou subsequente.",2 +V6,Autenticação,V6.6,Mecanismos de Autenticação Fora de Banda,V6.6.3,Verificar que um mecanismo de autenticação fora de banda baseado em código é protegido contra ataques de força bruta por meio de limitação de taxa. Considere também usar um código com pelo menos 64 bits de entropia.,2 +V6,Autenticação,V6.6,Mecanismos de Autenticação Fora de Banda,V6.6.4,"Verificar que, onde notificações push são usadas para autenticação multifator, a limitação de taxa é usada para prevenir ataques de push bombing. O casamento de números também pode mitigar esse risco.",3 +V6,Autenticação,V6.7,Mecanismo de Autenticação Criptográfica,V6.7.1,Verificar que os certificados usados para verificar asserções de autenticação criptográfica são armazenados de uma forma que os protege de modificação.,3 +V6,Autenticação,V6.7,Mecanismo de Autenticação Criptográfica,V6.7.2,Verificar que o nonce de desafio tem pelo menos 64 bits de comprimento e é estatisticamente único ou único ao longo da vida útil do dispositivo criptográfico.,3 +V6,Autenticação,V6.8,Autenticação com Provedor de Identidade,V6.8.1,"Verificar que, se a aplicação suporta múltiplos provedores de identidade (IdPs), a identidade do usuário não pode ser falsificada por outro provedor de identidade suportado (por exemplo, usando o mesmo identificador de usuário). A mitigação padrão seria a aplicação registrar e identificar o usuário usando uma combinação do ID do IdP (servindo como namespace) e o ID do usuário no IdP.",2 +V6,Autenticação,V6.8,Autenticação com Provedor de Identidade,V6.8.2,"Verificar que a presença e a integridade de assinaturas digitais em asserções de autenticação (por exemplo, em JWTs ou asserções SAML) são sempre validadas, rejeitando quaisquer asserções não assinadas ou com assinaturas inválidas.",2 +V6,Autenticação,V6.8,Autenticação com Provedor de Identidade,V6.8.3,Verificar que as asserções SAML são processadas de forma única e usadas apenas uma vez dentro do período de validade para prevenir ataques de replay.,2 +V6,Autenticação,V6.8,Autenticação com Provedor de Identidade,V6.8.4,"Verificar que, se uma aplicação usa um Provedor de Identidade (IdP) separado e espera força de autenticação, métodos ou recenticidade específicos para funções específicas, a aplicação verifica isso usando as informações retornadas pelo IdP. Por exemplo, se OIDC é usado, isso pode ser alcançado validando claims do Token ID como 'acr', 'amr' e 'auth_time' (se presentes). Se o IdP não fornecer essas informações, a aplicação deve ter uma abordagem de fallback documentada que assume que o mecanismo de autenticação de força mínima foi usado (por exemplo, autenticação de fator único usando nome de usuário e senha).",2 +V7,Gerenciamento de Sessão,V7.1,Documentação de Gerenciamento de Sessão,V7.1.1,"Verificar que o tempo limite de inatividade da sessão do usuário e o tempo de vida máximo absoluto da sessão estão documentados, são apropriados em combinação com outros controles, e que a documentação inclui justificativa para quaisquer desvios dos requisitos de reautenticação da NIST SP 800-63B.",2 +V7,Gerenciamento de Sessão,V7.1,Documentação de Gerenciamento de Sessão,V7.1.2,"Verificar que a documentação define quantas sessões concorrentes (paralelas) são permitidas para uma conta, bem como os comportamentos e ações pretendidos quando o número máximo de sessões ativas for atingido.",2 +V7,Gerenciamento de Sessão,V7.1,Documentação de Gerenciamento de Sessão,V7.1.3,"Verificar que todos os sistemas que criam e gerenciam sessões de usuário como parte de um ecossistema de gerenciamento de identidade federada (como sistemas SSO) estão documentados junto com controles para coordenar o tempo de vida das sessões, encerramento e quaisquer outras condições que exijam reautenticação.",2 +V7,Gerenciamento de Sessão,V7.2,Segurança Fundamental do Gerenciamento de Sessão,V7.2.1,Verificar que a aplicação realiza toda a verificação de tokens de sessão usando um serviço de backend confiável.,1 +V7,Gerenciamento de Sessão,V7.2,Segurança Fundamental do Gerenciamento de Sessão,V7.2.2,"Verificar que a aplicação usa tokens autocontidos ou de referência gerados dinamicamente para gerenciamento de sessão — ou seja, não usa segredos e chaves de API estáticas.",1 +V7,Gerenciamento de Sessão,V7.2,Segurança Fundamental do Gerenciamento de Sessão,V7.2.3,"Verificar que, se tokens de referência são usados para representar sessões de usuário, eles são únicos e gerados usando um gerador de números pseudoaleatórios criptograficamente seguro (CSPRNG) e possuem pelo menos 128 bits de entropia.",1 +V7,Gerenciamento de Sessão,V7.2,Segurança Fundamental do Gerenciamento de Sessão,V7.2.4,"Verificar que a aplicação gera um novo token de sessão na autenticação do usuário, incluindo reautenticação, e encerra o token de sessão atual.",1 +V7,Gerenciamento de Sessão,V7.3,Tempo Limite de Sessão,V7.3.1,Verificar que há um tempo limite de inatividade que impõe a reautenticação conforme análise de risco e decisões de segurança documentadas.,2 +V7,Gerenciamento de Sessão,V7.3,Tempo Limite de Sessão,V7.3.2,Verificar que há um tempo de vida máximo absoluto de sessão que impõe a reautenticação conforme análise de risco e decisões de segurança documentadas.,2 +V7,Gerenciamento de Sessão,V7.4,Encerramento de Sessão,V7.4.1,"Verificar que, quando o encerramento da sessão é acionado (como logout ou expiração), a aplicação não permite mais nenhum uso da sessão. Para tokens de referência ou sessões stateful, isso significa invalidar os dados da sessão no backend da aplicação. Aplicações que usam tokens autocontidos precisarão de uma solução como manter uma lista de tokens encerrados, não permitir tokens produzidos antes de uma data e hora por usuário ou rotacionar uma chave de assinatura por usuário.",1 +V7,Gerenciamento de Sessão,V7.4,Encerramento de Sessão,V7.4.2,Verificar que a aplicação encerra todas as sessões ativas quando uma conta de usuário é desabilitada ou excluída (como um funcionário que deixa a empresa).,1 +V7,Gerenciamento de Sessão,V7.4,Encerramento de Sessão,V7.4.3,"Verificar que a aplicação dá a opção de encerrar todas as outras sessões ativas após uma mudança ou remoção bem-sucedida de qualquer fator de autenticação (incluindo alteração de senha via reset ou recuperação e, se presente, uma atualização das configurações de MFA).",2 +V7,Gerenciamento de Sessão,V7.4,Encerramento de Sessão,V7.4.4,Verificar que todas as páginas que exigem autenticação têm acesso fácil e visível à funcionalidade de logout.,2 +V7,Gerenciamento de Sessão,V7.4,Encerramento de Sessão,V7.4.5,Verificar que os administradores da aplicação são capazes de encerrar sessões ativas para um usuário individual ou para todos os usuários.,2 +V7,Gerenciamento de Sessão,V7.5,Defesas Contra Abuso de Sessão,V7.5.1,"Verificar que a aplicação exige reautenticação completa antes de permitir modificações em atributos sensíveis de conta que possam afetar a autenticação, como endereço de e-mail, número de telefone, configuração de MFA ou outras informações usadas na recuperação de conta.",2 +V7,Gerenciamento de Sessão,V7.5,Defesas Contra Abuso de Sessão,V7.5.2,Verificar que os usuários são capazes de visualizar e (tendo autenticado novamente com pelo menos um fator) encerrar qualquer uma ou todas as sessões ativas atualmente.,2 +V7,Gerenciamento de Sessão,V7.5,Defesas Contra Abuso de Sessão,V7.5.3,Verificar que a aplicação exige autenticação adicional com pelo menos um fator ou verificação secundária antes de realizar transações ou operações altamente sensíveis.,3 +V7,Gerenciamento de Sessão,V7.6,Reautenticação Federada,V7.6.1,"Verificar que o tempo de vida da sessão e o encerramento entre Partes Confiantes (RPs) e Provedores de Identidade (IdPs) se comportam conforme documentado, exigindo reautenticação quando necessário, como quando o tempo máximo entre eventos de autenticação no IdP é atingido.",2 +V7,Gerenciamento de Sessão,V7.6,Reautenticação Federada,V7.6.2,"Verificar que a criação de uma sessão exige o consentimento do usuário ou uma ação explícita, prevenindo a criação de novas sessões de aplicação sem interação do usuário.",2 +V8,Autorização,V8.1,Documentação de Autorização,V8.1.1,Verificar que a documentação de autorização define regras para restringir o acesso em nível de função e dados específicos com base nas permissões do consumidor e atributos do recurso.,1 +V8,Autorização,V8.1,Documentação de Autorização,V8.1.2,"Verificar que a documentação de autorização define regras para restrições de acesso em nível de campo (tanto leitura quanto escrita) com base nas permissões do consumidor e atributos do recurso. Observar que essas regras podem depender de outros valores de atributos do objeto de dados relevante, como estado ou status.",2 +V8,Autorização,V8.1,Documentação de Autorização,V8.1.3,"Verificar que a documentação da aplicação define os atributos ambientais e contextuais (incluindo, mas não se limitando a, hora do dia, localização do usuário, endereço IP ou dispositivo) que são usados na aplicação para tomar decisões de segurança, incluindo aquelas relacionadas à autenticação e autorização.",3 +V8,Autorização,V8.1,Documentação de Autorização,V8.1.4,"Verificar que a documentação de autenticação e autorização define como fatores ambientais e contextuais são usados na tomada de decisões, além da autorização em nível de função, dados específicos e nível de campo. Isso deve incluir os atributos avaliados, limiares de risco e ações tomadas (por exemplo, permitir, desafiar, negar, autenticação step-up).",3 +V8,Autorização,V8.2,Projeto Geral de Autorização,V8.2.1,Verificar que a aplicação garante que o acesso em nível de função é restrito a consumidores com permissões explícitas.,1 +V8,Autorização,V8.2,Projeto Geral de Autorização,V8.2.2,"Verificar que a aplicação garante que o acesso a dados específicos é restrito a consumidores com permissões explícitas para itens de dados específicos, para mitigar referência direta insegura a objetos (IDOR) e autorização quebrada em nível de objeto (BOLA).",1 +V8,Autorização,V8.2,Projeto Geral de Autorização,V8.2.3,"Verificar que a aplicação garante que o acesso em nível de campo é restrito a consumidores com permissões explícitas para campos específicos, para mitigar autorização quebrada em nível de propriedade de objeto (BOPLA).",2 +V8,Autorização,V8.2,Projeto Geral de Autorização,V8.2.4,"Verificar que controles de segurança adaptativa baseados nos atributos ambientais e contextuais de um consumidor (como hora do dia, localização, endereço IP ou dispositivo) são implementados para decisões de autenticação e autorização, conforme definido na documentação da aplicação. Esses controles devem ser aplicados quando o consumidor tenta iniciar uma nova sessão e também durante uma sessão existente.",3 +V8,Autorização,V8.3,Autorização em Nível de Operação,V8.3.1,"Verificar que a aplicação aplica regras de autorização em uma camada de serviço confiável e não depende de controles que um consumidor não confiável possa manipular, como JavaScript no lado do cliente.",1 +V8,Autorização,V8.3,Autorização em Nível de Operação,V8.3.2,"Verificar que as alterações nos valores sobre os quais as decisões de autorização são tomadas são aplicadas imediatamente. Onde alterações não podem ser aplicadas imediatamente (como quando se depende de dados em tokens autocontidos), devem existir controles mitigadores para alertar quando um consumidor realiza uma ação quando não está mais autorizado a fazê-lo e reverter a alteração. Observar que essa alternativa não mitigaria o vazamento de informações.",3 +V8,Autorização,V8.3,Autorização em Nível de Operação,V8.3.3,"Verificar que o acesso a um objeto é baseado nas permissões do sujeito originário (por exemplo, do consumidor), e não nas permissões de qualquer intermediário ou serviço que age em seu nome. Por exemplo, se um consumidor chama um serviço web usando um token autocontido para autenticação, e o serviço então solicita dados de um serviço diferente, o segundo serviço usará o token do consumidor, em vez de um token máquina-a-máquina do primeiro serviço, para tomar decisões de permissão.",3 +V8,Autorização,V8.4,Outras Considerações de Autorização,V8.4.1,Verificar que as aplicações multilocatárias usam controles entre locatários para garantir que as operações do consumidor nunca afetem locatários com os quais eles não têm permissão de interagir.,2 +V8,Autorização,V8.4,Outras Considerações de Autorização,V8.4.2,"Verificar que o acesso a interfaces administrativas incorpora múltiplas camadas de segurança, incluindo verificação contínua de identidade do consumidor, avaliação da postura de segurança do dispositivo e análise contextual de risco, garantindo que a localização na rede ou endpoints confiáveis não sejam os únicos fatores para autorização, mesmo que possam reduzir a probabilidade de acesso não autorizado.",3 +V9,Tokens Autocontidos,V9.1,Fonte e Integridade do Token,V9.1.1,Verificar que os tokens autocontidos são validados usando sua assinatura digital ou MAC para proteção contra adulteração antes de aceitar o conteúdo do token.,1 +V9,Tokens Autocontidos,V9.1,Fonte e Integridade do Token,V9.1.2,"Verificar que apenas algoritmos em uma lista de permissões podem ser usados para criar e verificar tokens autocontidos, para um dado contexto. A lista de permissões deve incluir os algoritmos permitidos, idealmente apenas algoritmos simétricos ou assimétricos, e não deve incluir o algoritmo 'None'. Se ambos simétricos e assimétricos precisarem ser suportados, serão necessários controles adicionais para prevenir confusão de chaves.",1 +V9,Tokens Autocontidos,V9.1,Fonte e Integridade do Token,V9.1.3,"Verificar que o material de chave usado para validar tokens autocontidos provém de fontes pré-configuradas confiáveis para o emissor do token, impedindo que atacantes especifiquem fontes e chaves não confiáveis. Para JWTs e outras estruturas JWS, cabeçalhos como 'jku', 'x5u' e 'jwk' devem ser validados em relação a uma lista de permissões de fontes confiáveis.",1 +V9,Tokens Autocontidos,V9.2,Conteúdo do Token,V9.2.1,"Verificar que, se um intervalo de validade de tempo estiver presente nos dados do token, o token e seu conteúdo são aceitos apenas se o tempo de verificação estiver dentro desse intervalo de validade. Por exemplo, para JWTs, os claims 'nbf' e 'exp' devem ser verificados.",1 +V9,Tokens Autocontidos,V9.2,Conteúdo do Token,V9.2.2,"Verificar que o serviço que recebe um token valida que o token é do tipo correto e se destina à finalidade pretendida antes de aceitar o conteúdo do token. Por exemplo, apenas tokens de acesso podem ser aceitos para decisões de autorização e apenas Tokens ID podem ser usados para comprovar a autenticação do usuário.",2 +V9,Tokens Autocontidos,V9.2,Conteúdo do Token,V9.2.3,"Verificar que o serviço aceita apenas tokens que se destinam ao uso com esse serviço (audiência). Para JWTs, isso pode ser alcançado validando o claim 'aud' em relação a uma lista de permissões definida no serviço.",2 +V9,Tokens Autocontidos,V9.2,Conteúdo do Token,V9.2.4,"Verificar que, se um emissor de token usa a mesma chave privada para emitir tokens para diferentes audiências, os tokens emitidos contêm uma restrição de audiência que identifica de forma única as audiências pretendidas. Isso evitará que um token seja reutilizado com uma audiência não pretendida. Se o identificador de audiência for provisionado dinamicamente, o emissor do token deve validar essas audiências para garantir que não resultem em impersonificação de audiência.",2 +V10,OAuth e OIDC,V10.1,Segurança Genérica de OAuth e OIDC,V10.1.1,"Verificar que os tokens são enviados apenas para componentes que estritamente precisam deles. Por exemplo, ao usar um padrão backend-for-frontend para aplicações JavaScript baseadas em navegador, tokens de acesso e de atualização devem ser acessíveis apenas para o backend.",2 +V10,OAuth e OIDC,V10.1,Segurança Genérica de OAuth e OIDC,V10.1.2,"Verificar que o cliente aceita valores do servidor de autorização (como o código de autorização ou Token ID) apenas se esses valores resultam de um fluxo de autorização iniciado pela mesma sessão do agente de usuário e transação. Isso requer que segredos gerados pelo cliente, como o 'code_verifier' da prova de chave para troca de código (PKCE), 'state' ou 'nonce' do OIDC, não sejam adivinháveis, sejam específicos à transação e estejam seguramente vinculados tanto ao cliente quanto à sessão do agente de usuário na qual a transação foi iniciada.",2 +V10,OAuth e OIDC,V10.2,Cliente OAuth,V10.2.1,"Verificar que, se o fluxo de código é usado, o cliente OAuth tem proteção contra ataques de falsificação de requisição baseados no navegador, comumente conhecidos como cross-site request forgery (CSRF), que acionam requisições de token, seja usando a funcionalidade de prova de chave para troca de código (PKCE) ou verificando o parâmetro 'state' que foi enviado na requisição de autorização.",2 +V10,OAuth e OIDC,V10.2,Cliente OAuth,V10.2.2,"Verificar que, se o cliente OAuth pode interagir com mais de um servidor de autorização, ele tem uma defesa contra ataques de mix-up. Por exemplo, poderia exigir que o servidor de autorização retorne o valor do parâmetro 'iss' e validá-lo na resposta de autorização e na resposta de token.",2 +V10,OAuth e OIDC,V10.2,Cliente OAuth,V10.2.3,Verificar que o cliente OAuth solicita apenas os escopos necessários (ou outros parâmetros de autorização) nas requisições ao servidor de autorização.,3 +V10,OAuth e OIDC,V10.3,Servidor de Recursos OAuth,V10.3.1,Verificar que o servidor de recursos aceita apenas tokens de acesso destinados ao uso com esse serviço (audiência). A audiência pode estar incluída em um token de acesso estruturado (como o claim 'aud' em JWT) ou pode ser verificada usando o endpoint de introspecção de token.,2 +V10,OAuth e OIDC,V10.3,Servidor de Recursos OAuth,V10.3.2,"Verificar que o servidor de recursos aplica decisões de autorização com base em claims do token de acesso que definem a autorização delegada. Se claims como 'sub', 'scope' e 'authorization_details' estiverem presentes, devem fazer parte da decisão.",2 +V10,OAuth e OIDC,V10.3,Servidor de Recursos OAuth,V10.3.3,"Verificar que, se uma decisão de controle de acesso requer a identificação de um usuário único a partir de um token de acesso (JWT ou resposta de introspecção de token relacionada), o servidor de recursos identifica o usuário a partir de claims que não podem ser reatribuídos a outros usuários. Tipicamente, isso significa usar uma combinação dos claims 'iss' e 'sub'.",2 +V10,OAuth e OIDC,V10.3,Servidor de Recursos OAuth,V10.3.4,"Verificar que, se o servidor de recursos requer força de autenticação, métodos ou recenticidade específicos, ele verifica se o token de acesso apresentado satisfaz essas restrições. Por exemplo, se presentes, usando os claims OIDC 'acr', 'amr' e 'auth_time' respectivamente.",2 +V10,OAuth e OIDC,V10.3,Servidor de Recursos OAuth,V10.3.5,"Verificar que o servidor de recursos previne o uso de tokens de acesso roubados ou replay de tokens de acesso (de partes não autorizadas) ao exigir tokens de acesso vinculados ao remetente, seja TLS Mútuo para OAuth 2 ou OAuth 2 Demonstration of Proof of Possession (DPoP).",3 +V10,OAuth e OIDC,V10.4,Servidor de Autorização OAuth,V10.4.1,Verificar que o servidor de autorização valida URIs de redirecionamento com base em uma lista de permissões específica do cliente com URIs pré-registrados usando comparação exata de strings.,1 +V10,OAuth e OIDC,V10.4,Servidor de Autorização OAuth,V10.4.2,"Verificar que, se o servidor de autorização retorna o código de autorização na resposta de autorização, ele só pode ser usado uma vez para uma requisição de token. Para a segunda requisição válida com um código de autorização que já foi usado para emitir um token de acesso, o servidor de autorização deve rejeitar a requisição de token e revogar todos os tokens emitidos relacionados ao código de autorização.",1 +V10,OAuth e OIDC,V10.4,Servidor de Autorização OAuth,V10.4.3,Verificar que o código de autorização tem vida curta. O tempo de vida máximo pode ser de até 10 minutos para aplicações L1 e L2 e de até 1 minuto para aplicações L3.,1 +V10,OAuth e OIDC,V10.4,Servidor de Autorização OAuth,V10.4.4,"Verificar que, para um determinado cliente, o servidor de autorização só permite o uso de concessões que esse cliente precisa usar. Observar que as concessões 'token' (fluxo Implícito) e 'password' (fluxo de Credenciais de Senha do Proprietário do Recurso) não devem mais ser usadas.",1 +V10,OAuth e OIDC,V10.4,Servidor de Autorização OAuth,V10.4.5,"Verificar que o servidor de autorização mitiga ataques de replay de token de atualização para clientes públicos, preferencialmente usando tokens de atualização vinculados ao remetente, ou seja, Demonstrating Proof of Possession (DPoP) ou Tokens de Acesso Vinculados a Certificado usando TLS mútuo (mTLS). Para aplicações L1 e L2, a rotação de token de atualização pode ser usada. Se a rotação de token de atualização for usada, o servidor de autorização deve invalidar o token de atualização após o uso e revogar todos os tokens de atualização para essa autorização se um token de atualização já usado e invalidado for fornecido.",1 +V10,OAuth e OIDC,V10.4,Servidor de Autorização OAuth,V10.4.6,"Verificar que, se o fluxo de código é usado, o servidor de autorização mitiga ataques de interceptação de código de autorização ao exigir prova de chave para troca de código (PKCE). Para requisições de autorização, o servidor de autorização deve exigir um valor 'code_challenge' válido e não deve aceitar um valor 'code_challenge_method' de 'plain'. Para uma requisição de token, deve exigir a validação do parâmetro 'code_verifier'.",2 +V10,OAuth e OIDC,V10.4,Servidor de Autorização OAuth,V10.4.7,"Verificar que, se o servidor de autorização suporta registro dinâmico de cliente não autenticado, ele mitiga o risco de aplicações cliente maliciosas. Deve validar metadados do cliente como quaisquer URIs registrados, garantir o consentimento do usuário e avisar o usuário antes de processar uma requisição de autorização com uma aplicação cliente não confiável.",2 +V10,OAuth e OIDC,V10.4,Servidor de Autorização OAuth,V10.4.8,"Verificar que os tokens de atualização têm uma expiração absoluta, incluindo se a expiração deslizante de token de atualização for aplicada.",2 +V10,OAuth e OIDC,V10.4,Servidor de Autorização OAuth,V10.4.9,"Verificar que tokens de atualização e tokens de acesso de referência podem ser revogados por um usuário autorizado usando a interface de usuário do servidor de autorização, para mitigar o risco de clientes maliciosos ou tokens roubados.",2 +V10,OAuth e OIDC,V10.4,Servidor de Autorização OAuth,V10.4.10,"Verificar que o cliente confidencial é autenticado para requisições de backchannel cliente-para-servidor autorizado, como requisições de token, requisições de autorização enviadas (PAR) e requisições de revogação de token.",2 +V10,OAuth e OIDC,V10.4,Servidor de Autorização OAuth,V10.4.11,Verificar que a configuração do servidor de autorização atribui apenas os escopos necessários ao cliente OAuth.,2 +V10,OAuth e OIDC,V10.4,Servidor de Autorização OAuth,V10.4.12,"Verificar que, para um determinado cliente, o servidor de autorização só permite o valor de 'response_mode' que esse cliente precisa usar. Por exemplo, fazendo com que o servidor de autorização valide esse valor em relação aos valores esperados ou usando requisição de autorização enviada (PAR) ou Requisição de Autorização Protegida com JWT (JAR).",3 +V10,OAuth e OIDC,V10.4,Servidor de Autorização OAuth,V10.4.13,Verificar que o tipo de concessão 'code' é sempre usado em conjunto com requisições de autorização enviadas (PAR).,3 +V10,OAuth e OIDC,V10.4,Servidor de Autorização OAuth,V10.4.14,"Verificar que o servidor de autorização emite apenas tokens de acesso vinculados ao remetente (Proof-of-Possession), seja com tokens de acesso vinculados a certificado usando TLS mútuo (mTLS) ou tokens de acesso vinculados ao DPoP (Demonstration of Proof of Possession).",3 +V10,OAuth e OIDC,V10.4,Servidor de Autorização OAuth,V10.4.15,"Verificar que, para um cliente do lado do servidor (que não é executado no dispositivo do usuário final), o servidor de autorização garante que o valor do parâmetro 'authorization_details' seja do backend do cliente e que o usuário não o tenha adulterado. Por exemplo, exigindo o uso de requisição de autorização enviada (PAR) ou Requisição de Autorização Protegida com JWT (JAR).",3 +V10,OAuth e OIDC,V10.4,Servidor de Autorização OAuth,V10.4.16,"Verificar que o cliente é confidencial e o servidor de autorização exige o uso de métodos fortes de autenticação de cliente (baseados em criptografia de chave pública e resistentes a ataques de replay), como TLS mútuo ('tls_client_auth', 'self_signed_tls_client_auth') ou JWT de chave privada ('private_key_jwt').",3 +V10,OAuth e OIDC,V10.5,Cliente OIDC,V10.5.1,"Verificar que o cliente (como parte confiante) mitiga ataques de replay de Token ID. Por exemplo, garantindo que o claim 'nonce' no Token ID corresponda ao valor 'nonce' enviado na requisição de autenticação ao Provedor OpenID (em OAuth2 referido como a requisição de autorização enviada ao servidor de autorização).",2 +V10,OAuth e OIDC,V10.5,Cliente OIDC,V10.5.2,"Verificar que o cliente identifica de forma única o usuário a partir dos claims do Token ID, geralmente o claim 'sub', que não pode ser reatribuído a outros usuários (para o escopo de um provedor de identidade).",2 +V10,OAuth e OIDC,V10.5,Cliente OIDC,V10.5.3,Verificar que o cliente rejeita tentativas de um servidor de autorização malicioso de se passar por outro servidor de autorização por meio de metadados do servidor de autorização. O cliente deve rejeitar metadados do servidor de autorização se a URL do emissor nos metadados do servidor de autorização não corresponder exatamente à URL do emissor pré-configurada esperada pelo cliente.,2 +V10,OAuth e OIDC,V10.5,Cliente OIDC,V10.5.4,Verificar que o cliente valida que o Token ID é destinado ao uso para esse cliente (audiência) verificando que o claim 'aud' do token é igual ao valor 'client_id' do cliente.,2 +V10,OAuth e OIDC,V10.5,Cliente OIDC,V10.5.5,"Verificar que, ao usar o logout de backchannel OIDC, a parte confiante mitiga a negação de serviço por logout forçado e confusão entre JWTs no fluxo de logout. O cliente deve verificar que o token de logout tem o tipo correto com um valor de 'logout+jwt', contém o claim 'event' com o nome de membro correto e não contém um claim 'nonce'. Observar que também é recomendado ter uma expiração curta (por exemplo, 2 minutos).",2 +V10,OAuth e OIDC,V10.6,Provedor OpenID,V10.6.1,"Verificar que o Provedor OpenID permite apenas os valores 'code', 'ciba', 'id_token' ou 'id_token code' para modo de resposta. Observar que 'code' é preferido em relação a 'id_token code' (o fluxo Híbrido OIDC) e 'token' (qualquer fluxo Implícito) não deve ser usado.",2 +V10,OAuth e OIDC,V10.6,Provedor OpenID,V10.6.2,"Verificar que o Provedor OpenID mitiga a negação de serviço por logout forçado. Obtendo confirmação explícita do usuário final ou, se presentes, validando os parâmetros na requisição de logout (iniciada pela parte confiante), como o 'id_token_hint'.",2 +V10,OAuth e OIDC,V10.7,Gerenciamento de Consentimento,V10.7.1,"Verificar que o servidor de autorização garante que o usuário consente a cada requisição de autorização. Se a identidade do cliente não puder ser assegurada, o servidor de autorização deve sempre solicitar explicitamente o consentimento do usuário.",2 +V10,OAuth e OIDC,V10.7,Gerenciamento de Consentimento,V10.7.2,"Verificar que, ao solicitar o consentimento do usuário, o servidor de autorização apresenta informações suficientes e claras sobre o que está sendo consentido. Quando aplicável, isso deve incluir a natureza das autorizações solicitadas (tipicamente com base no escopo, servidor de recursos, detalhes de autorização Rich Authorization Requests (RAR)), a identidade da aplicação autorizada e o tempo de vida dessas autorizações.",2 +V10,OAuth e OIDC,V10.7,Gerenciamento de Consentimento,V10.7.3,"Verificar que o usuário pode revisar, modificar e revogar consentimentos que ele concedeu por meio do servidor de autorização.",2 +V11,Criptografia,V11.1,Inventário e Documentação Criptográfica,V11.1.1,"Verificar que existe uma política documentada para gerenciamento de chaves criptográficas e um ciclo de vida de chaves criptográficas que segue um padrão de gerenciamento de chaves como o NIST SP 800-57. Isso deve incluir garantir que as chaves não sejam compartilhadas em excesso (por exemplo, com mais de duas entidades para segredos compartilhados e mais de uma entidade para chaves privadas).",2 +V11,Criptografia,V11.1,Inventário e Documentação Criptográfica,V11.1.2,"Verificar que um inventário criptográfico é realizado, mantido, regularmente atualizado e inclui todas as chaves criptográficas, algoritmos e certificados usados pela aplicação. Também deve documentar onde as chaves podem e não podem ser usadas no sistema e os tipos de dados que podem e não podem ser protegidos usando as chaves.",2 +V11,Criptografia,V11.1,Inventário e Documentação Criptográfica,V11.1.3,"Verificar que mecanismos de descoberta criptográfica são empregados para identificar todas as instâncias de criptografia no sistema, incluindo operações de criptografia, hash e assinatura.",3 +V11,Criptografia,V11.1,Inventário e Documentação Criptográfica,V11.1.4,"Verificar que um inventário criptográfico é mantido. Deve incluir um plano documentado que delineie o caminho de migração para novos padrões criptográficos, como criptografia pós-quântica, a fim de reagir a ameaças futuras.",3 +V11,Criptografia,V11.2,Implementação Segura de Criptografia,V11.2.1,Verificar que implementações validadas pela indústria (incluindo bibliotecas e implementações aceleradas por hardware) são usadas para operações criptográficas.,2 +V11,Criptografia,V11.2,Implementação Segura de Criptografia,V11.2.2,"Verificar que a aplicação é projetada com agilidade criptográfica, de modo que os algoritmos de número aleatório, criptografia autenticada, MAC ou hash, comprimentos de chave, rodadas, cifras e modos possam ser reconfigurados, atualizados ou substituídos a qualquer momento, para proteger contra rupturas criptográficas. Da mesma forma, também deve ser possível substituir chaves e senhas e recriptografar dados. Isso permitirá atualizações contínuas para criptografia pós-quântica (PQC), quando implementações de alta segurança de esquemas ou padrões PQC aprovados estiverem amplamente disponíveis.",2 +V11,Criptografia,V11.2,Implementação Segura de Criptografia,V11.2.3,"Verificar que todas as primitivas criptográficas utilizam um mínimo de 128 bits de segurança com base no algoritmo, tamanho de chave e configuração. Por exemplo, uma chave ECC de 256 bits fornece aproximadamente 128 bits de segurança, enquanto o RSA requer uma chave de 3072 bits para atingir 128 bits de segurança.",2 +V11,Criptografia,V11.2,Implementação Segura de Criptografia,V11.2.4,"Verificar que todas as operações criptográficas são de tempo constante, sem operações de 'curto-circuito' em comparações, cálculos ou retornos, para evitar o vazamento de informações.",3 +V11,Criptografia,V11.2,Implementação Segura de Criptografia,V11.2.5,"Verificar que todos os módulos criptográficos falham de forma segura e os erros são tratados de maneira que não habilite vulnerabilidades, como ataques de Padding Oracle.",3 +V11,Criptografia,V11.3,Algoritmos de Criptografia,V11.3.1,"Verificar que modos de bloco inseguros (por exemplo, ECB) e esquemas de padding fracos (por exemplo, PKCS#1 v1.5) não são usados.",1 +V11,Criptografia,V11.3,Algoritmos de Criptografia,V11.3.2,"Verificar que apenas cifras e modos aprovados, como AES com GCM, são usados.",1 +V11,Criptografia,V11.3,Algoritmos de Criptografia,V11.3.3,"Verificar que dados criptografados são protegidos contra modificação não autorizada, preferencialmente usando um método de criptografia autenticada aprovado ou combinando um método de criptografia aprovado com um algoritmo MAC aprovado.",2 +V11,Criptografia,V11.3,Algoritmos de Criptografia,V11.3.4,"Verificar que nonces, vetores de inicialização e outros números de uso único não são reutilizados para mais de um par de chave de criptografia e elemento de dado. O método de geração deve ser adequado para o algoritmo em uso.",3 +V11,Criptografia,V11.3,Algoritmos de Criptografia,V11.3.5,Verificar que qualquer combinação de um algoritmo de criptografia e um algoritmo MAC está operando no modo encrypt-then-MAC.,3 +V11,Criptografia,V11.4,Funções de Hash e Baseadas em Hash,V11.4.1,"Verificar que apenas funções de hash aprovadas são usadas para casos de uso criptográfico geral, incluindo assinaturas digitais, HMAC, KDF e geração de bits aleatórios. Funções de hash não permitidas, como MD5, não devem ser usadas para nenhuma finalidade criptográfica.",1 +V11,Criptografia,V11.4,Funções de Hash e Baseadas em Hash,V11.4.2,"Verificar que as senhas são armazenadas usando uma função de derivação de chave aprovada e computacionalmente intensiva (também conhecida como 'função de hash de senha'), com configurações de parâmetros configuradas com base na orientação atual. As configurações devem equilibrar segurança e desempenho para tornar os ataques de força bruta suficientemente desafiadores para o nível de segurança exigido.",2 +V11,Criptografia,V11.4,Funções de Hash e Baseadas em Hash,V11.4.3,"Verificar que as funções de hash usadas em assinaturas digitais, como parte de autenticação de dados ou integridade de dados, são resistentes a colisão e têm comprimentos de bits adequados. Se a resistência à colisão for necessária, o comprimento de saída deve ser de pelo menos 256 bits. Se apenas a resistência a ataques de segunda pré-imagem for necessária, o comprimento de saída deve ser de pelo menos 128 bits.",2 +V11,Criptografia,V11.4,Funções de Hash e Baseadas em Hash,V11.4.4,Verificar que a aplicação usa funções de derivação de chave aprovadas com parâmetros de key stretching ao derivar chaves secretas de senhas. Os parâmetros em uso devem equilibrar segurança e desempenho para prevenir ataques de força bruta de comprometer a chave criptográfica resultante.,2 +V11,Criptografia,V11.5,Valores Aleatórios,V11.5.1,Verificar que todos os números e strings aleatórios destinados a ser não adivinháveis devem ser gerados usando um gerador de números pseudoaleatórios criptograficamente seguro (CSPRNG) e ter pelo menos 128 bits de entropia. Observar que UUIDs não respeitam essa condição.,2 +V11,Criptografia,V11.5,Valores Aleatórios,V11.5.2,"Verificar que o mecanismo de geração de números aleatórios em uso é projetado para funcionar de forma segura, mesmo sob alta demanda.",3 +V11,Criptografia,V11.6,Criptografia de Chave Pública,V11.6.1,"Verificar que apenas algoritmos e modos de operação criptográficos aprovados são usados para geração e inicialização de chaves, e geração e verificação de assinatura digital. Os algoritmos de geração de chave não devem gerar chaves inseguras vulneráveis a ataques conhecidos, por exemplo, chaves RSA que são vulneráveis à fatoração de Fermat.",2 +V11,Criptografia,V11.6,Criptografia de Chave Pública,V11.6.2,Verificar que algoritmos criptográficos aprovados são usados para troca de chaves (como Diffie-Hellman) com foco em garantir que os mecanismos de troca de chaves usem parâmetros seguros. Isso prevenirá ataques no processo de estabelecimento de chave que possam levar a ataques adversário-no-meio ou rupturas criptográficas.,3 +V11,Criptografia,V11.7,Criptografia de Dados em Uso,V11.7.1,"Verificar que a criptografia completa de memória está em uso, protegendo dados sensíveis enquanto estão em uso, prevenindo acesso por usuários ou processos não autorizados.",3 +V11,Criptografia,V11.7,Criptografia de Dados em Uso,V11.7.2,"Verificar que a minimização de dados garante que a quantidade mínima de dados seja exposta durante o processamento, e garantir que os dados sejam criptografados imediatamente após o uso ou assim que possível.",3 +V12,Comunicação Segura,V12.1,Orientações Gerais de Segurança TLS,V12.1.1,"Verificar que apenas as versões mais recentes recomendadas do protocolo TLS estão habilitadas, como TLS 1.2 e TLS 1.3. A versão mais recente do protocolo TLS deve ser a opção preferida.",1 +V12,Comunicação Segura,V12.1,Orientações Gerais de Segurança TLS,V12.1.2,"Verificar que apenas suítes de cifra recomendadas estão habilitadas, com as suítes de cifra mais fortes definidas como preferidas. Aplicações L3 devem suportar apenas suítes de cifra que fornecem sigilo de encaminhamento.",2 +V12,Comunicação Segura,V12.1,Orientações Gerais de Segurança TLS,V12.1.3,Verificar que a aplicação valida que os certificados de cliente mTLS são confiáveis antes de usar a identidade do certificado para autenticação ou autorização.,2 +V12,Comunicação Segura,V12.1,Orientações Gerais de Segurança TLS,V12.1.4,"Verificar que a revogação adequada de certificação, como o OCSP Stapling (Online Certificate Status Protocol), está habilitada e configurada.",3 +V12,Comunicação Segura,V12.1,Orientações Gerais de Segurança TLS,V12.1.5,"Verificar que o Encrypted Client Hello (ECH) está habilitado nas configurações TLS da aplicação para prevenir a exposição de metadados sensíveis, como a Indicação de Nome do Servidor (SNI), durante os processos de handshake TLS.",3 +V12,Comunicação Segura,V12.2,Comunicação HTTPS com Serviços Externos,V12.2.1,"Verificar que TLS é usado para toda a conectividade entre um cliente e serviços HTTP externos, e que não há fallback para comunicações inseguras ou não criptografadas.",1 +V12,Comunicação Segura,V12.2,Comunicação HTTPS com Serviços Externos,V12.2.2,Verificar que os serviços externos usam certificados TLS publicamente confiáveis.,1 +V12,Comunicação Segura,V12.3,Segurança Geral de Comunicação entre Serviços,V12.3.1,"Verificar que um protocolo criptografado como TLS é usado para todas as conexões de entrada e saída de e para a aplicação, incluindo sistemas de monitoramento, ferramentas de gerenciamento, acesso remoto e SSH, middleware, bancos de dados, mainframes, sistemas parceiros ou APIs externas. O servidor não deve realizar fallback para protocolos inseguros ou não criptografados.",2 +V12,Comunicação Segura,V12.3,Segurança Geral de Comunicação entre Serviços,V12.3.2,Verificar que os clientes TLS validam os certificados recebidos antes de se comunicar com um servidor TLS.,2 +V12,Comunicação Segura,V12.3,Segurança Geral de Comunicação entre Serviços,V12.3.3,"Verificar que TLS ou outro mecanismo apropriado de criptografia de transporte é usado para toda a conectividade entre serviços HTTP internos na aplicação, e que não há fallback para comunicações inseguras ou não criptografadas.",2 +V12,Comunicação Segura,V12.3,Segurança Geral de Comunicação entre Serviços,V12.3.4,"Verificar que as conexões TLS entre serviços internos usam certificados confiáveis. Onde certificados gerados internamente ou autoassinados são usados, o serviço consumidor deve ser configurado para confiar apenas em CAs internas específicas e certificados autoassinados específicos.",2 +V12,Comunicação Segura,V12.3,Segurança Geral de Comunicação entre Serviços,V12.3.5,"Verificar que os serviços que se comunicam internamente em um sistema (comunicações intraserviço) usam autenticação forte para garantir que cada endpoint seja verificado. Métodos de autenticação fortes, como autenticação de cliente TLS, devem ser empregados para garantir a identidade, usando infraestrutura de chave pública e mecanismos resistentes a ataques de replay. Para arquiteturas de microsserviços, considere usar um service mesh para simplificar o gerenciamento de certificados e aprimorar a segurança.",3 +V13,Configuração,V13.1,Documentação de Configuração,V13.1.1,Verificar que todas as necessidades de comunicação da aplicação estão documentadas. Isso deve incluir serviços externos dos quais a aplicação depende e casos onde um usuário final pode fornecer um local externo ao qual a aplicação se conectará.,2 +V13,Configuração,V13.1,Documentação de Configuração,V13.1.2,"Verificar que, para cada serviço que a aplicação usa, a documentação define o número máximo de conexões simultâneas (por exemplo, limites de pool de conexões) e como a aplicação se comporta quando esse limite é atingido, incluindo quaisquer mecanismos de fallback ou recuperação, para prevenir condições de negação de serviço.",3 +V13,Configuração,V13.1,Documentação de Configuração,V13.1.3,"Verificar que a documentação da aplicação define estratégias de gerenciamento de recursos para cada sistema ou serviço externo que usa (por exemplo, bancos de dados, descritores de arquivo, threads, conexões HTTP). Isso deve incluir procedimentos de liberação de recursos, configurações de timeout, tratamento de falhas e, onde a lógica de retry é implementada, especificando limites de retry, atrasos e algoritmos de backoff. Para operações síncronas de requisição-resposta HTTP, deve exigir timeouts curtos e desabilitar ou limitar estritamente os retries para prevenir atrasos em cascata e esgotamento de recursos.",3 +V13,Configuração,V13.1,Documentação de Configuração,V13.1.4,"Verificar que a documentação da aplicação define os segredos críticos para a segurança da aplicação e um cronograma para rotacioná-los, com base no modelo de ameaças e requisitos de negócio da organização.",3 +V13,Configuração,V13.2,Configuração de Comunicação com Backend,V13.2.1,"Verificar que as comunicações entre componentes de aplicação backend que não suportam o mecanismo de sessão de usuário padrão da aplicação, incluindo APIs, middleware e camadas de dados, são autenticadas. A autenticação deve usar contas de serviço individuais, tokens de curto prazo ou autenticação baseada em certificado, e não credenciais imutáveis como senhas, chaves de API ou contas compartilhadas com acesso privilegiado.",2 +V13,Configuração,V13.2,Configuração de Comunicação com Backend,V13.2.2,"Verificar que as comunicações entre componentes de aplicação backend, incluindo serviços locais ou do sistema operacional, APIs, middleware e camadas de dados, são realizadas com contas atribuídas ao menor privilégio necessário.",2 +V13,Configuração,V13.2,Configuração de Comunicação com Backend,V13.2.3,"Verificar que, se uma credencial tiver de ser usada para autenticação de serviço, a credencial usada pelo consumidor não é uma credencial padrão (por exemplo, root/root ou admin/admin).",2 +V13,Configuração,V13.2,Configuração de Comunicação com Backend,V13.2.4,"Verificar que uma lista de permissões é usada para definir os recursos ou sistemas externos com os quais a aplicação tem permissão de se comunicar (por exemplo, para requisições de saída, cargas de dados ou acesso a arquivos). Essa lista de permissões pode ser implementada na camada de aplicação, servidor web, firewall ou uma combinação de diferentes camadas.",2 +V13,Configuração,V13.2,Configuração de Comunicação com Backend,V13.2.5,Verificar que o servidor web ou de aplicação está configurado com uma lista de permissões de recursos ou sistemas para os quais o servidor pode enviar requisições ou carregar dados ou arquivos.,2 +V13,Configuração,V13.2,Configuração de Comunicação com Backend,V13.2.6,"Verificar que, onde a aplicação se conecta a serviços separados, ela segue a configuração documentada para cada conexão, como número máximo de conexões paralelas, comportamento quando o número máximo de conexões permitidas é atingido, timeouts de conexão e estratégias de retry.",3 +V13,Configuração,V13.3,Gerenciamento de Segredos,V13.3.1,"Verificar que uma solução de gerenciamento de segredos, como um cofre de chaves, é usada para criar, armazenar, controlar o acesso e destruir segredos de backend de forma segura. Estes podem incluir senhas, material de chave, integrações com bancos de dados e sistemas de terceiros, chaves e seeds para tokens baseados em tempo, outros segredos internos e chaves de API. Os segredos não devem ser incluídos no código-fonte da aplicação ou em artefatos de build. Para uma aplicação L3, isso deve envolver uma solução respaldada por hardware como um HSM.",2 +V13,Configuração,V13.3,Gerenciamento de Segredos,V13.3.2,Verificar que o acesso a ativos de segredo adere ao princípio do menor privilégio.,2 +V13,Configuração,V13.3,Gerenciamento de Segredos,V13.3.3,Verificar que todas as operações criptográficas são realizadas usando um módulo de segurança isolado (como um cofre ou módulo de segurança de hardware) para gerenciar e proteger de forma segura o material de chave contra exposição fora do módulo de segurança.,3 +V13,Configuração,V13.3,Gerenciamento de Segredos,V13.3.4,Verificar que os segredos são configurados para expirar e ser rotacionados com base na documentação da aplicação.,3 +V13,Configuração,V13.4,Vazamento Não Intencional de Informações,V13.4.1,"Verificar que a aplicação é implantada sem nenhum metadado de controle de código-fonte, incluindo as pastas .git ou .svn, ou de uma forma que essas pastas sejam inacessíveis tanto externamente quanto pela própria aplicação.",1 +V13,Configuração,V13.4,Vazamento Não Intencional de Informações,V13.4.2,"Verificar que os modos de depuração estão desabilitados para todos os componentes nos ambientes de produção, para prevenir a exposição de recursos de depuração e vazamento de informações.",2 +V13,Configuração,V13.4,Vazamento Não Intencional de Informações,V13.4.3,"Verificar que os servidores web não expõem listagens de diretório aos clientes, a menos que seja explicitamente pretendido.",2 +V13,Configuração,V13.4,Vazamento Não Intencional de Informações,V13.4.4,"Verificar que o uso do método HTTP TRACE não é suportado em ambientes de produção, para evitar possível vazamento de informações.",2 +V13,Configuração,V13.4,Vazamento Não Intencional de Informações,V13.4.5,"Verificar que documentação (como para APIs internas) e endpoints de monitoramento não são expostos, a menos que seja explicitamente pretendido.",2 +V13,Configuração,V13.4,Vazamento Não Intencional de Informações,V13.4.6,Verificar que a aplicação não expõe informações detalhadas de versão dos componentes de backend.,3 +V13,Configuração,V13.4,Vazamento Não Intencional de Informações,V13.4.7,"Verificar que a camada web está configurada para servir apenas arquivos com extensões de arquivo específicas, para prevenir o vazamento não intencional de informações, configurações e código-fonte.",3 +V14,Proteção de Dados,V14.1,Documentação de Proteção de Dados,V14.1.1,"Verificar que todos os dados sensíveis criados e processados pela aplicação foram identificados e classificados em níveis de proteção. Isso inclui dados que são apenas codificados e, portanto, facilmente decodificados, como strings Base64 ou o payload em texto simples dentro de um JWT. Os níveis de proteção precisam levar em conta quaisquer regulamentos e padrões de proteção de dados e privacidade com os quais a aplicação deve estar em conformidade.",2 +V14,Proteção de Dados,V14.1,Documentação de Proteção de Dados,V14.1.2,"Verificar que todos os níveis de proteção de dados sensíveis têm um conjunto documentado de requisitos de proteção. Isso deve incluir (mas não se limitar a) requisitos relacionados à criptografia geral, verificação de integridade, retenção, como os dados devem ser registrados, controles de acesso em torno de dados sensíveis em logs, criptografia em nível de banco de dados, privacidade e tecnologias de aprimoramento de privacidade a serem usadas, e outros requisitos de confidencialidade.",2 +V14,Proteção de Dados,V14.2,Proteção Geral de Dados,V14.2.1,"Verificar que dados sensíveis são enviados ao servidor apenas no corpo da mensagem HTTP ou campos de cabeçalho, e que a URL e a string de consulta não contêm informações sensíveis, como uma chave de API ou token de sessão.",1 +V14,Proteção de Dados,V14.2,Proteção Geral de Dados,V14.2.2,"Verificar que a aplicação evita que dados sensíveis sejam armazenados em cache em componentes do servidor, como balanceadores de carga e caches de aplicação, ou garante que os dados sejam purgados de forma segura após o uso.",2 +V14,Proteção de Dados,V14.2,Proteção Geral de Dados,V14.2.3,"Verificar que dados sensíveis definidos não são enviados a partes não confiáveis (por exemplo, rastreadores de usuários) para evitar a coleta indesejada de dados fora do controle da aplicação.",2 +V14,Proteção de Dados,V14.2,Proteção Geral de Dados,V14.2.4,"Verificar que os controles em torno de dados sensíveis relacionados à criptografia, verificação de integridade, retenção, como os dados devem ser registrados, controles de acesso em torno de dados sensíveis em logs, privacidade e tecnologias de aprimoramento de privacidade são implementados conforme definido na documentação para o nível de proteção dos dados específicos.",2 +V14,Proteção de Dados,V14.2,Proteção Geral de Dados,V14.2.5,"Verificar que os mecanismos de cache são configurados para armazenar em cache apenas respostas que têm o tipo de conteúdo esperado para esse recurso e não contêm conteúdo dinâmico e sensível. O servidor web deve retornar uma resposta 404 ou 302 quando um arquivo inexistente é acessado, em vez de retornar um arquivo diferente e válido. Isso deve prevenir ataques de Web Cache Deception.",3 +V14,Proteção de Dados,V14.2,Proteção Geral de Dados,V14.2.6,"Verificar que a aplicação retorna apenas o mínimo de dados sensíveis necessários para a funcionalidade da aplicação. Por exemplo, retornar apenas alguns dígitos de um número de cartão de crédito e não o número completo. Se os dados completos forem necessários, devem ser mascarados na interface do usuário, a menos que o usuário os visualize especificamente.",3 +V14,Proteção de Dados,V14.2,Proteção Geral de Dados,V14.2.7,"Verificar que as informações sensíveis estão sujeitas à classificação de retenção de dados, garantindo que dados desatualizados ou desnecessários sejam excluídos automaticamente, em um cronograma definido ou conforme a situação exigir.",3 +V14,Proteção de Dados,V14.2,Proteção Geral de Dados,V14.2.8,"Verificar que informações sensíveis são removidas dos metadados de arquivos enviados pelo usuário, a menos que o armazenamento seja consentido pelo usuário.",3 +V14,Proteção de Dados,V14.3,Proteção de Dados no Lado do Cliente,V14.3.1,"Verificar que os dados autenticados são limpos do armazenamento do cliente, como o DOM do navegador, após o término do cliente ou da sessão. O campo de cabeçalho HTTP de resposta 'Clear-Site-Data' pode ajudar nisso, mas o lado do cliente também deve ser capaz de limpar se a conexão com o servidor não estiver disponível quando a sessão for encerrada.",1 +V14,Proteção de Dados,V14.3,Proteção de Dados no Lado do Cliente,V14.3.2,"Verificar que a aplicação define campos de cabeçalho HTTP de resposta anti-cache suficientes (ou seja, Cache-Control: no-store) para que dados sensíveis não sejam armazenados em cache nos navegadores.",2 +V14,Proteção de Dados,V14.3,Proteção de Dados no Lado do Cliente,V14.3.3,"Verificar que os dados armazenados no armazenamento do navegador (como localStorage, sessionStorage, IndexedDB ou cookies) não contêm dados sensíveis, com exceção de tokens de sessão.",2 +V15,Codificação e Arquitetura Segura,V15.1,Documentação de Codificação e Arquitetura Segura,V15.1.1,"Verificar que a documentação da aplicação define prazos de remediação baseados em risco para versões de componentes de terceiros com vulnerabilidades e para atualização de bibliotecas em geral, a fim de minimizar o risco proveniente desses componentes.",1 +V15,Codificação e Arquitetura Segura,V15.1,Documentação de Codificação e Arquitetura Segura,V15.1.2,"Verificar que um catálogo de inventário, como uma software bill of materials (SBOM), é mantido de todas as bibliotecas de terceiros em uso, incluindo a verificação de que os componentes vêm de repositórios predefinidos, confiáveis e continuamente mantidos.",2 +V15,Codificação e Arquitetura Segura,V15.1,Documentação de Codificação e Arquitetura Segura,V15.1.3,"Verificar que a documentação da aplicação identifica funcionalidades que são demoradas ou exigem muitos recursos. Isso deve incluir como prevenir uma perda de disponibilidade devido ao uso excessivo dessa funcionalidade e como evitar uma situação em que a construção de uma resposta demore mais do que o timeout do consumidor. As defesas potenciais podem incluir processamento assíncrono, uso de filas e limitação de processos paralelos por usuário e por aplicação.",2 +V15,Codificação e Arquitetura Segura,V15.1,Documentação de Codificação e Arquitetura Segura,V15.1.4,Verificar que a documentação da aplicação destaca bibliotecas de terceiros consideradas 'componentes de risco'.,3 +V15,Codificação e Arquitetura Segura,V15.1,Documentação de Codificação e Arquitetura Segura,V15.1.5,Verificar que a documentação da aplicação destaca partes da aplicação onde 'funcionalidade perigosa' está sendo usada.,3 +V15,Codificação e Arquitetura Segura,V15.2,Arquitetura de Segurança e Dependências,V15.2.1,Verificar que a aplicação contém apenas componentes que não excederam os prazos documentados de atualização e remediação.,1 +V15,Codificação e Arquitetura Segura,V15.2,Arquitetura de Segurança e Dependências,V15.2.2,"Verificar que a aplicação implementou defesas contra perda de disponibilidade devido a funcionalidades demoradas ou que exigem muitos recursos, com base nas decisões e estratégias de segurança documentadas para isso.",2 +V15,Codificação e Arquitetura Segura,V15.2,Arquitetura de Segurança e Dependências,V15.2.3,"Verificar que o ambiente de produção inclui apenas funcionalidades necessárias para o funcionamento da aplicação, e não expõe funcionalidades desnecessárias como código de teste, trechos de exemplo e funcionalidades de desenvolvimento.",2 +V15,Codificação e Arquitetura Segura,V15.2,Arquitetura de Segurança e Dependências,V15.2.4,"Verificar que componentes de terceiros e todas as suas dependências transitivas são incluídos do repositório esperado, seja de propriedade interna ou de uma fonte externa, e que não há risco de um ataque de dependency confusion.",3 +V15,Codificação e Arquitetura Segura,V15.2,Arquitetura de Segurança e Dependências,V15.2.5,"Verificar que a aplicação implementa proteções adicionais em torno das partes da aplicação documentadas como contendo 'funcionalidade perigosa' ou que usam bibliotecas de terceiros consideradas 'componentes de risco'. Isso pode incluir técnicas como sandboxing, encapsulamento, containerização ou isolamento em nível de rede para retardar e deter atacantes que comprometam uma parte de uma aplicação de se mover lateralmente para outras partes.",3 +V15,Codificação e Arquitetura Segura,V15.3,Codificação Defensiva,V15.3.1,"Verificar que a aplicação retorna apenas o subconjunto necessário de campos de um objeto de dados. Por exemplo, não deve retornar um objeto de dados inteiro, pois alguns campos individuais não devem ser acessíveis aos usuários.",1 +V15,Codificação e Arquitetura Segura,V15.3,Codificação Defensiva,V15.3.2,"Verificar que, onde o backend da aplicação faz chamadas para URLs externas, ele está configurado para não seguir redirecionamentos a menos que seja uma funcionalidade pretendida.",2 +V15,Codificação e Arquitetura Segura,V15.3,Codificação Defensiva,V15.3.3,"Verificar que a aplicação tem contramedidas para proteger contra ataques de mass assignment, limitando os campos permitidos por controlador e ação — por exemplo, não é possível inserir ou atualizar um valor de campo quando não era pretendido que fizesse parte dessa ação.",2 +V15,Codificação e Arquitetura Segura,V15.3,Codificação Defensiva,V15.3.4,"Verificar que todos os componentes de proxy e middleware transferem corretamente o endereço IP original do usuário usando campos de dados confiáveis que não podem ser manipulados pelo usuário final, e que a aplicação e o servidor web usam esse valor correto para registro e decisões de segurança como limitação de taxa, levando em conta que mesmo o endereço IP original pode não ser confiável devido a IPs dinâmicos, VPNs ou firewalls corporativos.",2 +V15,Codificação e Arquitetura Segura,V15.3,Codificação Defensiva,V15.3.5,Verificar que a aplicação garante explicitamente que as variáveis são do tipo correto e realiza operações de igualdade e comparação estritas. Isso serve para evitar vulnerabilidades de type juggling ou type confusion causadas pelo código da aplicação assumindo um tipo de variável.,2 +V15,Codificação e Arquitetura Segura,V15.3,Codificação Defensiva,V15.3.6,"Verificar que o código JavaScript é escrito de forma a prevenir poluição de prototype, por exemplo, usando Set() ou Map() em vez de literais de objeto.",2 +V15,Codificação e Arquitetura Segura,V15.3,Codificação Defensiva,V15.3.7,"Verificar que a aplicação tem defesas contra ataques de poluição de parâmetro HTTP, especialmente se o framework da aplicação não faz distinção entre a fonte dos parâmetros de requisição (string de consulta, parâmetros do corpo, cookies ou campos de cabeçalho).",2 +V15,Codificação e Arquitetura Segura,V15.4,Concorrência Segura,V15.4.1,"Verificar que objetos compartilhados em código multithread (como caches, arquivos ou objetos na memória acessados por múltiplas threads) são acessados de forma segura usando tipos thread-safe e mecanismos de sincronização como locks ou semáforos, para evitar condições de corrida e corrupção de dados.",3 +V15,Codificação e Arquitetura Segura,V15.4,Concorrência Segura,V15.4.2,"Verificar que verificações sobre o estado de um recurso, como sua existência ou permissões, e as ações que dependem delas são realizadas como uma única operação atômica para prevenir condições de corrida de time-of-check to time-of-use (TOCTOU). Por exemplo, verificar se um arquivo existe antes de abri-lo ou verificar o acesso de um usuário antes de concedê-lo.",3 +V15,Codificação e Arquitetura Segura,V15.4,Concorrência Segura,V15.4.3,"Verificar que os locks são usados de forma consistente para evitar que threads fiquem presos, seja esperando uns pelos outros ou tentando repetidamente, e que a lógica de locking permanece no código responsável por gerenciar o recurso para garantir que os locks não possam ser inadvertida ou maliciosamente modificados por classes ou código externos.",3 +V15,Codificação e Arquitetura Segura,V15.4,Concorrência Segura,V15.4.4,"Verificar que as políticas de alocação de recursos previnem a starvation de threads garantindo acesso justo aos recursos, como usando pools de threads, permitindo que threads de menor prioridade prossigam dentro de um prazo razoável.",3 +V16,Registro de Segurança e Tratamento de Erros,V16.1,Documentação de Registro de Segurança,V16.1.1,"Verificar que existe um inventário documentando o registro realizado em cada camada da pilha de tecnologia da aplicação, quais eventos são registrados, formatos de log, onde esse registro é armazenado, como é usado, como o acesso a ele é controlado e por quanto tempo os logs são mantidos.",2 +V16,Registro de Segurança e Tratamento de Erros,V16.2,Registro Geral,V16.2.1,"Verificar que cada entrada de log inclui os metadados necessários (como quando, onde, quem, o quê) que permitiriam uma investigação detalhada da linha do tempo quando um evento ocorrer.",2 +V16,Registro de Segurança e Tratamento de Erros,V16.2,Registro Geral,V16.2.2,Verificar que as fontes de tempo para todos os componentes de registro estão sincronizadas e que os timestamps nos metadados de eventos de segurança usam UTC ou incluem um deslocamento de fuso horário explícito. UTC é recomendado para garantir consistência em sistemas distribuídos e prevenir confusão durante transições de horário de verão.,2 +V16,Registro de Segurança e Tratamento de Erros,V16.2,Registro Geral,V16.2.3,Verificar que a aplicação armazena ou transmite logs apenas para os arquivos e serviços documentados no inventário de logs.,2 +V16,Registro de Segurança e Tratamento de Erros,V16.2,Registro Geral,V16.2.4,"Verificar que os logs podem ser lidos e correlacionados pelo processador de log em uso, preferencialmente usando um formato de registro comum.",2 +V16,Registro de Segurança e Tratamento de Erros,V16.2,Registro Geral,V16.2.5,"Verificar que, ao registrar dados sensíveis, a aplicação aplica o registro com base no nível de proteção dos dados. Por exemplo, pode não ser permitido registrar certos dados, como credenciais ou detalhes de pagamento. Outros dados, como tokens de sessão, podem ser registrados apenas por meio de hash ou mascaramento, seja total ou parcialmente.",2 +V16,Registro de Segurança e Tratamento de Erros,V16.3,Eventos de Segurança,V16.3.1,"Verificar que todas as operações de autenticação são registradas, incluindo tentativas bem-sucedidas e fracassadas. Metadados adicionais, como o tipo de autenticação ou fatores usados, também devem ser coletados.",2 +V16,Registro de Segurança e Tratamento de Erros,V16.3,Eventos de Segurança,V16.3.2,"Verificar que tentativas de autorização falhas são registradas. Para L3, isso deve incluir o registro de todas as decisões de autorização, incluindo o registro de quando dados sensíveis são acessados (sem registrar os próprios dados sensíveis).",2 +V16,Registro de Segurança e Tratamento de Erros,V16.3,Eventos de Segurança,V16.3.3,"Verificar que a aplicação registra os eventos de segurança definidos na documentação e também registra tentativas de contornar os controles de segurança, como validação de entrada, lógica de negócio e anti-automação.",2 +V16,Registro de Segurança e Tratamento de Erros,V16.3,Eventos de Segurança,V16.3.4,"Verificar que a aplicação registra erros inesperados e falhas de controle de segurança, como falhas de TLS no backend.",2 +V16,Registro de Segurança e Tratamento de Erros,V16.4,Proteção de Logs,V16.4.1,Verificar que todos os componentes de registro codificam adequadamente os dados para prevenir injeção de log.,2 +V16,Registro de Segurança e Tratamento de Erros,V16.4,Proteção de Logs,V16.4.2,Verificar que os logs são protegidos contra acesso não autorizado e não podem ser modificados.,2 +V16,Registro de Segurança e Tratamento de Erros,V16.4,Proteção de Logs,V16.4.3,"Verificar que os logs são transmitidos de forma segura para um sistema logicamente separado para análise, detecção, alerta e escalação. O objetivo é garantir que, se a aplicação for comprometida, os logs não sejam comprometidos.",2 +V16,Registro de Segurança e Tratamento de Erros,V16.5,Tratamento de Erros,V16.5.1,"Verificar que uma mensagem genérica é retornada ao consumidor quando ocorre um erro inesperado ou sensível à segurança, garantindo que não haja exposição de dados internos sensíveis do sistema, como rastreamentos de pilha, consultas, chaves secretas e tokens.",2 +V16,Registro de Segurança e Tratamento de Erros,V16.5,Tratamento de Erros,V16.5.2,"Verificar que a aplicação continua a operar de forma segura quando o acesso a recursos externos falha, por exemplo, usando padrões como circuit breakers ou degradação graciosa.",2 +V16,Registro de Segurança e Tratamento de Erros,V16.5,Tratamento de Erros,V16.5.3,"Verificar que a aplicação falha de forma graciosa e segura, incluindo quando ocorre uma exceção, prevenindo condições de fail-open como processar uma transação apesar de erros resultantes da lógica de validação.",2 +V16,Registro de Segurança e Tratamento de Erros,V16.5,Tratamento de Erros,V16.5.4,"Verificar que um handler de erro 'de último recurso' é definido para capturar todas as exceções não tratadas. Isso serve tanto para evitar perder detalhes de erro que devem ir para arquivos de log quanto para garantir que um erro não derrube todo o processo da aplicação, levando a uma perda de disponibilidade.",3 +V17,WebRTC,V17.1,Servidor TURN,V17.1.1,"Verificar que o serviço de Traversal Using Relays around NAT (TURN) permite apenas acesso a endereços IP que não são reservados para fins especiais (por exemplo, redes internas, broadcast, loopback). Observar que isso se aplica tanto a endereços IPv4 quanto IPv6.",2 +V17,WebRTC,V17.1,Servidor TURN,V17.1.2,Verificar que o serviço de Traversal Using Relays around NAT (TURN) não é suscetível ao esgotamento de recursos quando usuários legítimos tentam abrir um grande número de portas no servidor TURN.,3 +V17,WebRTC,V17.2,Mídia,V17.2.1,Verificar que a chave para o certificado Datagram Transport Layer Security (DTLS) é gerenciada e protegida com base na política documentada de gerenciamento de chaves criptográficas.,2 +V17,WebRTC,V17.2,Mídia,V17.2.2,Verificar que o servidor de mídia está configurado para usar e suportar suítes de cifra DTLS (Datagram Transport Layer Security) aprovadas e um perfil de proteção seguro para a Extensão DTLS para estabelecimento de chaves para o Secure Real-time Transport Protocol (DTLS-SRTP).,2 +V17,WebRTC,V17.2,Mídia,V17.2.3,Verificar que a autenticação do Secure Real-time Transport Protocol (SRTP) é verificada no servidor de mídia para evitar que ataques de injeção de Real-time Transport Protocol (RTP) levem a uma condição de Negação de Serviço ou inserção de áudio ou vídeo nos fluxos de mídia.,2 +V17,WebRTC,V17.2,Mídia,V17.2.4,Verificar que o servidor de mídia é capaz de continuar processando tráfego de mídia recebido ao encontrar pacotes SRTP (Secure Real-time Transport Protocol) malformados.,2 +V17,WebRTC,V17.2,Mídia,V17.2.5,Verificar que o servidor de mídia é capaz de continuar processando tráfego de mídia recebido durante uma inundação de pacotes SRTP (Secure Real-time Transport Protocol) de usuários legítimos.,3 +V17,WebRTC,V17.2,Mídia,V17.2.6,"Verificar que o servidor de mídia não é suscetível à vulnerabilidade de Condição de Corrida 'ClientHello' no Datagram Transport Layer Security (DTLS), verificando se o servidor de mídia é publicamente conhecido por ser vulnerável ou realizando o teste de condição de corrida.",3 +V17,WebRTC,V17.2,Mídia,V17.2.7,Verificar que qualquer mecanismo de gravação de áudio ou vídeo associado ao servidor de mídia é capaz de continuar processando tráfego de mídia recebido durante uma inundação de pacotes SRTP (Secure Real-time Transport Protocol) de usuários legítimos.,3 +V17,WebRTC,V17.2,Mídia,V17.2.8,"Verificar que o certificado DTLS (Datagram Transport Layer Security) é verificado em relação ao atributo de fingerprint do Session Description Protocol (SDP), encerrando o fluxo de mídia se a verificação falhar, para garantir a autenticidade do fluxo de mídia.",3 +V17,WebRTC,V17.3,Sinalização,V17.3.1,Verificar que o servidor de sinalização é capaz de continuar processando mensagens de sinalização legítimas durante um ataque de inundação. Isso deve ser alcançado implementando limitação de taxa no nível de sinalização.,2 +V17,WebRTC,V17.3,Sinalização,V17.3.2,"Verificar que o servidor de sinalização é capaz de continuar processando mensagens de sinalização legítimas ao encontrar mensagens de sinalização malformadas que possam causar uma condição de negação de serviço. Isso pode incluir a implementação de validação de entrada, tratamento seguro de estouros de inteiros, prevenção de estouros de buffer e emprego de outras técnicas robustas de tratamento de erros.",2 diff --git a/5.0/pt/0x00-Header.yaml b/5.0/pt/0x00-Header.yaml new file mode 100644 index 0000000000..309d2b6f5d --- /dev/null +++ b/5.0/pt/0x00-Header.yaml @@ -0,0 +1,16 @@ +--- + title: "Application Security Verification Standard" + subtitle: "Version 5.0.0" + date: May 2025 + titlepage: true + titlepage-rule-height: 0 + titlepage-logo: "images/owasp_logo_1c_notext.png" + table-use-row-colors: true + toc: true + toc-own-page: true + geometry: "left=2cm,right=2cm,top=3cm,bottom=3cm" + CJKmainfont: "Noto Sans CJK JP" + mainfont: "Source Serif 4" + sansfont: "Source Sans 3" +--- + diff --git a/5.0/pt/0x01-Frontispiece.md b/5.0/pt/0x01-Frontispiece.md new file mode 100644 index 0000000000..b6ad6346a2 --- /dev/null +++ b/5.0/pt/0x01-Frontispiece.md @@ -0,0 +1,46 @@ +# Frontispiece + +## About the Standard + +The Application Security Verification Standard is a list of application security requirements that architects, developers, testers, security professionals, tool vendors, and consumers can use to define, build, test, and verify secure applications. + +## Copyright and License + +Version 5.0.0, May 2025 + +![license](../images/license.png) + +Copyright © 2008-2025 The OWASP Foundation. + +This document is released under the [Creative Commons Attribution-ShareAlike 4.0 International License](https://creativecommons.org/licenses/by-sa/4.0/). + +For any reuse or distribution, you must clearly communicate the license terms of this work to others. + +## Project Leads + +| | | +|---------------------- |----------------- | +| Elar Lang | Josh C Grossman | +| Jim Manico | Daniel Cuthbert | + +## Working Group + +| | | | | +|---------------- |------------------ |------------------- |----------------- | +| Tobias Ahnoff | Ralph Andalis | Ryan Armstrong | Gabriel Corona | +| Meghan Jacquot | Shanni Prutchi | Iman Sharafaldin | Eden Yardeni | + +## Other Major Contributors + +| | | +|-------------------|-------------------| +| Sjoerd Langkemper | Isaac Lewis | +| Mark Carney | Sandro Gauci | + +## Other Contributors and Reviewers + +We have included a list of the other contributors in Appendix E. + +If a credit is missing from the 5.x credit list, please log a ticket at GitHub to be recognized in future 5.x updates. + +The Application Security Verification Standard builds on the work of those involved in ASVS 1.0 (2008) through 4.0 (2019). Much of the structure and many of the verification items that remain in ASVS today were originally written by Andrew van der Stock, Mike Boberski, Jeff Williams, and Dave Wichers, among numerous other contributors. Thank you to everyone who has contributed in the past. For a comprehensive list of earlier contributors, please consult each prior version. diff --git a/5.0/pt/0x02-Preface.md b/5.0/pt/0x02-Preface.md new file mode 100644 index 0000000000..4c0b8d3764 --- /dev/null +++ b/5.0/pt/0x02-Preface.md @@ -0,0 +1,29 @@ +# Preface + +Welcome to the Application Security Verification Standard (ASVS) Version 5.0. + +## Introduction + +Originally launched in 2008 through a global community collaboration, the ASVS defines a comprehensive set of security requirements for designing, developing, and testing modern web applications and services. + +Following the release of ASVS 4.0 in 2019 and its minor update (v4.0.3) in 2021, Version 5.0 represents a significant milestone—modernized to reflect the latest advances in software security. + +ASVS 5.0 is the result of extensive contributions from project leaders, working group members, and the wider OWASP community to update and improve this important standard. + +## Principles behind version 5.0 + +This major revision has been developed with several key principles in mind: + +* Refined Scope and Focus: This version of the standard has been designed to align more directly with the foundational pillars in its name: Application, Security, Verification, and Standard. Requirements have been rewritten to emphasize the prevention of security flaws rather than mandating specific technical implementations. Requirement texts are intended to be self-explanatory, explaining why they exist. + +* Support for Documented Security Decisions: ASVS 5.0 introduces requirements for documenting key security decisions. This enhances traceability and supports context-sensitive implementations, allowing organizations to tailor their security posture to their specific needs and risks. + +* Updated Levels: While ASVS retains its three-tier model, the level definitions have evolved to make the ASVS easier to adopt. Level 1 is designed as the initial step to adopting the ASVS, providing the first layer of defense. Level 2 represents a comprehensive view of standard security practices, and Level 3 addresses advanced, high-assurance requirements. + +* Restructured and Expanded Content: ASVS 5.0 includes approximately 350 requirements across 17 chapters. Chapters have been reorganized for clarity and usability. A two-way mapping between v4.0 and v5.0 is provided to facilitate migration. + +## Looking ahead + +Just as securing an application is never truly finished, neither is the ASVS. Although Version 5.0 is a major release, development continues. This release allows the wider community to benefit from the improvements and additions which have been accumulated but also lays the groundwork for future enhancements. This could include community-driven efforts to create implementation and verification guidance built on top of the core requirement set. + +ASVS 5.0 is designed to serve as a reliable foundation for secure software development. The community is invited to adopt, contribute, and build upon this standard to collectively advance the state of application security. diff --git a/5.0/pt/0x03-What-is-the-ASVS.md b/5.0/pt/0x03-What-is-the-ASVS.md new file mode 100644 index 0000000000..925ecb33b6 --- /dev/null +++ b/5.0/pt/0x03-What-is-the-ASVS.md @@ -0,0 +1,195 @@ +# What is the ASVS? + +The Application Security Verification Standard (ASVS) defines security requirements for web applications and services, and it is a valuable resource for anyone aiming to design, develop, and maintain secure applications or evaluate their security. + +This chapter outlines the essential aspects of using the ASVS, including its scope, the structure of its priority-based levels, and the primary use cases for the standard. + +## Scope of the ASVS + +The scope of the ASVS is defined by its name: Application, Security, Verification, and Standard. It establishes which requirements are included or excluded, with the overarching goal of identifying the security principles that must be achieved. The scope also considers documentation requirements, which serve as the foundation for implementation requirements. + +There is no such thing as scope for attackers. Therefore, ASVS requirements should be evaluated alongside guidance for other aspects of the application lifecycle, including CI/CD processes, hosting, and operational activities. + +### Application + +ASVS defines an "application" as the software product being developed, into which security controls must be integrated. ASVS does not prescribe development lifecycle activities or dictate how the application should be built via a CI/CD pipeline; instead, it specifies the security outcomes that must be achieved within the product itself. + +Components that serve, modify, or validate HTTP traffic, such as Web Application Firewalls (WAFs), load balancers, or proxies, may be considered part of the application for those specific purposes, as some security controls depend directly on them or can be implemented through them. These components should be considered for requirements related to cached responses, rate limiting, or restricting incoming and outgoing connections based on source and destination. + +Conversely, ASVS generally excludes requirements that are not directly relevant to the application or where configuration is outside the application's responsibility. For example, DNS issues are typically managed by a separate team or function. + +Similarly, while the application is responsible for how it consumes input and produces output, if an external process interacts with the application or its data, it is considered out of scope for ASVS. For instance, backing up the application or its data is usually the responsibility of an external process and is not controlled by the application or its developers. + +### Security + +Every requirement must have a demonstrable impact on security. The absence of a requirement must result in a less secure application, and implementing the requirement must reduce either the likelihood or the impact of a security risk. + +All other considerations, such as functional aspects, code style, or policy requirements, are out of scope. + +### Verification + +The requirement must be verifiable, and the verification must result in a "fail" or "pass" decision. + +### Standard + +The ASVS is designed to be a collection of security requirements to be implemented to comply with the standard. This means that requirements are limited to defining the security goal to achieve that. Other related information can be built on top of ASVS or linked via mappings. + +Specifically, OWASP has many projects, and the ASVS deliberately avoids overlapping with the content in other projects. For example, developers may have a question, "how do I implement a particular requirement in my particular technology or environment," and this should be covered by the Cheat Sheet Series project. Verifiers may have a question "how do I test this requirement in this environment," and this should be covered by the Web Security Testing Guide project. + +Whilst the ASVS is not just intended for security experts to use, it does expect the reader to have technical knowledge to understand the content or the ability to research particular concepts. + +### Requirement + +The word requirement is used specifically in the ASVS as it describes what must be achieved to satisfy it. The ASVS only contains requirements (must) and does not contain recommendations (should) as the main condition. + +In other words, recommendations, whether they are just one of many possible options to solve a problem or code style considerations, do not satisfy the definition to be a requirement. + +ASVS requirements are intended to address specific security principles without being too implementation or technology-specific, at the same time, being self-explanatory as to why they exist. This also means that requirements are not built around a particular verification method or implementation. + +### Documented security decisions + +In software security, planning security design and the mechanisms to be used early on will lead to a more consistent and reliable implementation in the finished product or feature. + +Additionally, for certain requirements, implementation will be complicated and very specific to an application's needs. Common examples include permissions, input validation, and protective controls around different levels of sensitive data. + +To account for this, rather than sweeping statements like "all data must be encrypted" or trying to cover every possible use case in a requirement, documentation requirements were included which mandate that the application developer's approach and configuration to these sorts of controls must be documented. This can then be reviewed for appropriateness and then the actual implementation can be compared to the documentation to assess whether the implementation matches expectations. + +These requirements are intended to document the decisions which the organization developing the application has taken regarding how to implement certain security requirements. + +Documentation requirements are always in the first section of a chapter (although not every chapter has them) and always have a related implementation requirement where the decisions that are documented should actually be put into place. The point here is that verifying that the documentation is in place and that the actual implementation are two separate activities. + +There are two key drivers for including these requirements. The first driver is that a security requirement will often involve enforcing rules e.g., what kind of file types are allowed to be uploaded, what business controls should be enforced, what are the allowed characters for a particular field. These rules will differ for every application, and therefore, the ASVS cannot prescriptively define what they should be, nor will a cheat sheet or more detailed response help in this case. Similarly, without these decisions being documented, it will not be possible to perform verification of the requirements that implement these decisions. + +The second driver is that for certain requirements, it is important to provide an application development with flexibility regarding how to address particular security challenges. For example, in previous ASVS versions, session timeout rules were very prescriptive. Practically speaking, many applications, especially those that are consumer-facing, have much more relaxed rules and prefer to implement other mitigation controls instead. Documentation requirements, therefore, explicitly allow for flexibility around this. + +Clearly, it is not expected that individual developers will be making and documenting these decisions but rather the organization as a whole will be taking those decisions and making sure that they are communicated to developers who then make sure to follow them. + +Providing developers with specifications and designs for new features and functionality is a standard part of software development. Similarly, developers are expected to use common components and user interface mechanisms rather than just making their own decisions each time. As such, extending this to security should not be seen as surprising or controversial. + +There is also flexibility around how to achieve this. Security decisions might be documented in a literal document, which developers are expected to refer to. Alternatively, security decisions could be documented and implemented in a common code library that all developers are mandated to use. In both cases, the desired result is achieved. + +## Application Security Verification Levels + +The ASVS defines three security verification levels, with each level increasing in depth and complexity. The general aim is for organizations to start with the first level to address the most critical security concerns, and then move up to the higher levels according to the organization and application needs. Levels may be presented as L1, L2, and L3 in the document and in requirement texts. + +Each ASVS level indicates the security requirements that are required to achieve from that level, with the higher remaining level requirements as recommendations. + +In order to avoid duplicate requirements or requirements that are no longer relevant at higher levels, some requirements apply to a particular level but have more stringent conditions for higher levels. + +### Level evaluation + +Levels are defined by priority-based evaluation of each requirement based on experience implementing and testing security requirements. The main focus is on comparing risk reduction with the effort to implement the requirement. Another key factor is to keep a low barrier to entry. + +Risk reduction considers the extent to which the requirement reduces the level of security risk within the application, taking into account the classic Confidentiality, Integrity, and Availability impact factors as well as considering whether this is a primary layer of defense or whether it would be considered defense in depth. + +The rigorous discussions around both the criteria and the leveling decisions have resulted in an allocation which should hold true for the vast majority of cases, whilst accepting that it may not be a 100% fit for every situation. This means that in certain cases, organizations may wish to prioritize requirements from a higher level earlier on based on their own specific risk considerations. + +The types of requirements in each level could be characterized as follows. + +### Level 1 + +This level contains the minimum requirements to consider when securing an application and represents a critical starting point. This level contains around 20% of the ASVS requirements. The goal for this level is to have as few requirements as possible, to decrease the barrier to entry. + +These requirements are generally critical or basic, first-layer of defense requirements for preventing common attacks that do not require other vulnerabilities or preconditions to be exploitable. + +In addition to the first layer of defense requirements, some requirements have less of an impact at higher levels, such as requirements related to passwords. Those are more important for Level 1, as from higher levels, the multi-factor authentication requirements become relevant. + +Level 1 is not necessarily penetration testable by an external tester without internal access to documentation or code (such as "black box" testing), although the lower number of requirements should make it easier to verify. + +### Level 2 + +Most applications should be striving to achieve this level of security. Around 50% of the requirements in the ASVS are L2 meaning that an application needs to implement around 70% of the requirements in the ASVS (all of the L1 and L2 requirements) in order to comply with L2. + +These requirements generally relate to either less common attacks or more complicated protections against common attacks. They may still be a first layer of defense, or they may require certain preconditions for the attack to be successful. + +### Level 3 + +This level should be the goal for applications looking to demonstrate the highest levels of security and provides the final ~30% of requirements to comply with. + +Requirements in this section are generally either defense-in-depth mechanisms or other useful but hard-to-implement controls. + +### Which level to achieve + +The priority-based levels are intended to provide a reflection of the application security maturity of the organization and the application. Rather than the ASVS prescriptively stating what level an application should be at, an organization should analyze its risks and decide what level it believes it should be at, depending on the sensitivity of the application and of course, the expectations of the application's users. + +For example, an early-stage startup that is only collecting limited sensitive data may decide to focus on Level 1 for its initial security goals, but a bank may have difficulty justifying anything less than Level 3 to its customers for its online banking application. + +## How to use the ASVS + +### The structure of the ASVS + +The ASVS is made up of a total of around 350 requirements which are divided into 17 chapters, each of which is further divided into sections. + +The aim of the chapter and section division is to simplify choosing or filtering out chapters and sections based on the what is relevant for the application. For example, for a machine-to-machine API, the requirements in chapter V3 related to web frontends will not be relevant. If there is no use of OAuth or WebRTC, then those chapters can be ignored as well. + +### Release strategy + +ASVS releases follow the pattern "Major.Minor.Patch" and the numbers provide information on what has changed within the release. In a major release, the first number will change, in a minor release, the second number will change, and in a patch release, the third number will change. + +* Major release - Full reorganization, almost everything may have changed, including requirement numbers. Reevaluation for compliance will be necessary (for example, 4.0.3 -> 5.0.0). +* Minor release - Requirements may be added or removed, but overall numbering will stay the same. Reevaluation for compliance will be necessary, but should be easier (for example, 5.0.0 -> 5.1.0). +* Patch release - Requirements may be removed (for example, if they are duplicates or outdated) or made less stringent, but an application that complied with the previous release will comply with the patch release as well (for example, 5.0.0 -> 5.0.1). + +The above specifically relates to the requirements in the ASVS. Changes to surrounding text and other content such as the appendices will not be considered to be a breaking change. + +### Flexibility with the ASVS + +Several of the points described above, such as documentation requirements and the levels mechanism, provide the ability to use the ASVS in a more flexible and organization-specific way. + +Additionally, organizations are strongly encouraged to create an organization- or domain-specific fork that adjusts requirements based on the specific characteristics and risk levels of their applications. However, it is important to maintain traceability so that passing requirement 4.1.1 means the same across all versions. + +Ideally, each organization should create its own tailored ASVS, omitting irrelevant sections (e.g., GraphQL, WebSockets, SOAP, if unused). An organization-specific ASVS version or supplement is also a good place to provide organization-specific implementation guidance, detailing libraries or resources to use when complying with requirements. + +### How to Reference ASVS Requirements + +Each requirement has an identifier in the format `.
.`, where each element is a number. For example, `1.11.3`. + +* The `` value corresponds to the chapter from which the requirement comes; for example, all `1.#.#` requirements are from the 'Encoding and Sanitization' chapter. +* The `
` value corresponds to the section within that chapter where the requirement appears, for example: all `1.2.#` requirements are in the 'Injection Prevention' section of the 'Encoding and Sanitization' chapter. +* The `` value identifies the specific requirement within the chapter and section, for example, `1.2.5` which as of version 5.0.0 of this standard is: + +> Verify that the application protects against OS command injection and that operating system calls use parameterized OS queries or use contextual command line output encoding. + +Since the identifiers may change between versions of the standard, it is preferable for other documents, reports, or tools to use the following format: `v-.
.`, where: 'version' is the ASVS version tag. For example: `v5.0.0-1.2.5` would be understood to mean specifically the 5th requirement in the 'Injection Prevention' section of the 'Encoding and Sanitization' chapter from version 5.0.0. (This could be summarized as `v-`.) + +Note: The `v` preceding the version number in the format should always be lowercase. + +If identifiers are used without including the `v` element then they should be assumed to refer to the latest Application Security Verification Standard content. As the standard grows and changes this becomes problematic, which is why writers or developers should include the version element. + +ASVS requirement lists are made available in CSV, JSON, and other formats which may be useful for reference or programmatic use. + +### Forking the ASVS + +Organizations can benefit from adopting ASVS by choosing one of the three levels or by creating a domain-specific fork that adjusts requirements per application risk level. This type of fork is encouraged, provided that it maintains traceability so that passing requirement 4.1.1 means the same across all versions. + +Ideally, each organization should create its own tailored ASVS, omitting irrelevant sections (e.g., GraphQL, Websockets, SOAP, if unused). Forking should start with ASVS Level 1 as a baseline, advancing to Levels 2 or 3 based on the application’s risk. + +## Use cases for the ASVS + +The ASVS can be used to assess the security of an application and this is explored in more depth in the next chapter. However, several other potential uses for the ASVS (or a forked version) have been identified. + +### As Detailed Security Architecture Guidance + +One of the more common uses for the Application Security Verification Standard is as a resource for security architects. There are limited resources available for how to build a secure application archiecture, especially with modern applications. ASVS can be used to fill in those gaps by allowing security architects to choose better controls for common problems, such as data protection patterns and input validation strategies. The architecture and documentation requirements will be particularly useful for this. + +### As a Specialized Secure Coding Reference + +The ASVS can be used as a basis for preparing a secure coding reference during application development, helping developers to make sure that they keep security in mind when they build software. Whilst the ASVS can be the base, prganizations should prepare their own specific guidance which is clear and unified and ideally be prepared based on guidance from security engineers or security architects. As an extension to this, organizations are encouraged wherever possible to prepare approved security mechanisms and libraries that can be referenced in the guidance and used by developers. + +### As a Guide for Automated Unit and Integration Tests + +The ASVS is designed to be highly testable. Some verifications will be technical where as other requirements (such as the architectural and documentation requirements) may require documentation or architecture review. By building unit and integration tests that test and fuzz for specific and relevant abuse cases related to the requirements that are verifiable by technical means, it should be easier to check that these controls are operating correctly on each build. For example, additional tests can be crafted for the test suite for a login controller, testing the username parameter for common default usernames, account enumeration, brute forcing, LDAP and SQL injection, and XSS. Similarly, a test on the password parameter should include common passwords, password length, null byte injection, removing the parameter, XSS, and more. + +### For Secure Development Training + +ASVS can also be used to define the characteristics of secure software. Many “secure coding” courses are simply ethical hacking courses with a light smear of coding tips. This may not necessarily help developers to write more secure code. Instead, secure development courses can use the ASVS with a strong focus on the positive mechanisms found in the ASVS, rather than the Top 10 negative things not to do. The ASVS structure also provides a logical structure for walking through the different topics when securing an application. + +### As a Framework for Guiding the Procurement of Secure Software + +The ASVS is a great framework to help with secure software procurement or procurement of custom development services. The buyer can simply set a requirement that the software they wish to procure must be developed at ASVS level X, and request that the seller proves that the software satisfies ASVS level X. + +## Applying ASVS in Practice + +Different threats have different motivations. Some industries have unique information and technology assets and domain-specific regulatory compliance requirements. + +Organizations are strongly encouraged to look deeply at their unique risk characteristics based on the nature of their business, and based upon that risk and business requirements determine the appropriate ASVS level. diff --git a/5.0/pt/0x04-Assessment_and_Certification.md b/5.0/pt/0x04-Assessment_and_Certification.md new file mode 100644 index 0000000000..da84e85661 --- /dev/null +++ b/5.0/pt/0x04-Assessment_and_Certification.md @@ -0,0 +1,47 @@ +# Assessment and Certification + +## OWASP's Stance on ASVS Certifications and Trust Marks + +OWASP, as a vendor-neutral nonprofit, does not certify any vendors, verifiers, or software. Any assurance, trust mark, or certification claiming ASVS compliance is not officially endorsed by OWASP, so organizations should be cautious of third-party claims of ASVS certification. + +Organizations may offer assurance services, provided they do not claim official OWASP certification. + +## How to Verify ASVS Compliance + +The ASVS is deliberately not presciptive about exactly how to verify compliance at the level of a testing guide. However, it is important to highlight some key points. + +### Verification reporting + +Traditional penetration testing reports issues “by exception,” only listing failures. However, an ASVS certification report should include scope, a summary of all requirements checked, the requirements where execptions were noted, and guidance on resolving issues. Some requirements may be non-applicable (e.g., session management in stateless APIs), and this must be noted in the report. + +### Scope of Verification + +An organization developing an application will generally not implement all requirements, as some may be irrelevant or less significant based on the functionality of the application. The verifier should make the scope of the verification clear including which Level the organization is attempting to achieve and which requirements were included. This should be from the perspective of what was included rather than what was not included. They should also provide an opinion on the rationale of excluding the requirements which haven't been implemented. + +This should allow the consumer of a verification report to understand the context of the verification and make an informed decision about the level of trust they can place in the application. + +Certifying organizations can choose their testing methods but should disclose them in the report and this should ideally be repeatable. Different methods, like manual penetration tests or source code analysis, may be used to verify aspects such as input validation, depending on the application and requirements. + +### Verification Mechanisms + +There are a number of different techniques which may be needed to verify specific ASVS requirements. Aside from penetration testing (using valid credentials to get full application coverage), verifying ASVS requirements may require access to documentation, source code, configuration, and the people involved in the development process. Especially for verifying L2 and L3 requirements. It is standard practice to provide robust evidence of findings with detailed documentation, which may include work papers, screenshots, scripts, and testing logs. Merely running an automated tool without thorough testing is insufficient for certification, as each requirement must be verifiably tested. + +The use of automation to verify ASVS requirements is a topic that is constantly of interest. It is therefore important to clarify some points related to automated and black box testing. + +#### The Role of Automated Security Testing Tools + +When automated security testing tools such as Dynamic and Static Application Security Testing tools (DAST and SAST) are correctly implemented in the build pipeline, they may be able to identify some security issues that should never exist. However, without careful configuration and tuning they will not provide the required coverage and the level of noise will prevent real security issues from being identified and mitigated. + +Whilst this may provide coverage of some of the more basic and straightforward technical requirements such as those relating to output encoding or sanitiation, it is critical to note that these tools will be unable entirely to verify many of the more complicated ASVS requirements or those that relate to business logic and access control. + +For less straightforward requirements, it is likely that automation can still be utilized but application specific verifications will need to be written to achieve this. These may be similar to unit and integration tests that the organization may already be using. It may therefore be possible to use this existing test automation infrastructure to write these ASVS specific tests. Whilst doing this will require short term investment, the long term benefits being able to continually verify these ASVS requirements will be significant. + +In summary, testable using automation != running an off the shelf tool. + +#### The Role of Penetration Testing + +Whilst L1 in version 4.0 was optimized for "black box" (no documentation and no source) testing to occur, even then the standard was clear that it is not an effective assurance activity and should be actively discouraged. + +Testing without access to necessary additional information is an inefficient and ineffective mechanism for security verification, as it misses out on the possibility of reviewing the source, identifying threats and missing controls, and performing a far more thorough test in a shorter timeframe. + +It is strongly encouraged to perform documentation or source code-led (hybrid) penetration testing, which have full access to the application developers and the application's documentation, rather than traditional penetration tests. This will certainly be necessary in order to verify many of the ASVS requirements. diff --git a/5.0/pt/0x05-For-Users-Of-4.0.md b/5.0/pt/0x05-For-Users-Of-4.0.md new file mode 100644 index 0000000000..281d61a775 --- /dev/null +++ b/5.0/pt/0x05-For-Users-Of-4.0.md @@ -0,0 +1,90 @@ +# Changes Compared to v4.x + +## Introduction + +Users familiar with version 4.x of the standard may find it helpful to review the key changes introduced in version 5.0, including updates in content, scope, and underlying philosophy. + +Of the 286 requirements in version 4.0.3, only 11 remain unchanged, while 15 have undergone minor grammatical adjustments without altering their meaning. In total 109 requirements (38%) are no longer separate requirements in version 5.0 with 50 simply being deleted, 28 removed as duplicates and 31 merged into other requirements. The rest have been revised in some way. Even requirements that were not substantively modified have different identifiers due to reordering or restructuring. + +To facilitate adoption of version 5.0, mapping documents are provided to help users trace how requirements from version 4.x correspond to those in version 5.0. These mappings are not tied to release versioning and may be updated or clarified as needed. + +## Requirement Philosophy + +### Scope and Focus + +Version 4.x included requirements that did not align with the intended scope of the standard; these have been removed. Requirements that did not meet the scope criteria for 5.0 or were not verifiable have also been excluded. + +### Emphasis on Security Goals Over Mechanisms + +In version 4.x, many requirements focused on specific mechanisms rather than the underlying security objectives. In version 5.0, requirements are centered on security goals, referencing particular mechanisms only when they are the sole practical solution, or providing them as examples or supplementary guidance. + +This approach recognizes that multiple methods may exist to achieve a given security objective, and avoids unnecessary prescriptiveness that could limit organizational flexibility. + +Additionally, requirements addressing the same security concern have been consolidated where appropriate. + +### Documented Security Decisions + +While the concept of documented security decisions may appear new in version 5.0, it is an evolution of earlier requirements related to policy application and threat modeling in version 4.0. Previously, some requirements implicitly demanded analysis to inform the implementation of security controls, such as determining permitted network connections. + +To ensure that necessary information is available for implementation and verification, these expectations are now explicitly defined as documentation requirements, making them clear, actionable, and verifiable. + +## Structural Changes and New Chapters + +Several chapters in version 5.0 introduce entirely new content: + +* OAuth and OIDC – Given the widespread adoption of these protocols for access delegation and single sign-on, dedicated requirements have been added to address the diverse scenarios developers may encounter. This area may eventually evolve into a standalone standard, similar to the treatment of Mobile and IoT requirements in previous versions. +* WebRTC – As this technology gains popularity, its unique security considerations and challenges are now addressed in a dedicated section. + +Efforts have also been made to ensure that chapters and sections are organized around coherent sets of related requirements. + +This restructuring has led to the creation of additional chapters: + +* Self-contained Tokens – Formerly grouped under session management, self-contained tokens are now recognized as a distinct mechanism and a foundational element for stateless communication (such as in OAuth and OIDC). Due to their unique security implications, they are addressed in a dedicated chapter, with some new requirements introduced in version 5.x. +* Web Frontend Security – With the increasing complexity of browser-based applications and the rise of API-only architectures, frontend security requirements have been separated into their own chapter. +* Secure Coding and Architecture – New requirements addressing general security practices that did not fit within existing chapters have been grouped here. + +Other organizational changes in version 5.0 were made to clarify intent. For example, input validation requirements were moved alongside business logic, reflecting their role in enforcing business rules, rather than being grouped with sanitization and encoding. + +The former V1 Architecture chapter has been removed. Its initial section contained requirements that were out of scope, while subsequent sections have been redistributed to relevant chapters, with requirements deduplicated and clarified as necessary. + +## Removal of Direct Mappings to Other Standards + +Direct mappings to other standards have been removed from the main body of the standard. The aim is to prepare a mapping with the OWASP Common Requirement Enumeration (CRE) project, which in turn will link ASVS to a range of OWASP projects and external standards. + +Direct mappings to CWE and NIST are no longer maintained, as explained below. + +### Reduced Coupling with NIST Digital Identity Guidelines + +The NIST [Digital Identity Guidelines (SP 800-63)](https://pages.nist.gov/800-63-3/) have long served as a reference for authentication and authorization controls. In version 4.x, certain chapters were closely aligned with NIST's structure and terminology. + +While these guidelines remain an important reference, strict alignment introduced challenges, including less widely recognized terminology, duplication of similar requirements, and incomplete mappings. Version 5.0 moves away from this approach to improve clarity and relevance. + +### Moving Away from Common Weakness Enumeration (CWE) + +The [Common Weakness Enumeration (CWE)](https://cwe.mitre.org/) provides a useful taxonomy of software security weaknesses. However, challenges such as category-only CWEs, difficulties in mapping requirements to a single CWE, and the presence of imprecise mappings in version 4.x have led to the decision to discontinue direct CWE mappings in version 5.0. + +## Rethinking Level Definitions + +Version 4.x described the levels as L1 ("Minimum"), L2 ("Standard"), and L3 ("Advanced"), with the implication that all applications handling sensitive data should meet at least L2. + +Version 5.0 addresses several issues with this approach which are described in the following paragraphs. + +As a practical matter, whereas version 4.x used tick marks for level indicators, 5.x uses a simple number on all formats of the standard including markdown, PDF, DOCX, CSV, JSON and XML. For backwards compatibility, legacy versions of the CSV, JSON and XML outputs which still use tick marks are also generated. + +### Easier Entry Level + +Feedback indicated that the large number of Level 1 requirements (~120), combined with its designation as the "minimum" level that is not good enough for most applications, discouraged adoption. Version 5.0 aims to lower this barrier by defining Level 1 primarily around first-layer defense requirements, resulting in clearer and fewer requirements at that level. To demonstrate this numerically, in v4.0.3 there were 128 L1 requirements out of a total of 278 requirements, representing 46%. In 5.0.0 there are 70 L1 requirements out of a total of 345 requirements, representing 20%. + +### The Fallacy of Testability + +A key factor in selecting controls for Level 1 in version 4.x was their suitability for assessment through "black box" external penetration testing. However, this approach was not fully aligned with the intent of Level 1 as the minimum set of security controls. Some users argued that Level 1 was insufficient for securing applications, while others found it too difficult to test. + +Relying on testability as a criterion is both relative and, at times, misleading. The fact that a requirement is testable does not guarantee that it can be tested in an automated or straightforward manner. Moreover, the most easily testable requirements are not always those with the greatest security impact or the simplest to implement. + +As such, in version 5.0, the level decisions were made primarily based on risk reduction and also keeping in mind the effort to implement. + +### Not Just About Risk + +The use of prescriptive, risk-based levels that mandate a specific level for certain applications has proven to be overly rigid. In practice, the prioritization and implementation of security controls depend on multiple factors, including both risk reduction and the effort required for implementation. + +Therefore, organizations are encouraged to achieve the level that they feel like they should be achieving based on their maturity and the message they want to send to their users. diff --git a/5.0/pt/0x10-V1-Encoding-and-Sanitization.md b/5.0/pt/0x10-V1-Encoding-and-Sanitization.md new file mode 100644 index 0000000000..2a85c33148 --- /dev/null +++ b/5.0/pt/0x10-V1-Encoding-and-Sanitization.md @@ -0,0 +1,103 @@ +# V1 Encoding and Sanitization + +## Control Objective + +This chapter addresses the most common web application security weaknesses related to the unsafe processing of untrusted data. Such weaknesses can result in various technical vulnerabilities, where untrusted data is interpreted according to the syntax rules of the relevant interpreter. + +For modern web applications, it is always best to use safer APIs, such as parameterized queries, auto-escaping, or templating frameworks. Otherwise, carefully performed output encoding, escaping, or sanitization becomes critical to the application's security. + +Input validation serves as a defense-in-depth mechanism to protect against unexpected or dangerous content. However, since its primary purpose is to ensure that incoming content matches functional and business expectations, requirements related to this can be found in the "Validation and Business Logic" chapter. + +## V1.1 Encoding and Sanitization Architecture + +In the sections below, syntax-specific or interpreter-specific requirements for safely processing unsafe content to avoid security vulnerabilities are provided. The requirements in this section cover the order in which this processing should occur and where it should take place. They also aim to ensure that whenever data is stored, it remains in its original state and is not stored in an encoded or escaped form (e.g., HTML encoding), to prevent double encoding issues. + +| # | Description | Level | +| :---: | :--- | :---: | +| **1.1.1** | Verify that input is decoded or unescaped into a canonical form only once, it is only decoded when encoded data in that form is expected, and that this is done before processing the input further, for example it is not performed after input validation or sanitization. | 2 | +| **1.1.2** | Verify that the application performs output encoding and escaping either as a final step before being used by the interpreter for which it is intended or by the interpreter itself. | 2 | + +## V1.2 Injection Prevention + +Output encoding or escaping, performed close to or adjacent to a potentially dangerous context, is critical to the security of any application. Typically, output encoding and escaping are not persisted, but are instead used to render output safe for immediate use in the appropriate interpreter. Attempting to perform this too early may result in malformed content or render the encoding or escaping ineffective. + +In many cases, software libraries include safe or safer functions that perform this automatically, although it is necessary to ensure that they are correct for the current context. + +| # | Description | Level | +| :---: | :--- | :---: | +| **1.2.1** | Verify that output encoding for an HTTP response, HTML document, or XML document is relevant for the context required, such as encoding the relevant characters for HTML elements, HTML attributes, HTML comments, CSS, or HTTP header fields, to avoid changing the message or document structure. | 1 | +| **1.2.2** | Verify that when dynamically building URLs, untrusted data is encoded according to its context (e.g., URL encoding or base64url encoding for query or path parameters). Ensure that only safe URL protocols are permitted (e.g., disallow javascript: or data:). | 1 | +| **1.2.3** | Verify that output encoding or escaping is used when dynamically building JavaScript content (including JSON), to avoid changing the message or document structure (to avoid JavaScript and JSON injection). | 1 | +| **1.2.4** | Verify that data selection or database queries (e.g., SQL, HQL, NoSQL, Cypher) use parameterized queries, ORMs, entity frameworks, or are otherwise protected from SQL Injection and other database injection attacks. This is also relevant when writing stored procedures. | 1 | +| **1.2.5** | Verify that the application protects against OS command injection and that operating system calls use parameterized OS queries or use contextual command line output encoding. | 1 | +| **1.2.6** | Verify that the application protects against LDAP injection vulnerabilities, or that specific security controls to prevent LDAP injection have been implemented. | 2 | +| **1.2.7** | Verify that the application is protected against XPath injection attacks by using query parameterization or precompiled queries. | 2 | +| **1.2.8** | Verify that LaTeX processors are configured securely (such as not using the "--shell-escape" flag) and an allowlist of commands is used to prevent LaTeX injection attacks. | 2 | +| **1.2.9** | Verify that the application escapes special characters in regular expressions (typically using a backslash) to prevent them from being misinterpreted as metacharacters. | 2 | +| **1.2.10** | Verify that the application is protected against CSV and Formula Injection. The application must follow the escaping rules defined in RFC 4180 sections 2.6 and 2.7 when exporting CSV content. Additionally, when exporting to CSV or other spreadsheet formats (such as XLS, XLSX, or ODF), special characters (including '=', '+', '-', '@', '\t' (tab), and '\0' (null character)) must be escaped with a single quote if they appear as the first character in a field value. | 3 | + +Note: Using parameterized queries or escaping SQL is not always sufficient. Query parts such as table and column names (including "ORDER BY" column names) cannot be escaped. Including escaped user-supplied data in these fields results in failed queries or SQL injection. + +## V1.3 Sanitization + +The ideal protection against using untrusted content in an unsafe context is to use context-specific encoding or escaping, which maintains the same semantic meaning of the unsafe content but renders it safe for use in that particular context, as discussed in more detail in the previous section. + +Where this is not possible, sanitization becomes necessary, removing potentially dangerous characters or content. In some cases, this may change the semantic meaning of the input, but for security reasons, there may be no alternative. + +| # | Description | Level | +| :---: | :--- | :---: | +| **1.3.1** | Verify that all untrusted HTML input from WYSIWYG editors or similar is sanitized using a well-known and secure HTML sanitization library or framework feature. | 1 | +| **1.3.2** | Verify that the application avoids the use of eval() or other dynamic code execution features such as Spring Expression Language (SpEL). Where there is no alternative, any user input being included must be sanitized before being executed. | 1 | +| **1.3.3** | Verify that data being passed to a potentially dangerous context is sanitized beforehand to enforce safety measures, such as only allowing characters which are safe for this context and trimming input which is too long. | 2 | +| **1.3.4** | Verify that user-supplied Scalable Vector Graphics (SVG) scriptable content is validated or sanitized to contain only tags and attributes (such as draw graphics) that are safe for the application, e.g., do not contain scripts and foreignObject. | 2 | +| **1.3.5** | Verify that the application sanitizes or disables user-supplied scriptable or expression template language content, such as Markdown, CSS or XSL stylesheets, BBCode, or similar. | 2 | +| **1.3.6** | Verify that the application protects against Server-side Request Forgery (SSRF) attacks, by validating untrusted data against an allowlist of protocols, domains, paths and ports and sanitizing potentially dangerous characters before using the data to call another service. | 2 | +| **1.3.7** | Verify that the application protects against template injection attacks by not allowing templates to be built based on untrusted input. Where there is no alternative, any untrusted input being included dynamically during template creation must be sanitized or strictly validated. | 2 | +| **1.3.8** | Verify that the application appropriately sanitizes untrusted input before use in Java Naming and Directory Interface (JNDI) queries and that JNDI is configured securely to prevent JNDI injection attacks. | 2 | +| **1.3.9** | Verify that the application sanitizes content before it is sent to memcache to prevent injection attacks. | 2 | +| **1.3.10** | Verify that format strings which might resolve in an unexpected or malicious way when used are sanitized before being processed. | 2 | +| **1.3.11** | Verify that the application sanitizes user input before passing to mail systems to protect against SMTP or IMAP injection. | 2 | +| **1.3.12** | Verify that regular expressions are free from elements causing exponential backtracking, and ensure untrusted input is sanitized to mitigate ReDoS or Runaway Regex attacks. | 3 | + +## V1.4 Memory, String, and Unmanaged Code + +The following requirements address risks associated with unsafe memory use, which generally apply when the application uses a systems language or unmanaged code. + +In some cases, it may be possible to achieve this by setting compiler flags that enable buffer overflow protections and warnings, including stack randomization and data execution prevention, and that break the build if unsafe pointer, memory, format string, integer, or string operations are found. + +| # | Description | Level | +| :---: | :--- | :---: | +| **1.4.1** | Verify that the application uses memory-safe string, safer memory copy and pointer arithmetic to detect or prevent stack, buffer, or heap overflows. | 2 | +| **1.4.2** | Verify that sign, range, and input validation techniques are used to prevent integer overflows. | 2 | +| **1.4.3** | Verify that dynamically allocated memory and resources are released, and that references or pointers to freed memory are removed or set to null to prevent dangling pointers and use-after-free vulnerabilities. | 2 | + +## V1.5 Safe Deserialization + +The conversion of data from a stored or transmitted representation into actual application objects (deserialization) has historically been the cause of various code injection vulnerabilities. It is important to perform this process carefully and safely to avoid these types of issues. + +In particular, certain methods of deserialization have been identified by programming language or framework documentation as insecure and cannot be made safe with untrusted data. For each mechanism in use, careful due diligence should be performed. + +| # | Description | Level | +| :---: | :--- | :---: | +| **1.5.1** | Verify that the application configures XML parsers to use a restrictive configuration and that unsafe features such as resolving external entities are disabled to prevent XML eXternal Entity (XXE) attacks. | 1 | +| **1.5.2** | Verify that deserialization of untrusted data enforces safe input handling, such as using an allowlist of object types or restricting client-defined object types, to prevent deserialization attacks. Deserialization mechanisms that are explicitly defined as insecure must not be used with untrusted input. | 2 | +| **1.5.3** | Verify that different parsers used in the application for the same data type (e.g., JSON parsers, XML parsers, URL parsers), perform parsing in a consistent way and use the same character encoding mechanism to avoid issues such as JSON Interoperability vulnerabilities or different URI or file parsing behavior being exploited in Remote File Inclusion (RFI) or Server-side Request Forgery (SSRF) attacks. | 3 | + +## References + +For more information, see also: + +* [OWASP LDAP Injection Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/LDAP_Injection_Prevention_Cheat_Sheet.html) +* [OWASP Cross Site Scripting Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html) +* [OWASP DOM Based Cross Site Scripting Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html) +* [OWASP XML External Entity Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html) +* [OWASP Web Security Testing Guide: Client-Side Testing](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/11-Client-side_Testing) +* [OWASP Java Encoding Project](https://owasp.org/owasp-java-encoder/) +* [DOMPurify - Client-side HTML Sanitization Library](https://github.com/cure53/DOMPurify) +* [RFC4180 - Common Format and MIME Type for Comma-Separated Values (CSV) Files](https://datatracker.ietf.org/doc/html/rfc4180#section-2) + +For more information, specifically on deserialization or parsing issues, please see: + +* [OWASP Deserialization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html) +* [An Exploration of JSON Interoperability Vulnerabilities](https://bishopfox.com/blog/json-interoperability-vulnerabilities) +* [Orange Tsai - A New Era of SSRF Exploiting URL Parser In Trending Programming Languages](https://www.blackhat.com/docs/us-17/thursday/us-17-Tsai-A-New-Era-Of-SSRF-Exploiting-URL-Parser-In-Trending-Programming-Languages.pdf) diff --git a/5.0/pt/0x11-V2-Validation-and-Business-Logic.md b/5.0/pt/0x11-V2-Validation-and-Business-Logic.md new file mode 100644 index 0000000000..2b8bf8a6f0 --- /dev/null +++ b/5.0/pt/0x11-V2-Validation-and-Business-Logic.md @@ -0,0 +1,73 @@ +# V2 Validation and Business Logic + +## Control Objective + +This chapter aims to ensure that a verified application meets the following high-level goals: + +* Input received by the application matches business or functional expectations. +* The business logic flow is sequential, processed in order, and cannot be bypassed. +* Business logic includes limits and controls to detect and prevent automated attacks, such as continuous small funds transfers or adding a million friends one at a time. +* High-value business logic flows have considered abuse cases and malicious actors, and have protections against spoofing, tampering, information disclosure, and elevation of privilege attacks. + +## V2.1 Validation and Business Logic Documentation + +Validation and business logic documentation should clearly define business logic limits, validation rules, and contextual consistency of combined data items, so it is clear what needs to be implemented in the application. + +| # | Description | Level | +| :---: | :--- | :---: | +| **2.1.1** | Verify that the application's documentation defines input validation rules for how to check the validity of data items against an expected structure. This could be common data formats such as credit card numbers, email addresses, telephone numbers, or it could be an internal data format. | 1 | +| **2.1.2** | Verify that the application's documentation defines how to validate the logical and contextual consistency of combined data items, such as checking that suburb and ZIP code match. | 2 | +| **2.1.3** | Verify that expectations for business logic limits and validations are documented, including both per-user and globally across the application. | 2 | + +## V2.2 Input Validation + +Effective input validation controls enforce business or functional expectations around the type of data the application expects to receive. This ensures good data quality and reduces the attack surface. However, it does not remove or replace the need to use correct encoding, parameterization, or sanitization when using the data in another component or for presenting it for output. + +In this context, "input" could come from a wide variety of sources, including HTML form fields, REST requests, URL parameters, HTTP header fields, cookies, files on disk, databases, and external APIs. + +A business logic control might check that a particular input is a number less than 100. A functional expectation might check that a number is below a certain threshold, as that number controls how many times a particular loop will take place, and a high number could lead to excessive processing and a potential denial of service condition. + +While schema validation is not explicitly mandated, it may be the most effective mechanism for full validation coverage of HTTP APIs or other interfaces that use JSON or XML. + +Please note the following points on Schema Validation: + +* The "published version" of the JSON Schema validation specification is considered production-ready, but not strictly speaking "stable." When using JSON Schema validation, ensure there are no gaps with the guidance in the requirements below. +* Any JSON Schema validation libraries in use should also be monitored and updated if necessary once the standard is formalized. +* DTD validation should not be used, and framework DTD evaluation should be disabled, to avoid issues with XXE attacks against DTDs. + +| # | Description | Level | +| :---: | :--- | :---: | +| **2.2.1** | Verify that input is validated to enforce business or functional expectations for that input. This should either use positive validation against an allow list of values, patterns, and ranges, or be based on comparing the input to an expected structure and logical limits according to predefined rules. For L1, this can focus on input which is used to make specific business or security decisions. For L2 and up, this should apply to all input. | 1 | +| **2.2.2** | Verify that the application is designed to enforce input validation at a trusted service layer. While client-side validation improves usability and should be encouraged, it must not be relied upon as a security control. | 1 | +| **2.2.3** | Verify that the application ensures that combinations of related data items are reasonable according to the pre-defined rules. | 2 | + +## V2.3 Business Logic Security + +This section considers key requirements to ensure that the application enforces business logic processes in the correct way and is not vulnerable to attacks that exploit the logic and flow of the application. + +| # | Description | Level | +| :---: | :--- | :---: | +| **2.3.1** | Verify that the application will only process business logic flows for the same user in the expected sequential step order and without skipping steps. | 1 | +| **2.3.2** | Verify that business logic limits are implemented per the application's documentation to avoid business logic flaws being exploited. | 2 | +| **2.3.3** | Verify that transactions are being used at the business logic level such that either a business logic operation succeeds in its entirety or it is rolled back to the previous correct state. | 2 | +| **2.3.4** | Verify that business logic level locking mechanisms are used to ensure that limited quantity resources (such as theater seats or delivery slots) cannot be double-booked by manipulating the application's logic. | 2 | +| **2.3.5** | Verify that high-value business logic flows require multi-user approval to prevent unauthorized or accidental actions. This could include but is not limited to large monetary transfers, contract approvals, access to classified information, or safety overrides in manufacturing. | 3 | + +## V2.4 Anti-automation + +This section includes anti-automation controls to ensure that human-like interactions are required and excessive automated requests are prevented. + +| # | Description | Level | +| :---: | :--- | :---: | +| **2.4.1** | Verify that anti-automation controls are in place to protect against excessive calls to application functions that could lead to data exfiltration, garbage-data creation, quota exhaustion, rate-limit breaches, denial-of-service, or overuse of costly resources. | 2 | +| **2.4.2** | Verify that business logic flows require realistic human timing, preventing excessively rapid transaction submissions. | 3 | + +## References + +For more information, see also: + +* [OWASP Web Security Testing Guide: Input Validation Testing](https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/07-Input_Validation_Testing/README.html) +* [OWASP Web Security Testing Guide: Business Logic Testing](https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/10-Business_Logic_Testing/README) +* Anti-automation can be achieved in many ways, including the use of the [OWASP Automated Threats to Web Applications](https://owasp.org/www-project-automated-threats-to-web-applications/) +* [OWASP Input Validation Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html) +* [JSON Schema](https://json-schema.org/specification.html) diff --git a/5.0/pt/0x12-V3-Web-Frontend-Security.md b/5.0/pt/0x12-V3-Web-Frontend-Security.md new file mode 100644 index 0000000000..3d94e02905 --- /dev/null +++ b/5.0/pt/0x12-V3-Web-Frontend-Security.md @@ -0,0 +1,100 @@ +# V3 Web Frontend Security + +## Control Objective + +This category focuses on requirements designed to protect against attacks executed via a web frontend. These requirements do not apply to machine-to-machine solutions. + +## V3.1 Web Frontend Security Documentation + +This section outlines the browser security features that should be specified in the application's documentation. + +| # | Description | Level | +| :---: | :--- | :---: | +| **3.1.1** | Verify that application documentation states the expected security features that browsers using the application must support (such as HTTPS, HTTP Strict Transport Security (HSTS), Content Security Policy (CSP), and other relevant HTTP security mechanisms). It must also define how the application must behave when some of these features are not available (such as warning the user or blocking access). | 3 | + +## V3.2 Unintended Content Interpretation + +Rendering content or functionality in an incorrect context can result in malicious content being executed or displayed. + +| # | Description | Level | +| :---: | :--- | :---: | +| **3.2.1** | Verify that security controls are in place to prevent browsers from rendering content or functionality in HTTP responses in an incorrect context (e.g., when an API, a user-uploaded file or other resource is requested directly). Possible controls could include: not serving the content unless HTTP request header fields (such as Sec-Fetch-\*) indicate it is the correct context, using the sandbox directive of the Content-Security-Policy header field or using the attachment disposition type in the Content-Disposition header field. | 1 | +| **3.2.2** | Verify that content intended to be displayed as text, rather than rendered as HTML, is handled using safe rendering functions (such as createTextNode or textContent) to prevent unintended execution of content such as HTML or JavaScript. | 1 | +| **3.2.3** | Verify that the application avoids DOM clobbering when using client-side JavaScript by employing explicit variable declarations, performing strict type checking, avoiding storing global variables on the document object, and implementing namespace isolation. | 3 | + +## V3.3 Cookie Setup + +This section outlines requirements for securely configuring sensitive cookies to provide a higher level of assurance that they were created by the application itself and to prevent their contents from leaking or being inappropriately modified. + +| # | Description | Level | +| :---: | :--- | :---: | +| **3.3.1** | Verify that cookies have the 'Secure' attribute set, and if the '\__Host-' prefix is not used for the cookie name, the '__Secure-' prefix must be used for the cookie name. | 1 | +| **3.3.2** | Verify that each cookie's 'SameSite' attribute value is set according to the purpose of the cookie, to limit exposure to user interface redress attacks and browser-based request forgery attacks, commonly known as cross-site request forgery (CSRF). | 2 | +| **3.3.3** | Verify that cookies have the '__Host-' prefix for the cookie name unless they are explicitly designed to be shared with other hosts. | 2 | +| **3.3.4** | Verify that if the value of a cookie is not meant to be accessible to client-side scripts (such as a session token), the cookie must have the 'HttpOnly' attribute set and the same value (e. g. session token) must only be transferred to the client via the 'Set-Cookie' header field. | 2 | +| **3.3.5** | Verify that when the application writes a cookie, the cookie name and value length combined are not over 4096 bytes. Overly large cookies will not be stored by the browser and therefore not sent with requests, preventing the user from using application functionality which relies on that cookie. | 3 | + +## V3.4 Browser Security Mechanism Headers + +This section describes which security headers should be set on HTTP responses to enable browser security features and restrictions when handling responses from the application. + +| # | Description | Level | +| :---: | :--- | :---: | +| **3.4.1** | Verify that a Strict-Transport-Security header field is included on all responses to enforce an HTTP Strict Transport Security (HSTS) policy. A maximum age of at least 1 year must be defined, and for L2 and up, the policy must apply to all subdomains as well. | 1 | +| **3.4.2** | Verify that the Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin header field is a fixed value by the application, or if the Origin HTTP request header field value is used, it is validated against an allowlist of trusted origins. When 'Access-Control-Allow-Origin: *' needs to be used, verify that the response does not include any sensitive information. | 1 | +| **3.4.3** | Verify that HTTP responses include a Content-Security-Policy response header field which defines directives to ensure the browser only loads and executes trusted content or resources, in order to limit execution of malicious JavaScript. As a minimum, a global policy must be used which includes the directives object-src 'none' and base-uri 'none' and defines either an allowlist or uses nonces or hashes. For an L3 application, a per-response policy with nonces or hashes must be defined. | 2 | +| **3.4.4** | Verify that all HTTP responses contain an 'X-Content-Type-Options: nosniff' header field. This instructs browsers not to use content sniffing and MIME type guessing for the given response, and to require the response's Content-Type header field value to match the destination resource. For example, the response to a request for a style is only accepted if the response's Content-Type is 'text/css'. This also enables the use of the Cross-Origin Read Blocking (CORB) functionality by the browser. | 2 | +| **3.4.5** | Verify that the application sets a referrer policy to prevent leakage of technically sensitive data to third-party services via the 'Referer' HTTP request header field. This can be done using the Referrer-Policy HTTP response header field or via HTML element attributes. Sensitive data could include path and query data in the URL, and for internal non-public applications also the hostname. | 2 | +| **3.4.6** | Verify that the web application uses the frame-ancestors directive of the Content-Security-Policy header field for every HTTP response to ensure that it cannot be embedded by default and that embedding of specific resources is allowed only when necessary. Note that the X-Frame-Options header field, although supported by browsers, is obsolete and may not be relied upon. | 2 | +| **3.4.7** | Verify that the Content-Security-Policy header field specifies a location to report violations. | 3 | +| **3.4.8** | Verify that all HTTP responses that initiate a document rendering (such as responses with Content-Type text/html), include the Cross‑Origin‑Opener‑Policy header field with the same-origin directive or the same-origin-allow-popups directive as required. This prevents attacks that abuse shared access to Window objects, such as tabnabbing and frame counting. | 3 | + +## V3.5 Browser Origin Separation + +When accepting a request to sensitive functionality on the server side, the application needs to ensure the request is initiated by the application itself or by a trusted party and has not been forged by an attacker. + +Sensitive functionality in this context could include accepting form posts for authenticated and non-authenticated users (such as an authentication request), state-changing operations, or resource-demanding functionality (such as data export). + +The key protections here are browser security policies like Same Origin Policy for JavaScript and also SameSite logic for cookies. Another common protection is the CORS preflight mechanism. This mechanism will be critical for endpoints designed to be called from a different origin, but it can also be a useful request forgery prevention mechanism for endpoints which are not designed to be called from a different origin. + +| # | Description | Level | +| :---: | :--- | :---: | +| **3.5.1** | Verify that, if the application does not rely on the CORS preflight mechanism to prevent disallowed cross-origin requests to use sensitive functionality, these requests are validated to ensure they originate from the application itself. This may be done by using and validating anti-forgery tokens or requiring extra HTTP header fields that are not CORS-safelisted request-header fields. This is to defend against browser-based request forgery attacks, commonly known as cross-site request forgery (CSRF). | 1 | +| **3.5.2** | Verify that, if the application relies on the CORS preflight mechanism to prevent disallowed cross-origin use of sensitive functionality, it is not possible to call the functionality with a request which does not trigger a CORS-preflight request. This may require checking the values of the 'Origin' and 'Content-Type' request header fields or using an extra header field that is not a CORS-safelisted header-field. | 1 | +| **3.5.3** | Verify that HTTP requests to sensitive functionality use appropriate HTTP methods such as POST, PUT, PATCH, or DELETE, and not methods defined by the HTTP specification as "safe" such as HEAD, OPTIONS, or GET. Alternatively, strict validation of the Sec-Fetch-* request header fields can be used to ensure that the request did not originate from an inappropriate cross-origin call, a navigation request, or a resource load (such as an image source) where this is not expected. | 1 | +| **3.5.4** | Verify that separate applications are hosted on different hostnames to leverage the restrictions provided by same-origin policy, including how documents or scripts loaded by one origin can interact with resources from another origin and hostname-based restrictions on cookies. | 2 | +| **3.5.5** | Verify that messages received by the postMessage interface are discarded if the origin of the message is not trusted, or if the syntax of the message is invalid. | 2 | +| **3.5.6** | Verify that JSONP functionality is not enabled anywhere across the application to avoid Cross-Site Script Inclusion (XSSI) attacks. | 3 | +| **3.5.7** | Verify that data requiring authorization is not included in script resource responses, like JavaScript files, to prevent Cross-Site Script Inclusion (XSSI) attacks. | 3 | +| **3.5.8** | Verify that authenticated resources (such as images, videos, scripts, and other documents) can be loaded or embedded on behalf of the user only when intended. This can be accomplished by strict validation of the Sec-Fetch-* HTTP request header fields to ensure that the request did not originate from an inappropriate cross-origin call, or by setting a restrictive Cross-Origin-Resource-Policy HTTP response header field to instruct the browser to block returned content. | 3 | + +## V3.6 External Resource Integrity + +This section provides guidance for the safe hosting of content on third-party sites. + +| # | Description | Level | +| :---: | :--- | :---: | +| **3.6.1** | Verify that client-side assets, such as JavaScript libraries, CSS, or web fonts, are only hosted externally (e.g., on a Content Delivery Network) if the resource is static and versioned and Subresource Integrity (SRI) is used to validate the integrity of the asset. If this is not possible, there should be a documented security decision to justify this for each resource. | 3 | + +## V3.7 Other Browser Security Considerations + +This section includes various other security controls and modern browser security features required for client-side browser security. + +| # | Description | Level | +| :---: | :--- | :---: | +| **3.7.1** | Verify that the application only uses client-side technologies which are still supported and considered secure. Examples of technologies which do not meet this requirement include NSAPI plugins, Flash, Shockwave, ActiveX, Silverlight, NACL, or client-side Java applets. | 2 | +| **3.7.2** | Verify that the application will only automatically redirect the user to a different hostname or domain (which is not controlled by the application) where the destination appears on an allowlist. | 2 | +| **3.7.3** | Verify that the application shows a notification when the user is being redirected to a URL outside of the application's control, with an option to cancel the navigation. | 3 | +| **3.7.4** | Verify that the application's top-level domain (e.g., site.tld) is added to the public preload list for HTTP Strict Transport Security (HSTS). This ensures that the use of TLS for the application is built directly into the main browsers, rather than relying only on the Strict-Transport-Security response header field. | 3 | +| **3.7.5** | Verify that the application behaves as documented (such as warning the user or blocking access) if the browser used to access the application does not support the expected security features. | 3 | + +## References + +For more information, see also: + +* [Set-Cookie __Host- prefix details](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#cookie_prefixes) +* [OWASP Content Security Policy Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html) +* [OWASP Secure Headers Project](https://owasp.org/www-project-secure-headers/) +* [OWASP Cross-Site Request Forgery Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html) +* [HSTS Browser Preload List submission form](https://hstspreload.org/) +* [OWASP DOM Clobbering Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/DOM_Clobbering_Prevention_Cheat_Sheet.html) diff --git a/5.0/pt/0x13-V4-API-and-Web-Service.md b/5.0/pt/0x13-V4-API-and-Web-Service.md new file mode 100644 index 0000000000..470abc3ef7 --- /dev/null +++ b/5.0/pt/0x13-V4-API-and-Web-Service.md @@ -0,0 +1,64 @@ +# V4 API and Web Service + +## Control Objective + +Several considerations apply specifically to applications that expose APIs for use by web browsers or other consumers (commonly using JSON, XML, or GraphQL). This chapter covers the relevant security configurations and mechanisms that should be applied. + +Note that authentication, session management, and input validation concerns from other chapters also apply to APIs, so this chapter cannot be taken out of context or tested in isolation. + +## V4.1 Generic Web Service Security + +This section addresses general web service security considerations and, consequently, basic web service hygiene practices. + +| # | Description | Level | +| :---: | :--- | :---: | +| **4.1.1** | Verify that every HTTP response with a message body contains a Content-Type header field that matches the actual content of the response, including the charset parameter to specify safe character encoding (e.g., UTF-8, ISO-8859-1) according to IANA Media Types, such as "text/", "/+xml" and "/xml". | 1 | +| **4.1.2** | Verify that only user-facing endpoints (intended for manual web-browser access) automatically redirect from HTTP to HTTPS, while other services or endpoints do not implement transparent redirects. This is to avoid a situation where a client is erroneously sending unencrypted HTTP requests, but since the requests are being automatically redirected to HTTPS, the leakage of sensitive data goes undiscovered. | 2 | +| **4.1.3** | Verify that any HTTP header field used by the application and set by an intermediary layer, such as a load balancer, a web proxy, or a backend-for-frontend service, cannot be overridden by the end-user. Example headers might include X-Real-IP, X-Forwarded-*, or X-User-ID. | 2 | +| **4.1.4** | Verify that only HTTP methods that are explicitly supported by the application or its API (including OPTIONS during preflight requests) can be used and that unused methods are blocked. | 3 | +| **4.1.5** | Verify that per-message digital signatures are used to provide additional assurance on top of transport protections for requests or transactions which are highly sensitive or which traverse a number of systems. | 3 | + +## V4.2 HTTP Message Structure Validation + +This section explains how the structure and header fields of an HTTP message should be validated to prevent attacks such as request smuggling, response splitting, header injection, and denial of service via overly long HTTP messages. + +These requirements are relevant for general HTTP message processing and generation, but are especially important when converting HTTP messages between different HTTP versions. + +| # | Description | Level | +| :---: | :--- | :---: | +| **4.2.1** | Verify that all application components (including load balancers, firewalls, and application servers) determine boundaries of incoming HTTP messages using the appropriate mechanism for the HTTP version to prevent HTTP request smuggling. In HTTP/1.x, if a Transfer-Encoding header field is present, the Content-Length header must be ignored per RFC 2616. When using HTTP/2 or HTTP/3, if a Content-Length header field is present, the receiver must ensure that it is consistent with the length of the DATA frames. | 2 | +| **4.2.2** | Verify that when generating HTTP messages, the Content-Length header field does not conflict with the length of the content as determined by the framing of the HTTP protocol, in order to prevent request smuggling attacks. | 3 | +| **4.2.3** | Verify that the application does not send nor accept HTTP/2 or HTTP/3 messages with connection-specific header fields such as Transfer-Encoding to prevent response splitting and header injection attacks. | 3 | +| **4.2.4** | Verify that the application only accepts HTTP/2 and HTTP/3 requests where the header fields and values do not contain any CR (\r), LF (\n), or CRLF (\r\n) sequences, to prevent header injection attacks. | 3 | +| **4.2.5** | Verify that, if the application (backend or frontend) builds and sends requests, it uses validation, sanitization, or other mechanisms to avoid creating URIs (such as for API calls) or HTTP request header fields (such as Authorization or Cookie), which are too long to be accepted by the receiving component. This could cause a denial of service, such as when sending an overly long request (e.g., a long cookie header field), which results in the server always responding with an error status. | 3 | + +## V4.3 GraphQL + +GraphQL is becoming more common as a way of creating data-rich clients that are not tightly coupled to a variety of backend services. This section covers security considerations for GraphQL. + +| # | Description | Level | +| :---: | :--- | :---: | +| **4.3.1** | Verify that a query allowlist, depth limiting, amount limiting, or query cost analysis is used to prevent GraphQL or data layer expression Denial of Service (DoS) as a result of expensive, nested queries. | 2 | +| **4.3.2** | Verify that GraphQL introspection queries are disabled in the production environment unless the GraphQL API is meant to be used by other parties. | 2 | + +## V4.4 WebSocket + +WebSocket is a communications protocol that provides a simultaneous two-way communication channel over a single TCP connection. It was standardized by the IETF as RFC 6455 in 2011 and is distinct from HTTP, even though it is designed to work over HTTP ports 443 and 80. + +This section provides key security requirements to prevent attacks related to communication security and session management that specifically exploit this real-time communication channel. + +| # | Description | Level | +| :---: | :--- | :---: | +| **4.4.1** | Verify that WebSocket over TLS (WSS) is used for all WebSocket connections. | 1 | +| **4.4.2** | Verify that, during the initial HTTP WebSocket handshake, the Origin header field is checked against a list of origins allowed for the application. | 2 | +| **4.4.3** | Verify that, if the application's standard session management cannot be used, dedicated tokens are being used for this, which comply with the relevant Session Management security requirements. | 2 | +| **4.4.4** | Verify that dedicated WebSocket session management tokens are initially obtained or validated through the previously authenticated HTTPS session when transitioning an existing HTTPS session to a WebSocket channel. | 2 | + +## References + +For more information, see also: + +* [OWASP REST Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html) +* Resources on GraphQL Authorization from [graphql.org](https://graphql.org/learn/authorization/) and [Apollo](https://www.apollographql.com/docs/apollo-server/security/authentication/#authorization-methods). +* [OWASP Web Security Testing Guide: GraphQL Testing](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/12-API_Testing/01-Testing_GraphQL) +* [OWASP Web Security Testing Guide: Testing WebSockets](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/11-Client-side_Testing/10-Testing_WebSockets) diff --git a/5.0/pt/0x14-V5-File-Handling.md b/5.0/pt/0x14-V5-File-Handling.md new file mode 100644 index 0000000000..e8d601cefe --- /dev/null +++ b/5.0/pt/0x14-V5-File-Handling.md @@ -0,0 +1,54 @@ +# V5 File Handling + +## Control Objective + +The use of files can present a variety of risks to the application, including denial of service, unauthorized access, and storage exhaustion. This chapter includes requirements to address these risks. + +## V5.1 File Handling Documentation + +This section includes a requirement to document the expected characteristics of files accepted by the application, as a necessary precondition for developing and verifying relevant security checks. + +| # | Description | Level | +| :---: | :--- | :---: | +| **5.1.1** | Verify that the documentation defines the permitted file types, expected file extensions, and maximum size (including unpacked size) for each upload feature. Additionally, ensure that the documentation specifies how files are made safe for end-users to download and process, such as how the application behaves when a malicious file is detected. | 2 | + +## V5.2 File Upload and Content + +File upload functionality is a primary source of untrusted files. This section outlines the requirements for ensuring that the presence, volume, or content of these files cannot harm the application. + +| # | Description | Level | +| :---: | :--- | :---: | +| **5.2.1** | Verify that the application will only accept files of a size which it can process without causing a loss of performance or a denial of service attack. | 1 | +| **5.2.2** | Verify that when the application accepts a file, either on its own or within an archive such as a zip file, it checks if the file extension matches an expected file extension and validates that the contents correspond to the type represented by the extension. This includes, but is not limited to, checking the initial 'magic bytes', performing image re-writing, and using specialized libraries for file content validation. For L1, this can focus just on files which are used to make specific business or security decisions. For L2 and up, this must apply to all files being accepted. | 1 | +| **5.2.3** | Verify that the application checks compressed files (e.g., zip, gz, docx, odt) against maximum allowed uncompressed size and against maximum number of files before uncompressing the file. | 2 | +| **5.2.4** | Verify that a file size quota and maximum number of files per user are enforced to ensure that a single user cannot fill up the storage with too many files, or excessively large files. | 3 | +| **5.2.5** | Verify that the application does not allow uploading compressed files containing symlinks unless this is specifically required (in which case it will be necessary to enforce an allowlist of the files that can be symlinked to). | 3 | +| **5.2.6** | Verify that the application rejects uploaded images with a pixel size larger than the maximum allowed, to prevent pixel flood attacks. | 3 | + +## V5.3 File Storage + +This section includes requirements to prevent files from being inappropriately executed after upload, to detect dangerous content, and to avoid untrusted data being used to control where files are being stored. + +| # | Description | Level | +| :---: | :--- | :---: | +| **5.3.1** | Verify that files uploaded or generated by untrusted input and stored in a public folder, are not executed as server-side program code when accessed directly with an HTTP request. | 1 | +| **5.3.2** | Verify that when the application creates file paths for file operations, instead of user-submitted filenames, it uses internally generated or trusted data, or if user-submitted filenames or file metadata must be used, strict validation and sanitization must be applied. This is to protect against path traversal, local or remote file inclusion (LFI, RFI), and server-side request forgery (SSRF) attacks. | 1 | +| **5.3.3** | Verify that server-side file processing, such as file decompression, ignores user-provided path information to prevent vulnerabilities such as zip slip. | 3 | + +## V5.4 File Download + +This section contains requirements to mitigate risks when serving files to be downloaded, including path traversal and injection attacks. This also includes making sure they don't contain dangerous content. + +| # | Description | Level | +| :---: | :--- | :---: | +| **5.4.1** | Verify that the application validates or ignores user-submitted filenames, including in a JSON, JSONP, or URL parameter and specifies a filename in the Content-Disposition header field in the response. | 2 | +| **5.4.2** | Verify that file names served (e.g., in HTTP response header fields or email attachments) are encoded or sanitized (e.g., following RFC 6266) to preserve document structure and prevent injection attacks. | 2 | +| **5.4.3** | Verify that files obtained from untrusted sources are scanned by antivirus scanners to prevent serving of known malicious content. | 2 | + +## References + +For more information, see also: + +* [OWASP File Upload Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html) +* [Example of using symlinks for arbitrary file read](https://hackerone.com/reports/1439593) +* [Explanation of "Magic Bytes" from Wikipedia](https://en.wikipedia.org/wiki/List_of_file_signatures) diff --git a/5.0/pt/0x15-V6-Authentication.md b/5.0/pt/0x15-V6-Authentication.md new file mode 100644 index 0000000000..d9fa0025ad --- /dev/null +++ b/5.0/pt/0x15-V6-Authentication.md @@ -0,0 +1,166 @@ +# V6 Authentication + +## Control Objective + +Authentication is the process of establishing or confirming the authenticity of an individual or device. It involves verifying claims made by a person or about a device, ensuring resistance to impersonation, and preventing the recovery or interception of passwords. + +[NIST SP 800-63](https://pages.nist.gov/800-63-3/) is a modern, evidence-based standard that is valuable for organizations worldwide, but is particularly relevant to US agencies and those interacting with US agencies. + +While many of the requirements in this chapter are based on the second section of the standard (known as NIST SP 800-63B "Digital Identity Guidelines - Authentication and Lifecycle Management"), the chapter focuses on common threats and frequently exploited authentication weaknesses. It does not attempt to comprehensively cover every point in the standard. For cases where full NIST SP 800-63 compliance is necessary, please refer to NIST SP 800-63. + +Additionally, NIST SP 800-63 terminology may sometimes differ, and this chapter often uses more commonly understood terminology to improve clarity. + +A common feature of more advanced applications is the ability to adapt authentication stages required based on various risk factors. This feature is covered in the "Authorization" chapter, since these mechanisms also need to be considered for authorization decisions. + +## V6.1 Authentication Documentation + +This section contains requirements detailing the authentication documentation that should be maintained for an application. This is crucial for implementing and assessing how the relevant authentication controls should be configured. + +| # | Description | Level | +| :---: | :--- | :---: | +| **6.1.1** | Verify that application documentation defines how controls such as rate limiting, anti-automation, and adaptive response, are used to defend against attacks such as credential stuffing and password brute force. The documentation must make clear how these controls are configured and prevent malicious account lockout. | 1 | +| **6.1.2** | Verify that a list of context-specific words is documented in order to prevent their use in passwords. The list could include permutations of organization names, product names, system identifiers, project codenames, department or role names, and similar. | 2 | +| **6.1.3** | Verify that, if the application includes multiple authentication pathways, these are all documented together with the security controls and authentication strength which must be consistently enforced across them. | 2 | + +## V6.2 Password Security + +Passwords, called "Memorized Secrets" by NIST SP 800-63, include passwords, passphrases, PINs, unlock patterns, and picking the correct kitten or another image element. They are generally considered "something you know" and are often used as a single-factor authentication mechanism. + +As such, this section contains requirements for making sure that passwords are created and handled securely. Most of the requirements are L1 as they are most important at that level. From L2 onwards, multi-factor authentication mechanisms are required, where passwords may be one of those factors. + +The requirements in this section mostly relate to [§ 5.1.1.2](https://pages.nist.gov/800-63-3/sp800-63b.html#memsecretver) of [NIST's Guidance](https://pages.nist.gov/800-63-3/sp800-63b.html). + +| # | Description | Level | +| :---: | :--- | :---: | +| **6.2.1** | Verify that user set passwords are at least 8 characters in length although a minimum of 15 characters is strongly recommended. | 1 | +| **6.2.2** | Verify that users can change their password. | 1 | +| **6.2.3** | Verify that password change functionality requires the user's current and new password. | 1 | +| **6.2.4** | Verify that passwords submitted during account registration or password change are checked against an available set of, at least, the top 3000 passwords which match the application's password policy, e.g. minimum length. | 1 | +| **6.2.5** | Verify that passwords of any composition can be used, without rules limiting the type of characters permitted. There must be no requirement for a minimum number of upper or lower case characters, numbers, or special characters. | 1 | +| **6.2.6** | Verify that password input fields use type=password to mask the entry. Applications may allow the user to temporarily view the entire masked password, or the last typed character of the password. | 1 | +| **6.2.7** | Verify that "paste" functionality, browser password helpers, and external password managers are permitted. | 1 | +| **6.2.8** | Verify that the application verifies the user's password exactly as received from the user, without any modifications such as truncation or case transformation. | 1 | +| **6.2.9** | Verify that passwords of at least 64 characters are permitted. | 2 | +| **6.2.10** | Verify that a user's password stays valid until it is discovered to be compromised or the user rotates it. The application must not require periodic credential rotation. | 2 | +| **6.2.11** | Verify that the documented list of context specific words is used to prevent easy to guess passwords being created. | 2 | +| **6.2.12** | Verify that passwords submitted during account registration or password changes are checked against a set of breached passwords. | 2 | + +## V6.3 General Authentication Security + +This section contains general requirements for the security of authentication mechanisms as well as setting out the different expectations for levels. L2 applications must force the use of multi-factor authentication (MFA). L3 applications must use hardware-based authentication, performed in an attested and trusted execution environment (TEE). This could include device-bound passkeys, eIDAS Level of Assurance (LoA) High enforced authenticators, authenticators with NIST Authenticator Assurance Level 3 (AAL3) assurance, or an equivalent mechanism. + +While this is a relatively aggressive stance on MFA, it is critical to raise the bar around this to protect users, and any attempt to relax these requirements should be accompanied by a clear plan on how the risks around authentication will be mitigated, taking into account NIST's guidance and research on the topic. + +Note that at the time of release, NIST SP 800-63 considers email as [not acceptable](https://pages.nist.gov/800-63-FAQ/#q-b11) as an authentication mechanism ([archived copy](https://web.archive.org/web/20250330115328/https://pages.nist.gov/800-63-FAQ/#q-b11)). + +The requirements in this section relate to a variety of sections of [NIST's Guidance](https://pages.nist.gov/800-63-3/sp800-63b.html), including: [§ 4.2.1](https://pages.nist.gov/800-63-3/sp800-63b.html#421-permitted-authenticator-types), [§ 4.3.1](https://pages.nist.gov/800-63-3/sp800-63b.html#431-permitted-authenticator-types), [§ 5.2.2](https://pages.nist.gov/800-63-3/sp800-63b.html#522-rate-limiting-throttling), and [§ 6.1.2](https://pages.nist.gov/800-63-3/sp800-63b.html#-612-post-enrollment-binding). + +| # | Description | Level | +| :---: | :--- | :---: | +| **6.3.1** | Verify that controls to prevent attacks such as credential stuffing and password brute force are implemented according to the application's security documentation. | 1 | +| **6.3.2** | Verify that default user accounts (e.g., "root", "admin", or "sa") are not present in the application or are disabled. | 1 | +| **6.3.3** | Verify that either a multi-factor authentication mechanism or a combination of single-factor authentication mechanisms, must be used in order to access the application. For L3, one of the factors must be a hardware-based authentication mechanism which provides compromise and impersonation resistance against phishing attacks while verifying the intent to authenticate by requiring a user-initiated action (such as a button press on a FIDO hardware key or a mobile phone). Relaxing any of the considerations in this requirement requires a fully documented rationale and a comprehensive set of mitigating controls. | 2 | +| **6.3.4** | Verify that, if the application includes multiple authentication pathways, there are no undocumented pathways and that security controls and authentication strength are enforced consistently. | 2 | +| **6.3.5** | Verify that users are notified of suspicious authentication attempts (successful or unsuccessful). This may include authentication attempts from an unusual location or client, partially successful authentication (only one of multiple factors), an authentication attempt after a long period of inactivity or a successful authentication after several unsuccessful attempts. | 3 | +| **6.3.6** | Verify that email is not used as either a single-factor or multi-factor authentication mechanism. | 3 | +| **6.3.7** | Verify that users are notified after updates to authentication details, such as credential resets or modification of the username or email address. | 3 | +| **6.3.8** | Verify that valid users cannot be deduced from failed authentication challenges, such as by basing on error messages, HTTP response codes, or different response times. Registration and forgot password functionality must also have this protection. | 3 | + +## V6.4 Authentication Factor Lifecycle and Recovery + +Authentication factors may include passwords, soft tokens, hardware tokens, and biometric devices. Securely handling the lifecycle of these mechanisms is critical to the security of an application, and this section includes requirements related to this. + +The requirements in this section mostly relate to [§ 5.1.1.2](https://pages.nist.gov/800-63-3/sp800-63b.html#memsecretver) or [§ 6.1.2.3](https://pages.nist.gov/800-63-3/sp800-63b.html#replacement) of [NIST's Guidance](https://pages.nist.gov/800-63-3/sp800-63b.html). + +| # | Description | Level | +| :---: | :--- | :---: | +| **6.4.1** | Verify that system generated initial passwords or activation codes are securely randomly generated, follow the existing password policy, and expire after a short period of time or after they are initially used. These initial secrets must not be permitted to become the long term password. | 1 | +| **6.4.2** | Verify that password hints or knowledge-based authentication (so-called "secret questions") are not present. | 1 | +| **6.4.3** | Verify that a secure process for resetting a forgotten password is implemented, that does not bypass any enabled multi-factor authentication mechanisms. | 2 | +| **6.4.4** | Verify that if a multi-factor authentication factor is lost, evidence of identity proofing is performed at the same level as during enrollment. | 2 | +| **6.4.5** | Verify that renewal instructions for authentication mechanisms which expire are sent with enough time to be carried out before the old authentication mechanism expires, configuring automated reminders if necessary. | 3 | +| **6.4.6** | Verify that administrative users can initiate the password reset process for the user, but that this does not allow them to change or choose the user's password. This prevents a situation where they know the user's password. | 3 | + +## V6.5 General Multi-factor authentication requirements + +This section provides general guidance that will be relevant to various different multi-factor authentication methods. + +The mechanisms include: + +* Lookup Secrets +* Time based One-time Passwords (TOTPs) +* Out-of-Band mechanisms + +Lookup secrets are pre-generated lists of secret codes, similar to Transaction Authorization Numbers (TAN), social media recovery codes, or a grid containing a set of random values. This type of authentication mechanism is considered "something you have" because the codes are deliberately not memorable so will need to be stored somewhere. + +Time based One-time Passwords (TOTPs) are physical or soft tokens that display a continually changing pseudo-random one-time challenge. This type of authentication mechanism is considered "something you have". Multi-factor TOTPs are similar to single-factor TOTPs, but require a valid PIN code, biometric unlocking, USB insertion or NFC pairing, or some additional value (such as transaction signing calculators) to be entered to create the final One-time Password (OTP). + +Details on out-of-band mechanisms will be provided in the next section. + +The requirements in these sections mostly relate to [§ 5.1.2](https://pages.nist.gov/800-63-3/sp800-63b.html#-512-look-up-secrets), [§ 5.1.3](https://pages.nist.gov/800-63-3/sp800-63b.html#-513-out-of-band-devices), [§ 5.1.4.2](https://pages.nist.gov/800-63-3/sp800-63b.html#5142-single-factor-otp-verifiers), [§ 5.1.5.2](https://pages.nist.gov/800-63-3/sp800-63b.html#5152-multi-factor-otp-verifiers), [§ 5.2.1](https://pages.nist.gov/800-63-3/sp800-63b.html#521-physical-authenticators), and [§ 5.2.3](https://pages.nist.gov/800-63-3/sp800-63b.html#523-use-of-biometrics) of [NIST's Guidance](https://pages.nist.gov/800-63-3/sp800-63b.html). + +| # | Description | Level | +| :---: | :--- | :---: | +| **6.5.1** | Verify that lookup secrets, out-of-band authentication requests or codes, and time-based one-time passwords (TOTPs) are only successfully usable once. | 2 | +| **6.5.2** | Verify that, when being stored in the application's backend, lookup secrets with less than 112 bits of entropy (19 random alphanumeric characters or 34 random digits) are hashed with an approved password storage hashing algorithm that incorporates a 32-bit random salt. A standard hash function can be used if the secret has 112 bits of entropy or more. | 2 | +| **6.5.3** | Verify that lookup secrets, out-of-band authentication code, and time-based one-time password seeds, are generated using a Cryptographically Secure Pseudorandom Number Generator (CSPRNG) to avoid predictable values. | 2 | +| **6.5.4** | Verify that lookup secrets and out-of-band authentication codes have a minimum of 20 bits of entropy (typically 4 random alphanumeric characters or 6 random digits is sufficient). | 2 | +| **6.5.5** | Verify that out-of-band authentication requests, codes, or tokens, as well as time-based one-time passwords (TOTPs) have a defined lifetime. Out of band requests must have a maximum lifetime of 10 minutes and for TOTP a maximum lifetime of 30 seconds. | 2 | +| **6.5.6** | Verify that any authentication factor (including physical devices) can be revoked in case of theft or other loss. | 3 | +| **6.5.7** | Verify that biometric authentication mechanisms are only used as secondary factors together with either something you have or something you know. | 3 | +| **6.5.8** | Verify that time-based one-time passwords (TOTPs) are checked based on a time source from a trusted service and not from an untrusted or client provided time. | 3 | + +## V6.6 Out-of-Band authentication mechanisms + +This usually involves the authentication server communicating with a physical device over a secure secondary channel. For example, sending push notifications to mobile devices. This type of authentication mechanism is considered "something you have". + +Unsafe out-of-band authentication mechanisms such as e-mail and VOIP are not permitted. PSTN and SMS authentication are currently considered to be ["restricted" authentication mechanisms](https://pages.nist.gov/800-63-FAQ/#q-b01) by NIST and should be deprecated in favor of Time based One-time Passwords (TOTPs), a cryptographic mechanism, or similar. NIST SP 800-63B [§ 5.1.3.3](https://pages.nist.gov/800-63-3/sp800-63b.html#-5133-authentication-using-the-public-switched-telephone-network) recommends addressing the risks of device swap, SIM change, number porting, or other abnormal behavior, if telephone or SMS out-of-band authentication absolutely has to be supported. While this ASVS section does not mandate this as a requirement, not taking these precautions for a sensitive L2 app or an L3 app should be seen as a significant red flag. + +Note that NIST has also recently provided guidance which [discourages the use of push notifications](https://pages.nist.gov/800-63-4/sp800-63b/authenticators/#fig-3). While this ASVS section does not do so, it is important to be aware of the risks of "push bombing". + +| # | Description | Level | +| :---: | :--- | :---: | +| **6.6.1** | Verify that authentication mechanisms using the Public Switched Telephone Network (PSTN) to deliver One-time Passwords (OTPs) via phone or SMS are offered only when the phone number has previously been validated, alternate stronger methods (such as Time based One-time Passwords) are also offered, and the service provides information on their security risks to users. For L3 applications, phone and SMS must not be available as options. | 2 | +| **6.6.2** | Verify that out-of-band authentication requests, codes, or tokens are bound to the original authentication request for which they were generated and are not usable for a previous or subsequent one. | 2 | +| **6.6.3** | Verify that a code based out-of-band authentication mechanism is protected against brute force attacks by using rate limiting. Consider also using a code with at least 64 bits of entropy. | 2 | +| **6.6.4** | Verify that, where push notifications are used for multi-factor authentication, rate limiting is used to prevent push bombing attacks. Number matching may also mitigate this risk. | 3 | + +## V6.7 Cryptographic authentication mechanism + +Cryptographic authentication mechanisms include smart cards or FIDO keys, where the user has to plug in or pair the cryptographic device to the computer to complete authentication. The authentication server will send a challenge nonce to the cryptographic device or software, and the device or software calculates a response based upon a securely stored cryptographic key. The requirements in this section provide implementation-specific guidance for these mechanisms, with guidance on cryptographic algorithms being covered in the "Cryptography" chapter. + +Where shared or secret keys are used for cryptographic authentication, these should be stored using the same mechanisms as other system secrets, as documented in the "Secret Management" section in the "Configuration" chapter. + +The requirements in this section mostly relate to [§ 5.1.7.2](https://pages.nist.gov/800-63-3/sp800-63b.html#sfcdv) of [NIST's Guidance](https://pages.nist.gov/800-63-3/sp800-63b.html). + +| # | Description | Level | +| :---: | :--- | :---: | +| **6.7.1** | Verify that the certificates used to verify cryptographic authentication assertions are stored in a way protects them from modification. | 3 | +| **6.7.2** | Verify that the challenge nonce is at least 64 bits in length, and statistically unique or unique over the lifetime of the cryptographic device. | 3 | + +## V6.8 Authentication with an Identity Provider + +Identity Providers (IdPs) provide federated identity for users. Users will often have more than one identity with multiple IdPs, such as an enterprise identity using Azure AD, Okta, Ping Identity, or Google, or consumer identity using Facebook, Twitter, Google, or WeChat, to name just a few common alternatives. This list is not an endorsement of these companies or services, but simply an encouragement for developers to consider the reality that many users have many established identities. Organizations should consider integrating with existing user identities, as per the risk profile of the IdP's strength of identity proofing. For example, it is unlikely a government organization would accept a social media identity as a login for sensitive systems, as it is easy to create fake or throwaway identities, whereas a mobile game company may well need to integrate with major social media platforms to grow their active player base. + +Secure use of external identity providers requires careful configuration and verification to prevent identity spoofing or forged assertions. This section provides requirements to address these risks. + +| # | Description | Level | +| :---: | :--- | :---: | +| **6.8.1** | Verify that, if the application supports multiple identity providers (IdPs), the user's identity cannot be spoofed via another supported identity provider (eg. by using the same user identifier). The standard mitigation would be for the application to register and identify the user using a combination of the IdP ID (serving as a namespace) and the user's ID in the IdP. | 2 | +| **6.8.2** | Verify that the presence and integrity of digital signatures on authentication assertions (for example on JWTs or SAML assertions) are always validated, rejecting any assertions that are unsigned or have invalid signatures. | 2 | +| **6.8.3** | Verify that SAML assertions are uniquely processed and used only once within the validity period to prevent replay attacks. | 2 | +| **6.8.4** | Verify that, if an application uses a separate Identity Provider (IdP) and expects specific authentication strength, methods, or recentness for specific functions, the application verifies this using the information returned by the IdP. For example, if OIDC is used, this might be achieved by validating ID Token claims such as 'acr', 'amr', and 'auth_time' (if present). If the IdP does not provide this information, the application must have a documented fallback approach that assumes that the minimum strength authentication mechanism was used (for example, single-factor authentication using username and password). | 2 | + +## References + +For more information, see also: + +* [NIST SP 800-63 - Digital Identity Guidelines](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-3.pdf) +* [NIST SP 800-63B - Authentication and Lifecycle Management](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf) +* [NIST SP 800-63 FAQ](https://pages.nist.gov/800-63-FAQ/) +* [OWASP Web Security Testing Guide: Testing for Authentication](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/04-Authentication_Testing) +* [OWASP Password Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html) +* [OWASP Forgot Password Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html) +* [OWASP Choosing and Using Security Questions Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Choosing_and_Using_Security_Questions_Cheat_Sheet.html) +* [CISA Guidance on "Number Matching"](https://www.cisa.gov/sites/default/files/publications/fact-sheet-implement-number-matching-in-mfa-applications-508c.pdf) +* [Details on the FIDO Alliance](https://fidoalliance.org/) diff --git a/5.0/pt/0x16-V7-Session-Management.md b/5.0/pt/0x16-V7-Session-Management.md new file mode 100644 index 0000000000..0124d000ac --- /dev/null +++ b/5.0/pt/0x16-V7-Session-Management.md @@ -0,0 +1,91 @@ +# V7 Session Management + +## Control Objective + +Session management mechanisms allow applications to correlate user and device interactions over time, even when using stateless communication protocols (such as HTTP). Modern applications may use multiple session tokens with distinct characteristics and purposes. A secure session management system is one that prevents attackers from obtaining, utilizing, or otherwise abusing a victim's session. Applications maintaining sessions must ensure that the following high-level session management requirements are met: + +* Sessions are unique to each individual and cannot be guessed or shared. +* Sessions are invalidated when no longer required and are timed out during periods of inactivity. + +Many of the requirements in this chapter relate to selected [NIST SP 800-63 Digital Identity Guidelines](https://pages.nist.gov/800-63-4/) controls, focusing on common threats and commonly exploited authentication weaknesses. + +Note that requirements for specific implementation details of certain session management mechanisms can be found elsewhere: + +* HTTP Cookies are a common mechanism for securing session tokens. Specific security requirements for cookies can be found in the "Web Frontend Security" chapter. +* Self-contained tokens are frequently used as a way of maintaining sessions. Specific security requirements can be found in the "Self-contained Tokens" chapter. + +## V7.1 Session Management Documentation + +There is no single pattern that suits all applications. Therefore, it is not feasible to define universal boundaries and limits that suit all cases. A risk analysis with documented security decisions related to session handling must be conducted as a prerequisite to implementation and testing. This ensures that the session management system is tailored to the specific requirements of the application. + +Regardless of whether a stateful or "stateless" session mechanism is chosen, the analysis must be complete and documented to demonstrate that the selected solution is capable of satisfying all relevant security requirements. Interaction with any Single Sign-on (SSO) mechanisms in use should also be considered. + +| # | Description | Level | +| :---: | :--- | :---: | +| **7.1.1** | Verify that the user's session inactivity timeout and absolute maximum session lifetime are documented, are appropriate in combination with other controls, and that the documentation includes justification for any deviations from NIST SP 800-63B re-authentication requirements. | 2 | +| **7.1.2** | Verify that the documentation defines how many concurrent (parallel) sessions are allowed for one account as well as the intended behaviors and actions to be taken when the maximum number of active sessions is reached. | 2 | +| **7.1.3** | Verify that all systems that create and manage user sessions as part of a federated identity management ecosystem (such as SSO systems) are documented along with controls to coordinate session lifetimes, termination, and any other conditions that require re-authentication. | 2 | + +## V7.2 Fundamental Session Management Security + +This section satisfies the essential requirements of secure sessions by verifying that session tokens are securely generated and validated. + +| # | Description | Level | +| :---: | :--- | :---: | +| **7.2.1** | Verify that the application performs all session token verification using a trusted, backend service. | 1 | +| **7.2.2** | Verify that the application uses either self-contained or reference tokens that are dynamically generated for session management, i.e. not using static API secrets and keys. | 1 | +| **7.2.3** | Verify that if reference tokens are used to represent user sessions, they are unique and generated using a cryptographically secure pseudo-random number generator (CSPRNG) and possess at least 128 bits of entropy. | 1 | +| **7.2.4** | Verify that the application generates a new session token on user authentication, including re-authentication, and terminates the current session token. | 1 | + +## V7.3 Session Timeout + +Session timeout mechanisms serve to minimize the window of opportunity for session hijacking and other forms of session abuse. Timeouts must satisfy documented security decisions. + +| # | Description | Level | +| :---: | :--- | :---: | +| **7.3.1** | Verify that there is an inactivity timeout such that re-authentication is enforced according to risk analysis and documented security decisions. | 2 | +| **7.3.2** | Verify that there is an absolute maximum session lifetime such that re-authentication is enforced according to risk analysis and documented security decisions. | 2 | + +## V7.4 Session Termination + +Session termination may be handled either by the application itself or by the SSO provider if the SSO provider is handling session management instead of the application. It may be necessary to decide whether the SSO provider is in scope when considering the requirements in this section as some may be controlled by the provider. + +Session termination should result in requiring re-authentication and be effective across the application, federated login (if present), and any relying parties. + +For stateful session mechanisms, termination typically involves invalidating the session on the backend. In the case of self-contained tokens, additional measures are required to revoke or block these tokens, as they may otherwise remain valid until expiration. + +| # | Description | Level | +| :---: | :--- | :---: | +| **7.4.1** | Verify that when session termination is triggered (such as logout or expiration), the application disallows any further use of the session. For reference tokens or stateful sessions, this means invalidating the session data at the application backend. Applications using self-contained tokens will need a solution such as maintaining a list of terminated tokens, disallowing tokens produced before a per-user date and time or rotating a per-user signing key. | 1 | +| **7.4.2** | Verify that the application terminates all active sessions when a user account is disabled or deleted (such as an employee leaving the company). | 1 | +| **7.4.3** | Verify that the application gives the option to terminate all other active sessions after a successful change or removal of any authentication factor (including password change via reset or recovery and, if present, an MFA settings update). | 2 | +| **7.4.4** | Verify that all pages that require authentication have easy and visible access to logout functionality. | 2 | +| **7.4.5** | Verify that application administrators are able to terminate active sessions for an individual user or for all users. | 2 | + +## V7.5 Defenses Against Session Abuse + +This section provides requirements to mitigate the risk posed by active sessions that are either hijacked or abused through vectors that rely on the existence and capabilities of active user sessions. For example, using malicious content execution to force an authenticated victim browser to perform an action using the victim's session. + +Note that the level-specific guidance in the "Authentication" chapter should be taken into account when considering requirements in this section. + +| # | Description | Level | +| :---: | :--- | :---: | +| **7.5.1** | Verify that the application requires full re-authentication before allowing modifications to sensitive account attributes which may affect authentication such as email address, phone number, MFA configuration, or other information used in account recovery. | 2 | +| **7.5.2** | Verify that users are able to view and (having authenticated again with at least one factor) terminate any or all currently active sessions. | 2 | +| **7.5.3** | Verify that the application requires further authentication with at least one factor or secondary verification before performing highly sensitive transactions or operations. | 3 | + +## V7.6 Federated Re-authentication + +This section relates to those writing Relying Party (RP) or Identity Provider (IdP) code. These requirements are derived from the [NIST SP 800-63C](https://pages.nist.gov/800-63-4/sp800-63c.html) for Federation & Assertions. + +| # | Description | Level | +| :---: | :--- | :---: | +| **7.6.1** | Verify that session lifetime and termination between Relying Parties (RPs) and Identity Providers (IdPs) behave as documented, requiring re-authentication as necessary such as when the maximum time between IdP authentication events is reached. | 2 | +| **7.6.2** | Verify that creation of a session requires either the user's consent or an explicit action, preventing the creation of new application sessions without user interaction. | 2 | + +## References + +For more information, see also: + +* [OWASP Web Security Testing Guide: Session Management Testing](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/06-Session_Management_Testing) +* [OWASP Session Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html) diff --git a/5.0/pt/0x17-V8-Authorization.md b/5.0/pt/0x17-V8-Authorization.md new file mode 100644 index 0000000000..eef4209554 --- /dev/null +++ b/5.0/pt/0x17-V8-Authorization.md @@ -0,0 +1,56 @@ +# V8 Authorization + +## Control Objective + +Authorization ensures that access is granted only to permitted consumers (users, servers, and other clients). To enforce the Principle of Least Privilege (POLP), verified applications must meet the following high-level requirements: + +* Document authorization rules, including decision-making factors and environmental contexts. +* Consumers should have access only to resources permitted by their defined entitlements. + +## V8.1 Authorization Documentation + +Comprehensive authorization documentation is essential to ensure that security decisions are consistently applied, auditable, and aligned with organizational policies. This reduces the risk of unauthorized access by making security requirements clear and actionable for developers, administrators, and testers. + +| # | Description | Level | +| :---: | :--- | :---: | +| **8.1.1** | Verify that authorization documentation defines rules for restricting function-level and data-specific access based on consumer permissions and resource attributes. | 1 | +| **8.1.2** | Verify that authorization documentation defines rules for field-level access restrictions (both read and write) based on consumer permissions and resource attributes. Note that these rules might depend on other attribute values of the relevant data object, such as state or status. | 2 | +| **8.1.3** | Verify that the application's documentation defines the environmental and contextual attributes (including but not limited to, time of day, user location, IP address, or device) that are used in the application to make security decisions, including those pertaining to authentication and authorization. | 3 | +| **8.1.4** | Verify that authentication and authorization documentation defines how environmental and contextual factors are used in decision-making, in addition to function-level, data-specific, and field-level authorization. This should include the attributes evaluated, thresholds for risk, and actions taken (e.g., allow, challenge, deny, step-up authentication). | 3 | + +## V8.2 General Authorization Design + +Implementing granular authorization controls at the function, data, and field levels ensures that consumers can access only what has been explicitly granted to them. + +| # | Description | Level | +| :---: | :--- | :---: | +| **8.2.1** | Verify that the application ensures that function-level access is restricted to consumers with explicit permissions. | 1 | +| **8.2.2** | Verify that the application ensures that data-specific access is restricted to consumers with explicit permissions to specific data items to mitigate insecure direct object reference (IDOR) and broken object level authorization (BOLA). | 1 | +| **8.2.3** | Verify that the application ensures that field-level access is restricted to consumers with explicit permissions to specific fields to mitigate broken object property level authorization (BOPLA). | 2 | +| **8.2.4** | Verify that adaptive security controls based on a consumer's environmental and contextual attributes (such as time of day, location, IP address, or device) are implemented for authentication and authorization decisions, as defined in the application's documentation. These controls must be applied when the consumer tries to start a new session and also during an existing session. | 3 | + +## V8.3 Operation Level Authorization + +The immediate application of authorization changes in the appropriate tier of an application's architecture is crucial to preventing unauthorized actions, especially in dynamic environments. + +| # | Description | Level | +| :---: | :--- | :---: | +| **8.3.1** | Verify that the application enforces authorization rules at a trusted service layer and doesn't rely on controls that an untrusted consumer could manipulate, such as client-side JavaScript. | 1 | +| **8.3.2** | Verify that changes to values on which authorization decisions are made are applied immediately. Where changes cannot be applied immediately, (such as when relying on data in self-contained tokens), there must be mitigating controls to alert when a consumer performs an action when they are no longer authorized to do so and revert the change. Note that this alternative would not mitigate information leakage. | 3 | +| **8.3.3** | Verify that access to an object is based on the originating subject's (e.g. consumer's) permissions, not on the permissions of any intermediary or service acting on their behalf. For example, if a consumer calls a web service using a self-contained token for authentication, and the service then requests data from a different service, the second service will use the consumer's token, rather than a machine-to-machine token from the first service, to make permission decisions. | 3 | + +## V8.4 Other Authorization Considerations + +Additional considerations for authorization, particularly for administrative interfaces and multi-tenant environments, help prevent unauthorized access. + +| # | Description | Level | +| :---: | :--- | :---: | +| **8.4.1** | Verify that multi-tenant applications use cross-tenant controls to ensure consumer operations will never affect tenants with which they do not have permissions to interact. | 2 | +| **8.4.2** | Verify that access to administrative interfaces incorporates multiple layers of security, including continuous consumer identity verification, device security posture assessment, and contextual risk analysis, ensuring that network location or trusted endpoints are not the sole factors for authorization even though they may reduce the likelihood of unauthorized access. | 3 | + +## References + +For more information, see also: + +* [OWASP Web Security Testing Guide: Authorization](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/05-Authorization_Testing) +* [OWASP Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) diff --git a/5.0/pt/0x18-V9-Self-contained-Tokens.md b/5.0/pt/0x18-V9-Self-contained-Tokens.md new file mode 100644 index 0000000000..d34dd16b3e --- /dev/null +++ b/5.0/pt/0x18-V9-Self-contained-Tokens.md @@ -0,0 +1,36 @@ +# V9 Self-contained Tokens + +## Control Objective + +The concept of a self-contained token is mentioned in the original RFC 6749 OAuth 2.0 from 2012. It refers to a token containing data or claims on which a receiving service will rely to make security decisions. This should be differentiated from a simple token containing only an identifier, which a receiving service uses to look up data locally. The most common examples of self-contained tokens are JSON Web Tokens (JWTs) and SAML assertions. + +The use of self-contained tokens has become very widespread, even outside of OAuth and OIDC. At the same time, the security of this mechanism relies on the ability to validate the integrity of the token and to ensure that the token is valid for a particular context. There are many pitfalls with this process, and this chapter provides specific details of the mechanisms that applications should have in place to prevent them. + +## V9.1 Token source and integrity + +This section includes requirements to ensure that the token has been produced by a trusted party and has not been tampered with. + +| # | Description | Level | +| :---: | :--- | :---: | +| **9.1.1** | Verify that self-contained tokens are validated using their digital signature or MAC to protect against tampering before accepting the token's contents. | 1 | +| **9.1.2** | Verify that only algorithms on an allowlist can be used to create and verify self-contained tokens, for a given context. The allowlist must include the permitted algorithms, ideally only either symmetric or asymmetric algorithms, and must not include the 'None' algorithm. If both symmetric and asymmetric must be supported, additional controls will be needed to prevent key confusion. | 1 | +| **9.1.3** | Verify that key material that is used to validate self-contained tokens is from trusted pre-configured sources for the token issuer, preventing attackers from specifying untrusted sources and keys. For JWTs and other JWS structures, headers such as 'jku', 'x5u', and 'jwk' must be validated against an allowlist of trusted sources. | 1 | + +## V9.2 Token content + +Before making security decisions based on the content of a self-contained token, it is necessary to validate that the token has been presented within its validity period and that it is intended for use by the receiving service and for the purpose for which it was presented. This helps avoid insecure cross-usage between different services or with different token types from the same issuer. + +Specific requirements for OAuth and OIDC are covered in the dedicated chapter. + +| # | Description | Level | +| :---: | :--- | :---: | +| **9.2.1** | Verify that, if a validity time span is present in the token data, the token and its content are accepted only if the verification time is within this validity time span. For example, for JWTs, the claims 'nbf' and 'exp' must be verified. | 1 | +| **9.2.2** | Verify that the service receiving a token validates the token to be the correct type and is meant for the intended purpose before accepting the token's contents. For example, only access tokens can be accepted for authorization decisions and only ID Tokens can be used for proving user authentication. | 2 | +| **9.2.3** | Verify that the service only accepts tokens which are intended for use with that service (audience). For JWTs, this can be achieved by validating the 'aud' claim against an allowlist defined in the service. | 2 | +| **9.2.4** | Verify that, if a token issuer uses the same private key for issuing tokens to different audiences, the issued tokens contain an audience restriction that uniquely identifies the intended audiences. This will prevent a token from being reused with an unintended audience. If the audience identifier is dynamically provisioned, the token issuer must validate these audiences in order to make sure that they do not result in audience impersonation. | 2 | + +## References + +For more information, see also: + +* [OWASP JSON Web Token Cheat Sheet for Java Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.html) (but has useful general guidance) diff --git a/5.0/pt/0x19-V10-OAuth-and-OIDC.md b/5.0/pt/0x19-V10-OAuth-and-OIDC.md new file mode 100644 index 0000000000..e726216b4b --- /dev/null +++ b/5.0/pt/0x19-V10-OAuth-and-OIDC.md @@ -0,0 +1,169 @@ +# V10 OAuth and OIDC + +## Control Objective + +OAuth2 (referred to as OAuth in this chapter) is an industry-standard framework for delegated authorization. For example, using OAuth, a client application can obtain access to APIs (server resources) on a user's behalf, provided the user has authorized the client application to do so. + +By itself, OAuth is not designed for user authentication. The OpenID Connect (OIDC) framework extends OAuth by adding a user identity layer on top of OAuth. OIDC provides support for features including standardized user information, Single Sign-On (SSO), and session management. As OIDC is an extension of OAuth, the OAuth requirements in this chapter also apply to OIDC. + +The following roles are defined in OAuth: + +* The OAuth client is the application that attempts to obtain access to server resources (e.g., by calling an API using the issued access token). The OAuth client is often a server-side application. + * A confidential client is a client capable of maintaining the confidentiality of the credentials it uses to authenticate itself with the authorization server. + * A public client is not capable of maintaining the confidentiality of credentials for authenticating with the authorization server. Therefore, instead of authenticating itself (e.g., using 'client_id' and 'client_secret' parameters), it only identifies itself (using a 'client_id' parameter). +* The OAuth resource server (RS) is the server API exposing resources to OAuth clients. +* The OAuth authorization server (AS) is a server application that issues access tokens to OAuth clients. These access tokens allow OAuth clients to access RS resources, either on behalf of an end-user or on the OAuth client's own behalf. The AS is often a separate application, but (if appropriate) it may be integrated into a suitable RS. +* The resource owner (RO) is the end-user who authorizes OAuth clients to obtain limited access to resources hosted on the resource server on their behalf. The resource owner consents to this delegated authorization by interacting with the authorization server. + +The following roles are defined in OIDC: + +* The relying party (RP) is the client application requesting end-user authentication through the OpenID Provider. It assumes the role of an OAuth client. +* The OpenID Provider (OP) is an OAuth AS that is capable of authenticating the end-user and provides OIDC claims to an RP. The OP may be the identity provider (IdP), but in federated scenarios, the OP and the identity provider (where the end-user authenticates) may be different server applications. + +OAuth and OIDC were initially designed for third-party applications. Today, they are often used by first-party applications as well. However, when used in first-party scenarios, such as authentication and session management, the protocol adds some complexity, which may introduce new security challenges. + +OAuth and OIDC can be used for many types of applications, but the focus for ASVS and the requirements in this chapter is on web applications and APIs. + +Since OAuth and OIDC can be considered logic on top of web technologies, general requirements from other chapters always apply, and this chapter cannot be taken out of context. + +This chapter addresses best current practices for OAuth2 and OIDC aligned with specifications found at and . Even if RFCs are considered mature, they are updated frequently. Thus, it is important to align with the latest versions when applying the requirements in this chapter. See the references section for more details. + +Given the complexity of the area, it is vitally important for a secure OAuth or OIDC solution to use well-known industry-standard authorization servers and apply the recommended security configuration. + +Terminology used in this chapter aligns with OAuth RFCs and OIDC specifications, but note that OIDC terminology is only used for OIDC-specific requirements; otherwise, OAuth terminology is used. + +In the context of OAuth and OIDC, the term "token" in this chapter refers to: + +* Access tokens, which shall only be consumed by the RS and can either be reference tokens that are validated using introspection or self-contained tokens that are validated using some key material. +* Refresh tokens, which shall only be consumed by the authorization server that issued the token. +* OIDC ID Tokens, which shall only be consumed by the client that triggered the authorization flow. + +The risk levels for some of the requirements in this chapter depend on whether the client is a confidential client or regarded as a public client. Since using strong client authentication mitigates many attack vectors, a few requirements might be relaxed when using a confidential client for L1 applications. + +## V10.1 Generic OAuth and OIDC Security + +This section covers generic architectural requirements that apply to all applications using OAuth or OIDC. + +| # | Description | Level | +| :---: | :--- | :---: | +| **10.1.1** | Verify that tokens are only sent to components that strictly need them. For example, when using a backend-for-frontend pattern for browser-based JavaScript applications, access and refresh tokens shall only be accessible for the backend. | 2 | +| **10.1.2** | Verify that the client only accepts values from the authorization server (such as the authorization code or ID Token) if these values result from an authorization flow that was initiated by the same user agent session and transaction. This requires that client-generated secrets, such as the proof key for code exchange (PKCE) 'code_verifier', 'state' or OIDC 'nonce', are not guessable, are specific to the transaction, and are securely bound to both the client and the user agent session in which the transaction was started. | 2 | + +## V10.2 OAuth Client + +These requirements detail the responsibilities for OAuth client applications. The client can be, for example, a web server backend (often acting as a Backend For Frontend, BFF), a backend service integration, or a frontend Single Page Application (SPA, aka browser-based application). + +In general, backend clients are regarded as confidential clients and frontend clients are regarded as public clients. However, native applications running on the end-user device can be regarded as confidential when using OAuth dynamic client registration. + +| # | Description | Level | +| :---: | :--- | :---: | +| **10.2.1** | Verify that, if the code flow is used, the OAuth client has protection against browser-based request forgery attacks, commonly known as cross-site request forgery (CSRF), which trigger token requests, either by using proof key for code exchange (PKCE) functionality or checking the 'state' parameter that was sent in the authorization request. | 2 | +| **10.2.2** | Verify that, if the OAuth client can interact with more than one authorization server, it has a defense against mix-up attacks. For example, it could require that the authorization server return the 'iss' parameter value and validate it in the authorization response and the token response. | 2 | +| **10.2.3** | Verify that the OAuth client only requests the required scopes (or other authorization parameters) in requests to the authorization server. | 3 | + +## V10.3 OAuth Resource Server + +In the context of ASVS and this chapter, the resource server is an API. To provide secure access, the resource server must: + +* Validate the access token, according to the token format and relevant protocol specifications, e.g., JWT-validation or OAuth token introspection. +* If valid, enforce authorization decisions based on the information from the access token and permissions which have been granted. For example, the resource server needs to verify that the client (acting on behalf of RO) is authorized to access the requested resource. + +Therefore, the requirements listed here are OAuth or OIDC specific and should be performed after token validation and before performing authorization based on information from the token. + +| # | Description | Level | +| :---: | :--- | :---: | +| **10.3.1** | Verify that the resource server only accepts access tokens that are intended for use with that service (audience). The audience may be included in a structured access token (such as the 'aud' claim in JWT), or it can be checked using the token introspection endpoint. | 2 | +| **10.3.2** | Verify that the resource server enforces authorization decisions based on claims from the access token that define delegated authorization. If claims such as 'sub', 'scope', and 'authorization_details' are present, they must be part of the decision. | 2 | +| **10.3.3** | Verify that if an access control decision requires identifying a unique user from an access token (JWT or related token introspection response), the resource server identifies the user from claims that cannot be reassigned to other users. Typically, it means using a combination of 'iss' and 'sub' claims. | 2 | +| **10.3.4** | Verify that, if the resource server requires specific authentication strength, methods, or recentness, it verifies that the presented access token satisfies these constraints. For example, if present, using the OIDC 'acr', 'amr' and 'auth_time' claims respectively. | 2 | +| **10.3.5** | Verify that the resource server prevents the use of stolen access tokens or replay of access tokens (from unauthorized parties) by requiring sender-constrained access tokens, either Mutual TLS for OAuth 2 or OAuth 2 Demonstration of Proof of Possession (DPoP). | 3 | + +## V10.4 OAuth Authorization Server + +These requirements detail the responsibilities for OAuth authorization servers, including OpenID Providers. + +For client authentication, the 'self_signed_tls_client_auth' method is allowed with the prerequisites required by [section 2.2](https://datatracker.ietf.org/doc/html/rfc8705#name-self-signed-certificate-mut) of [RFC 8705](https://datatracker.ietf.org/doc/html/rfc8705). + +| # | Description | Level | +| :---: | :--- | :---: | +| **10.4.1** | Verify that the authorization server validates redirect URIs based on a client-specific allowlist of pre-registered URIs using exact string comparison. | 1 | +| **10.4.2** | Verify that, if the authorization server returns the authorization code in the authorization response, it can be used only once for a token request. For the second valid request with an authorization code that has already been used to issue an access token, the authorization server must reject a token request and revoke any issued tokens related to the authorization code. | 1 | +| **10.4.3** | Verify that the authorization code is short-lived. The maximum lifetime can be up to 10 minutes for L1 and L2 applications and up to 1 minute for L3 applications. | 1 | +| **10.4.4** | Verify that for a given client, the authorization server only allows the usage of grants that this client needs to use. Note that the grants 'token' (Implicit flow) and 'password' (Resource Owner Password Credentials flow) must no longer be used. | 1 | +| **10.4.5** | Verify that the authorization server mitigates refresh token replay attacks for public clients, preferably using sender-constrained refresh tokens, i.e., Demonstrating Proof of Possession (DPoP) or Certificate-Bound Access Tokens using mutual TLS (mTLS). For L1 and L2 applications, refresh token rotation may be used. If refresh token rotation is used, the authorization server must invalidate the refresh token after usage, and revoke all refresh tokens for that authorization if an already used and invalidated refresh token is provided. | 1 | +| **10.4.6** | Verify that, if the code grant is used, the authorization server mitigates authorization code interception attacks by requiring proof key for code exchange (PKCE). For authorization requests, the authorization server must require a valid 'code_challenge' value and must not accept a 'code_challenge_method' value of 'plain'. For a token request, it must require validation of the 'code_verifier' parameter. | 2 | +| **10.4.7** | Verify that if the authorization server supports unauthenticated dynamic client registration, it mitigates the risk of malicious client applications. It must validate client metadata such as any registered URIs, ensure the user's consent, and warn the user before processing an authorization request with an untrusted client application. | 2 | +| **10.4.8** | Verify that refresh tokens have an absolute expiration, including if sliding refresh token expiration is applied. | 2 | +| **10.4.9** | Verify that refresh tokens and reference access tokens can be revoked by an authorized user using the authorization server user interface, to mitigate the risk of malicious clients or stolen tokens. | 2 | +| **10.4.10** | Verify that confidential client is authenticated for client-to-authorized server backchannel requests such as token requests, pushed authorization requests (PAR), and token revocation requests. | 2 | +| **10.4.11** | Verify that the authorization server configuration only assigns the required scopes to the OAuth client. | 2 | +| **10.4.12** | Verify that for a given client, the authorization server only allows the 'response_mode' value that this client needs to use. For example, by having the authorization server validate this value against the expected values or by using pushed authorization request (PAR) or JWT-secured Authorization Request (JAR). | 3 | +| **10.4.13** | Verify that grant type 'code' is always used together with pushed authorization requests (PAR). | 3 | +| **10.4.14** | Verify that the authorization server issues only sender-constrained (Proof-of-Possession) access tokens, either with certificate-bound access tokens using mutual TLS (mTLS) or DPoP-bound access tokens (Demonstration of Proof of Possession). | 3 | +| **10.4.15** | Verify that, for a server-side client (which is not executed on the end-user device), the authorization server ensures that the 'authorization_details' parameter value is from the client backend and that the user has not tampered with it. For example, by requiring the usage of pushed authorization request (PAR) or JWT-secured Authorization Request (JAR). | 3 | +| **10.4.16** | Verify that the client is confidential and the authorization server requires the use of strong client authentication methods (based on public-key cryptography and resistant to replay attacks), such as mutual TLS ('tls_client_auth', 'self_signed_tls_client_auth') or private key JWT ('private_key_jwt'). | 3 | + +## V10.5 OIDC Client + +As the OIDC relying party acts as an OAuth client, the requirements from the section "OAuth Client" apply as well. + +Note that the "Authentication with an Identity Provider" section in the "Authentication" chapter also contains relevant general requirements. + +| # | Description | Level | +| :---: | :--- | :---: | +| **10.5.1** | Verify that the client (as the relying party) mitigates ID Token replay attacks. For example, by ensuring that the 'nonce' claim in the ID Token matches the 'nonce' value sent in the authentication request to the OpenID Provider (in OAuth2 refereed to as the authorization request sent to the authorization server). | 2 | +| **10.5.2** | Verify that the client uniquely identifies the user from ID Token claims, usually the 'sub' claim, which cannot be reassigned to other users (for the scope of an identity provider). | 2 | +| **10.5.3** | Verify that the client rejects attempts by a malicious authorization server to impersonate another authorization server through authorization server metadata. The client must reject authorization server metadata if the issuer URL in the authorization server metadata does not exactly match the pre-configured issuer URL expected by the client. | 2 | +| **10.5.4** | Verify that the client validates that the ID Token is intended to be used for that client (audience) by checking that the 'aud' claim from the token is equal to the 'client_id' value for the client. | 2 | +| **10.5.5** | Verify that, when using OIDC back-channel logout, the relying party mitigates denial of service through forced logout and cross-JWT confusion in the logout flow. The client must verify that the logout token is correctly typed with a value of 'logout+jwt', contains the 'event' claim with the correct member name, and does not contain a 'nonce' claim. Note that it is also recommended to have a short expiration (e.g., 2 minutes). | 2 | + +## V10.6 OpenID Provider + +As OpenID Providers act as OAuth authorization servers, the requirements from the section "OAuth Authorization Server" apply as well. + +Note that if using the ID Token flow (not the code flow), no access tokens are issued, and many of the requirements for OAuth AS are not applicable. + +| # | Description | Level | +| :---: | :--- | :---: | +| **10.6.1** | Verify that the OpenID Provider only allows values 'code', 'ciba', 'id_token', or 'id_token code' for response mode. Note that 'code' is preferred over 'id_token code' (the OIDC Hybrid flow), and 'token' (any Implicit flow) must not be used. | 2 | +| **10.6.2** | Verify that the OpenID Provider mitigates denial of service through forced logout. By obtaining explicit confirmation from the end-user or, if present, validating parameters in the logout request (initiated by the relying party), such as the 'id_token_hint'. | 2 | + +## V10.7 Consent Management + +These requirements cover the verification of the user's consent by the authorization server. Without proper user consent verification, a malicious actor may obtain permissions on the user's behalf through spoofing or social-engineering. + +| # | Description | Level | +| :---: | :--- | :---: | +| **10.7.1** | Verify that the authorization server ensures that the user consents to each authorization request. If the identity of the client cannot be assured, the authorization server must always explicitly prompt the user for consent. | 2 | +| **10.7.2** | Verify that when the authorization server prompts for user consent, it presents sufficient and clear information about what is being consented to. When applicable, this should include the nature of the requested authorizations (typically based on scope, resource server, Rich Authorization Requests (RAR) authorization details), the identity of the authorized application, and the lifetime of these authorizations. | 2 | +| **10.7.3** | Verify that the user can review, modify, and revoke consents which the user has granted through the authorization server. | 2 | + +## References + +For more information on OAuth, please see: + +* [oauth.net](https://oauth.net/) +* [OWASP OAuth 2.0 Protocol Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/OAuth2_Cheat_Sheet.html) + +For OAuth-related requirements in ASVS following published and in draft status RFC-s are used: + +* [RFC6749 The OAuth 2.0 Authorization Framework](https://datatracker.ietf.org/doc/html/rfc6749) +* [RFC6750 The OAuth 2.0 Authorization Framework: Bearer Token Usage](https://datatracker.ietf.org/doc/html/rfc6750) +* [RFC6819 OAuth 2.0 Threat Model and Security Considerations](https://datatracker.ietf.org/doc/html/rfc6819) +* [RFC7636 Proof Key for Code Exchange by OAuth Public Clients](https://datatracker.ietf.org/doc/html/rfc7636) +* [RFC7591 OAuth 2.0 Dynamic Client Registration Protocol](https://datatracker.ietf.org/doc/html/rfc7591) +* [RFC8628 OAuth 2.0 Device Authorization Grant](https://datatracker.ietf.org/doc/html/rfc8628) +* [RFC8707 Resource Indicators for OAuth 2.0](https://datatracker.ietf.org/doc/html/rfc8707) +* [RFC9068 JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens](https://datatracker.ietf.org/doc/html/rfc9068) +* [RFC9126 OAuth 2.0 Pushed Authorization Requests](https://datatracker.ietf.org/doc/html/rfc9126) +* [RFC9207 OAuth 2.0 Authorization Server Issuer Identification](https://datatracker.ietf.org/doc/html/rfc9207) +* [RFC9396 OAuth 2.0 Rich Authorization Requests](https://datatracker.ietf.org/doc/html/rfc9396) +* [RFC9449 OAuth 2.0 Demonstrating Proof of Possession (DPoP)](https://datatracker.ietf.org/doc/html/rfc9449) +* [RFC9700 Best Current Practice for OAuth 2.0 Security](https://datatracker.ietf.org/doc/html/rfc9700) +* [draft OAuth 2.0 for Browser-Based Applications](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps) +* [draft The OAuth 2.1 Authorization Framework](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-12) + +For more information on OpenID Connect, please see: + +* [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html) +* [FAPI 2.0 Security Profile](https://openid.net/specs/fapi-security-profile-2_0-final.html) diff --git a/5.0/pt/0x20-V11-Cryptography.md b/5.0/pt/0x20-V11-Cryptography.md new file mode 100644 index 0000000000..be70abcd6f --- /dev/null +++ b/5.0/pt/0x20-V11-Cryptography.md @@ -0,0 +1,107 @@ +# V11 Cryptography + +## Control Objective + +The objective of this chapter is to define best practices for the general use of cryptography, as well as to instill a fundamental understanding of cryptographic principles and inspire a shift toward more resilient and modern approaches. It encourages the following: + +* Implementing robust cryptographic systems that fail securely, adapt to evolving threats, and are future-proof. +* Utilizing cryptographic mechanisms that are both secure and aligned with industry best practices. +* Maintaining a secure cryptographic key management system with appropriate access controls and auditing. +* Regularly evaluating the cryptographic landscape to assess new risks and adapt algorithms accordingly. +* Discovering and managing cryptographic use cases throughout the application's lifecycle to ensure that all cryptographic assets are accounted for and secured. + +In addition to outlining general principles and best practices, this document also provides more in-depth technical information about the requirements in Appendix C - Cryptography Standards. This includes algorithms and modes that are considered "approved" for the purposes of the requirements in this chapter. + +Requirements that use cryptography to solve a separate problem, such as secrets management or communications security, will be in different parts of the standard. + +## V11.1 Cryptographic Inventory and Documentation + +Applications need to be designed with strong cryptographic architecture to protect data assets according to their classification. Encrypting everything is wasteful; not encrypting anything is legally negligent. A balance must be struck, usually during architectural or high-level design, design sprints, or architectural spikes. Designing cryptography "on the fly" or retrofitting it will inevitably cost much more to implement securely than simply building it in from the start. + +It is important to ensure that all cryptographic assets are regularly discovered, inventoried, and assessed. Please see the appendix for more information on how this can be done. + +The need to future-proof cryptographic systems against the eventual rise of quantum computing is also critical. Post-Quantum Cryptography (PQC) refers to cryptographic algorithms designed to remain secure against attacks by quantum computers, which are expected to break widely used algorithms such as RSA and elliptic curve cryptography (ECC). + +Please see the appendix for current guidance on vetted PQC primitives and standards. + +| # | Description | Level | +| :---: | :--- | :---: | +| **11.1.1** | Verify that there is a documented policy for management of cryptographic keys and a cryptographic key lifecycle that follows a key management standard such as NIST SP 800-57. This should include ensuring that keys are not overshared (for example, with more than two entities for shared secrets and more than one entity for private keys). | 2 | +| **11.1.2** | Verify that a cryptographic inventory is performed, maintained, regularly updated, and includes all cryptographic keys, algorithms, and certificates used by the application. It must also document where keys can and cannot be used in the system, and the types of data that can and cannot be protected using the keys. | 2 | +| **11.1.3** | Verify that cryptographic discovery mechanisms are employed to identify all instances of cryptography in the system, including encryption, hashing, and signing operations. | 3 | +| **11.1.4** | Verify that a cryptographic inventory is maintained. This must include a documented plan that outlines the migration path to new cryptographic standards, such as post-quantum cryptography, in order to react to future threats. | 3 | + +## V11.2 Secure Cryptography Implementation + +This section defines the requirements for the selection, implementation, and ongoing management of core cryptographic algorithms for an application. The objective is to ensure that only robust, industry-accepted cryptographic primitives are deployed, in alignment with current standards (e.g., NIST, ISO/IEC) and best practices. Organizations must ensure that each cryptographic component is selected based on peer-reviewed evidence and practical security testing. + +| # | Description | Level | +| :---: | :--- | :---: | +| **11.2.1** | Verify that industry-validated implementations (including libraries and hardware-accelerated implementations) are used for cryptographic operations. | 2 | +| **11.2.2** | Verify that the application is designed with crypto agility such that random number, authenticated encryption, MAC, or hashing algorithms, key lengths, rounds, ciphers and modes can be reconfigured, upgraded, or swapped at any time, to protect against cryptographic breaks. Similarly, it must also be possible to replace keys and passwords and re-encrypt data. This will allow for seamless upgrades to post-quantum cryptography (PQC), once high-assurance implementations of approved PQC schemes or standards are widely available. | 2 | +| **11.2.3** | Verify that all cryptographic primitives utilize a minimum of 128-bits of security based on the algorithm, key size, and configuration. For example, a 256-bit ECC key provides roughly 128 bits of security where RSA requires a 3072-bit key to achieve 128 bits of security. | 2 | +| **11.2.4** | Verify that all cryptographic operations are constant-time, with no 'short-circuit' operations in comparisons, calculations, or returns, to avoid leaking information. | 3 | +| **11.2.5** | Verify that all cryptographic modules fail securely, and errors are handled in a way that does not enable vulnerabilities, such as Padding Oracle attacks. | 3 | + +## V11.3 Encryption Algorithms + +Authenticated encryption algorithms built on AES and CHACHA20 form the backbone of modern cryptographic practice. + +| # | Description | Level | +| :---: | :--- | :---: | +| **11.3.1** | Verify that insecure block modes (e.g., ECB) and weak padding schemes (e.g., PKCS#1 v1.5) are not used. | 1 | +| **11.3.2** | Verify that only approved ciphers and modes such as AES with GCM are used. | 1 | +| **11.3.3** | Verify that encrypted data is protected against unauthorized modification preferably by using an approved authenticated encryption method or by combining an approved encryption method with an approved MAC algorithm. | 2 | +| **11.3.4** | Verify that nonces, initialization vectors, and other single-use numbers are not used for more than one encryption key and data-element pair. The method of generation must be appropriate for the algorithm being used. | 3 | +| **11.3.5** | Verify that any combination of an encryption algorithm and a MAC algorithm is operating in encrypt-then-MAC mode. | 3 | + +## V11.4 Hashing and Hash-based Functions + +Cryptographic hashes are used in a wide variety of cryptographic protocols, such as digital signatures, HMAC, key derivation functions (KDF), random bit generation, and password storage. The security of the cryptographic system is only as strong as the underlying hash functions used. This section outlines the requirements for using secure hash functions in cryptographic operations. + +For password storage, as well as the cryptography appendix, the [OWASP Password Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#password-hashing-algorithms) will also provide useful context and guidance. + +| # | Description | Level | +| :---: | :--- | :---: | +| **11.4.1** | Verify that only approved hash functions are used for general cryptographic use cases, including digital signatures, HMAC, KDF, and random bit generation. Disallowed hash functions, such as MD5, must not be used for any cryptographic purpose. | 1 | +| **11.4.2** | Verify that passwords are stored using an approved, computationally intensive, key derivation function (also known as a "password hashing function"), with parameter settings configured based on current guidance. The settings should balance security and performance to make brute-force attacks sufficiently challenging for the required level of security. | 2 | +| **11.4.3** | Verify that hash functions used in digital signatures, as part of data authentication or data integrity are collision resistant and have appropriate bit-lengths. If collision resistance is required, the output length must be at least 256 bits. If only resistance to second pre-image attacks is required, the output length must be at least 128 bits. | 2 | +| **11.4.4** | Verify that the application uses approved key derivation functions with key stretching parameters when deriving secret keys from passwords. The parameters in use must balance security and performance to prevent brute-force attacks from compromising the resulting cryptographic key. | 2 | + +## V11.5 Random Values + +Cryptographically secure Pseudo-random Number Generation (CSPRNG) is incredibly difficult to get right. Generally, good sources of entropy within a system will be quickly depleted if over-used, but sources with less randomness can lead to predictable keys and secrets. + +| # | Description | Level | +| :---: | :--- | :---: | +| **11.5.1** | Verify that all random numbers and strings which are intended to be non-guessable must be generated using a cryptographically secure pseudo-random number generator (CSPRNG) and have at least 128 bits of entropy. Note that UUIDs do not respect this condition. | 2 | +| **11.5.2** | Verify that the random number generation mechanism in use is designed to work securely, even under heavy demand. | 3 | + +## V11.6 Public Key Cryptography + +Public Key Cryptography will be used where it is not possible or not desirable to share a secret key between multiple parties. + +As part of this, there exists a need for approved key exchange mechanisms, such as Diffie-Hellman and Elliptic Curve Diffie-Hellman (ECDH) to ensure that the cryptosystem remains secure against modern threats. The "Secure Communication" chapter provides requirements for TLS so the requirements in this section are intended for situations where Public Key Cryptography is being used in use cases other than TLS. + +| # | Description | Level | +| :---: | :--- | :---: | +| **11.6.1** | Verify that only approved cryptographic algorithms and modes of operation are used for key generation and seeding, and digital signature generation and verification. Key generation algorithms must not generate insecure keys vulnerable to known attacks, for example, RSA keys which are vulnerable to Fermat factorization. | 2 | +| **11.6.2** | Verify that approved cryptographic algorithms are used for key exchange (such as Diffie-Hellman) with a focus on ensuring that key exchange mechanisms use secure parameters. This will prevent attacks on the key establishment process which could lead to adversary-in-the-middle attacks or cryptographic breaks. | 3 | + +## V11.7 In-Use Data Cryptography + +Protecting data while it is being processed is paramount. Techniques such as full memory encryption, encryption of data in transit, and ensuring data is encrypted as quickly as possible after use is recommended. + +| # | Description | Level | +| :---: | :--- | :---: | +| **11.7.1** | Verify that full memory encryption is in use that protects sensitive data while it is in use, preventing access by unauthorized users or processes. | 3 | +| **11.7.2** | Verify that data minimization ensures the minimal amount of data is exposed during processing, and ensure that data is encrypted immediately after use or as soon as feasible. | 3 | + +## References + +For more information, see also: + +* [OWASP Web Security Testing Guide: Testing for Weak Cryptography](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography) +* [OWASP Cryptographic Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html) +* [FIPS 140-3](https://csrc.nist.gov/pubs/fips/140-3/final) +* [NIST SP 800-57](https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final) diff --git a/5.0/pt/0x21-V12-Secure-Communication.md b/5.0/pt/0x21-V12-Secure-Communication.md new file mode 100644 index 0000000000..08013d3b6e --- /dev/null +++ b/5.0/pt/0x21-V12-Secure-Communication.md @@ -0,0 +1,57 @@ +# V12 Secure Communication + +## Control Objective + +This chapter includes requirements related to the specific mechanisms that should be in place to protect data in transit, both between an end-user client and a backend service, as well as between internal and backend services. + +The general concepts promoted by this chapter include: + +* Ensuring that communications are encrypted externally, and ideally internally as well. +* Configuring encryption mechanisms using the latest guidance, including preferred algorithms and ciphers. +* Ensuring that communications are not being intercepted by unauthorized parties through the use of signed certificates. + +In addition to outlining general principles and best practices, the ASVS also provides more in-depth technical information about cryptographic strength in Appendix C - Cryptography Standards. + +## V12.1 General TLS Security Guidance + +This section provides initial guidance on how to secure TLS communications. Up-to-date tools should be used to review TLS configuration on an ongoing basis. + +While the use of wildcard TLS certificates is not inherently insecure, a compromise of a certificate that is deployed across all owned environments (e.g., production, staging, development, and test) may lead to a compromise of the security posture of the applications using it. Proper protection, management, and the use of separate TLS certificates in different environments should be employed if possible. + +| # | Description | Level | +| :---: | :--- | :---: | +| **12.1.1** | Verify that only the latest recommended versions of the TLS protocol are enabled, such as TLS 1.2 and TLS 1.3. The latest version of the TLS protocol must be the preferred option. | 1 | +| **12.1.2** | Verify that only recommended cipher suites are enabled, with the strongest cipher suites set as preferred. L3 applications must only support cipher suites which provide forward secrecy. | 2 | +| **12.1.3** | Verify that the application validates that mTLS client certificates are trusted before using the certificate identity for authentication or authorization. | 2 | +| **12.1.4** | Verify that proper certification revocation, such as Online Certificate Status Protocol (OCSP) Stapling, is enabled and configured. | 3 | +| **12.1.5** | Verify that Encrypted Client Hello (ECH) is enabled in the application's TLS settings to prevent exposure of sensitive metadata, such as the Server Name Indication (SNI), during TLS handshake processes. | 3 | + +## V12.2 HTTPS Communication with External Facing Services + +Ensure all HTTP traffic to external-facing services which the application exposes is sent encrypted, with publicly trusted certificates. + +| # | Description | Level | +| :---: | :--- | :---: | +| **12.2.1** | Verify that TLS is used for all connectivity between a client and external facing, HTTP-based services, and does not fall back to insecure or unencrypted communications. | 1 | +| **12.2.2** | Verify that external facing services use publicly trusted TLS certificates. | 1 | + +## V12.3 General Service to Service Communication Security + +Server communications (both internal and external) involve more than just HTTP. Connections to and from other systems must also be secure, ideally using TLS. + +| # | Description | Level | +| :---: | :--- | :---: | +| **12.3.1** | Verify that an encrypted protocol such as TLS is used for all inbound and outbound connections to and from the application, including monitoring systems, management tools, remote access and SSH, middleware, databases, mainframes, partner systems, or external APIs. The server must not fall back to insecure or unencrypted protocols. | 2 | +| **12.3.2** | Verify that TLS clients validate certificates received before communicating with a TLS server. | 2 | +| **12.3.3** | Verify that TLS or another appropriate transport encryption mechanism used for all connectivity between internal, HTTP-based services within the application, and does not fall back to insecure or unencrypted communications. | 2 | +| **12.3.4** | Verify that TLS connections between internal services use trusted certificates. Where internally generated or self-signed certificates are used, the consuming service must be configured to only trust specific internal CAs and specific self-signed certificates. | 2 | +| **12.3.5** | Verify that services communicating internally within a system (intra-service communications) use strong authentication to ensure that each endpoint is verified. Strong authentication methods, such as TLS client authentication, must be employed to ensure identity, using public-key infrastructure and mechanisms that are resistant to replay attacks. For microservice architectures, consider using a service mesh to simplify certificate management and enhance security. | 3 | + +## References + +For more information, see also: + +* [OWASP - Transport Layer Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html) +* [Mozilla's Server Side TLS configuration guide](https://wiki.mozilla.org/Security/Server_Side_TLS) +* [Mozilla's tool to generate known good TLS configurations](https://ssl-config.mozilla.org/). +* [O-Saft - OWASP Project to validate TLS configuration](https://owasp.org/www-project-o-saft/) diff --git a/5.0/pt/0x22-V13-Configuration.md b/5.0/pt/0x22-V13-Configuration.md new file mode 100644 index 0000000000..9bac566a49 --- /dev/null +++ b/5.0/pt/0x22-V13-Configuration.md @@ -0,0 +1,68 @@ +# V13 Configuration + +## Control Objective + +The application's default configuration must be secure for use on the Internet. + +This chapter provides guidance on the various configurations necessary to achieve this, including those applied during development, build, and deployment. + +Topics covered include preventing data leakage, securely managing communication between components, and protecting secrets. + +## V13.1 Configuration Documentation + +This section outlines documentation requirements for how the application communicates with internal and external services, as well as techniques to prevent loss of availability due to service inaccessibility. It also addresses documentation related to secrets. + +| # | Description | Level | +| :---: | :--- | :---: | +| **13.1.1** | Verify that all communication needs for the application are documented. This must include external services which the application relies upon and cases where an end user might be able to provide an external location to which the application will then connect. | 2 | +| **13.1.2** | Verify that for each service the application uses, the documentation defines the maximum number of concurrent connections (e.g., connection pool limits) and how the application behaves when that limit is reached, including any fallback or recovery mechanisms, to prevent denial of service conditions. | 3 | +| **13.1.3** | Verify that the application documentation defines resource‑management strategies for every external system or service it uses (e.g., databases, file handles, threads, HTTP connections). This should include resource‑release procedures, timeout settings, failure handling, and where retry logic is implemented, specifying retry limits, delays, and back‑off algorithms. For synchronous HTTP request–response operations it should mandate short timeouts and either disable retries or strictly limit retries to prevent cascading delays and resource exhaustion. | 3 | +| **13.1.4** | Verify that the application's documentation defines the secrets that are critical for the security of the application and a schedule for rotating them, based on the organization's threat model and business requirements. | 3 | + +## V13.2 Backend Communication Configuration + +Applications interact with multiple services, including APIs, databases, or other components. These may be considered internal to the application but not included in the application's standard access control mechanisms, or they may be entirely external. In either case, it is necessary to configure the application to interact securely with these components and, if required, protect that configuration. + +Note: The "Secure Communication" chapter provides guidance for encryption in transit. + +| # | Description | Level | +| :---: | :--- | :---: | +| **13.2.1** | Verify that communications between backend application components that don't support the application's standard user session mechanism, including APIs, middleware, and data layers, are authenticated. Authentication must use individual service accounts, short-term tokens, or certificate-based authentication and not unchanging credentials such as passwords, API keys, or shared accounts with privileged access. | 2 | +| **13.2.2** | Verify that communications between backend application components, including local or operating system services, APIs, middleware, and data layers, are performed with accounts assigned the least necessary privileges. | 2 | +| **13.2.3** | Verify that if a credential has to be used for service authentication, the credential being used by the consumer is not a default credential (e.g., root/root or admin/admin). | 2 | +| **13.2.4** | Verify that an allowlist is used to define the external resources or systems with which the application is permitted to communicate (e.g., for outbound requests, data loads, or file access). This allowlist can be implemented at the application layer, web server, firewall, or a combination of different layers. | 2 | +| **13.2.5** | Verify that the web or application server is configured with an allowlist of resources or systems to which the server can send requests or load data or files from. | 2 | +| **13.2.6** | Verify that where the application connects to separate services, it follows the documented configuration for each connection, such as maximum parallel connections, behavior when maximum allowed connections is reached, connection timeouts, and retry strategies. | 3 | + +## V13.3 Secret Management + +Secret management is an essential configuration task to ensure the protection of data used in the application. Specific requirements for cryptography can be found in the "Cryptography" chapter, but this section focuses on the management and handling aspects of secrets. + +| # | Description | Level | +| :---: | :--- | :---: | +| **13.3.1** | Verify that a secrets management solution, such as a key vault, is used to securely create, store, control access to, and destroy backend secrets. These could include passwords, key material, integrations with databases and third-party systems, keys and seeds for time-based tokens, other internal secrets, and API keys. Secrets must not be included in application source code or included in build artifacts. For an L3 application, this must involve a hardware-backed solution such as an HSM. | 2 | +| **13.3.2** | Verify that access to secret assets adheres to the principle of least privilege. | 2 | +| **13.3.3** | Verify that all cryptographic operations are performed using an isolated security module (such as a vault or hardware security module) to securely manage and protect key material from exposure outside of the security module. | 3 | +| **13.3.4** | Verify that secrets are configured to expire and be rotated based on the application's documentation. | 3 | + +## V13.4 Unintended Information Leakage + +Production configurations should be hardened to avoid disclosing unnecessary data. Many of these issues are rarely rated as significant risks but are often chained with other vulnerabilities. If these issues are not present by default, it raises the bar for attacking an application. + +For example, hiding the version of server-side components does not eliminate the need to patch all components, and disabling folder listing does not remove the need to use authorization controls or keep files away from the public folder, but it raises the bar. + +| # | Description | Level | +| :---: | :--- | :---: | +| **13.4.1** | Verify that the application is deployed either without any source control metadata, including the .git or .svn folders, or in a way that these folders are inaccessible both externally and to the application itself. | 1 | +| **13.4.2** | Verify that debug modes are disabled for all components in production environments to prevent exposure of debugging features and information leakage. | 2 | +| **13.4.3** | Verify that web servers do not expose directory listings to clients unless explicitly intended. | 2 | +| **13.4.4** | Verify that using the HTTP TRACE method is not supported in production environments, to avoid potential information leakage. | 2 | +| **13.4.5** | Verify that documentation (such as for internal APIs) and monitoring endpoints are not exposed unless explicitly intended. | 2 | +| **13.4.6** | Verify that the application does not expose detailed version information of backend components. | 3 | +| **13.4.7** | Verify that the web tier is configured to only serve files with specific file extensions to prevent unintentional information, configuration, and source code leakage. | 3 | + +## References + +For more information, see also: + +* [OWASP Web Security Testing Guide: Configuration and Deployment Management Testing](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing) diff --git a/5.0/pt/0x23-V14-Data-Protection.md b/5.0/pt/0x23-V14-Data-Protection.md new file mode 100644 index 0000000000..1d56e04835 --- /dev/null +++ b/5.0/pt/0x23-V14-Data-Protection.md @@ -0,0 +1,60 @@ +# V14 Data Protection + +## Control Objective + +Applications cannot account for all usage patterns and user behaviors, and should therefore implement controls to limit unauthorized access to sensitive data on client devices. + +This chapter includes requirements related to defining what data needs to be protected, how it should be protected, and specific mechanisms to implement or pitfalls to avoid. + +Another consideration for data protection is bulk extraction, modification, or excessive usage. Each system's requirements are likely to be very different, so determining what is "abnormal" must consider the threat model and business risk. From an ASVS perspective, detecting these issues is handled in the "Security Logging and Error Handling" chapter, and setting limits is handled in the "Validation and Business Logic" chapter. + +## V14.1 Data Protection Documentation + +A key prerequisite for being able to protect data is to categorize what data should be considered sensitive. There are likely to be several different levels of sensitivity, and for each level, the controls required to protect data at that level will be different. + +There are various privacy regulations and laws that affect how applications must approach the storage, use, and transmission of sensitive personal information. This section no longer tries to duplicate these types of data protection or privacy legislation, but rather focuses on key technical considerations for protecting sensitive data. Please consult local laws and regulations, and consult a qualified privacy specialist or lawyer as required. + +| # | Description | Level | +| :---: | :--- | :---: | +| **14.1.1** | Verify that all sensitive data created and processed by the application has been identified and classified into protection levels. This includes data that is only encoded and therefore easily decoded, such as Base64 strings or the plaintext payload inside a JWT. Protection levels need to take into account any data protection and privacy regulations and standards which the application is required to comply with. | 2 | +| **14.1.2** | Verify that all sensitive data protection levels have a documented set of protection requirements. This must include (but not be limited to) requirements related to general encryption, integrity verification, retention, how the data is to be logged, access controls around sensitive data in logs, database-level encryption, privacy and privacy-enhancing technologies to be used, and other confidentiality requirements. | 2 | + +## V14.2 General Data Protection + +This section contains various practical requirements related to the protection of data. Most are specific to particular issues such as unintended data leakage, but there is also a general requirement to implement protection controls based on the protection level required for each data item. + +| # | Description | Level | +| :---: | :--- | :---: | +| **14.2.1** | Verify that sensitive data is only sent to the server in the HTTP message body or header fields, and that the URL and query string do not contain sensitive information, such as an API key or session token. | 1 | +| **14.2.2** | Verify that the application prevents sensitive data from being cached in server components, such as load balancers and application caches, or ensures that the data is securely purged after use. | 2 | +| **14.2.3** | Verify that defined sensitive data is not sent to untrusted parties (e.g., user trackers) to prevent unwanted collection of data outside of the application's control. | 2 | +| **14.2.4** | Verify that controls around sensitive data related to encryption, integrity verification, retention, how the data is to be logged, access controls around sensitive data in logs, privacy and privacy-enhancing technologies, are implemented as defined in the documentation for the specific data's protection level. | 2 | +| **14.2.5** | Verify that caching mechanisms are configured to only cache responses which have the expected content type for that resource and do not contain sensitive, dynamic content. The web server should return a 404 or 302 response when a non-existent file is accessed rather than returning a different, valid file. This should prevent Web Cache Deception attacks. | 3 | +| **14.2.6** | Verify that the application only returns the minimum required sensitive data for the application's functionality. For example, only returning some of the digits of a credit card number and not the full number. If the complete data is required, it should be masked in the user interface unless the user specifically views it. | 3 | +| **14.2.7** | Verify that sensitive information is subject to data retention classification, ensuring that outdated or unnecessary data is deleted automatically, on a defined schedule, or as the situation requires. | 3 | +| **14.2.8** | Verify that sensitive information is removed from the metadata of user-submitted files unless storage is consented to by the user. | 3 | + +## V14.3 Client-side Data Protection + +This section contains requirements preventing data from leaking in specific ways at the client or user agent side of an application. + +| # | Description | Level | +| :---: | :--- | :---: | +| **14.3.1** | Verify that authenticated data is cleared from client storage, such as the browser DOM, after the client or session is terminated. The 'Clear-Site-Data' HTTP response header field may be able to help with this but the client-side should also be able to clear up if the server connection is not available when the session is terminated. | 1 | +| **14.3.2** | Verify that the application sets sufficient anti-caching HTTP response header fields (i.e., Cache-Control: no-store) so that sensitive data is not cached in browsers. | 2 | +| **14.3.3** | Verify that data stored in browser storage (such as localStorage, sessionStorage, IndexedDB, or cookies) does not contain sensitive data, with the exception of session tokens. | 2 | + +## References + +For more information, see also: + +* [Consider using the Security Headers website to check security and anti-caching header fields](https://securityheaders.com/) +* [Documentation about anti-caching headers by Mozilla](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching) +* [OWASP Secure Headers project](https://owasp.org/www-project-secure-headers/) +* [OWASP Privacy Risks Project](https://owasp.org/www-project-top-10-privacy-risks/) +* [OWASP User Privacy Protection Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/User_Privacy_Protection_Cheat_Sheet.html) +* [Australian Privacy Principle 11 - Security of personal information](https://www.oaic.gov.au/privacy/australian-privacy-principles/australian-privacy-principles-guidelines/chapter-11-app-11-security-of-personal-information) +* [European Union General Data Protection Regulation (GDPR) overview](https://www.edps.europa.eu/data-protection_en) +* [European Union Data Protection Supervisor - Internet Privacy Engineering Network](https://www.edps.europa.eu/data-protection/ipen-internet-privacy-engineering-network_en) +* [Information on the "Clear-Site-Data" header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Clear-Site-Data) +* [White paper on Web Cache Deception](https://www.blackhat.com/docs/us-17/wednesday/us-17-Gil-Web-Cache-Deception-Attack-wp.pdf) diff --git a/5.0/pt/0x24-V15-Secure-Coding-and-Architecture.md b/5.0/pt/0x24-V15-Secure-Coding-and-Architecture.md new file mode 100644 index 0000000000..4f8ee500f3 --- /dev/null +++ b/5.0/pt/0x24-V15-Secure-Coding-and-Architecture.md @@ -0,0 +1,77 @@ +# V15 Secure Coding and Architecture + +## Control Objective + +Many ASVS requirements either relate to a particular area of security, such as authentication or authorization, or pertain to a particular type of application functionality, such as logging or file handling. + +This chapter provides general security requirements to consider when designing and developing applications. These requirements focus not only on clean architecture and code quality but also on specific architecture and coding practices necessary for application security. + +## V15.1 Secure Coding and Architecture Documentation + +Many requirements for establishing a secure and defensible architecture depend on clear documentation of decisions made regarding the implementation of specific security controls and the components used within the application. + +This section outlines the documentation requirements, including identifying components considered to contain "dangerous functionality" or to be "risky components." + +A component with "dangerous functionality" may be an internally developed or third-party component that performs operations such as deserialization of untrusted data, raw file or binary data parsing, dynamic code execution, or direct memory manipulation. Vulnerabilities in these types of operations pose a high risk of compromising the application and potentially exposing its underlying infrastructure. + +A "risky component" is a 3rd party library (i.e., not internally developed) with missing or poorly implemented security controls around its development processes or functionality. Examples include components that are poorly maintained, unsupported, at the end-of-life stage, or have a history of significant vulnerabilities. + +This section also emphasizes the importance of defining appropriate timeframes for addressing vulnerabilities in third-party components. + +| # | Description | Level | +| :---: | :--- | :---: | +| **15.1.1** | Verify that application documentation defines risk based remediation time frames for 3rd party component versions with vulnerabilities and for updating libraries in general, to minimize the risk from these components. | 1 | +| **15.1.2** | Verify that an inventory catalog, such as software bill of materials (SBOM), is maintained of all third-party libraries in use, including verifying that components come from pre-defined, trusted, and continually maintained repositories. | 2 | +| **15.1.3** | Verify that the application documentation identifies functionality which is time-consuming or resource-demanding. This must include how to prevent a loss of availability due to overusing this functionality and how to avoid a situation where building a response takes longer than the consumer's timeout. Potential defenses may include asynchronous processing, using queues, and limiting parallel processes per user and per application. | 2 | +| **15.1.4** | Verify that application documentation highlights third-party libraries which are considered to be "risky components". | 3 | +| **15.1.5** | Verify that application documentation highlights parts of the application where "dangerous functionality" is being used. | 3 | + +## V15.2 Security Architecture and Dependencies + +This section includes requirements for handling risky, outdated, or insecure dependencies and components through dependency management. + +It also includes using architectural-level techniques such as sandboxing, encapsulation, containerization, and network isolation to reduce the impact of using "dangerous operations" or "risky components" (as defined in the previous section) and prevent loss of availability due to overusing resource-demanding functionality. + +| # | Description | Level | +| :---: | :--- | :---: | +| **15.2.1** | Verify that the application only contains components which have not breached the documented update and remediation time frames. | 1 | +| **15.2.2** | Verify that the application has implemented defenses against loss of availability due to functionality which is time-consuming or resource-demanding, based on the documented security decisions and strategies for this. | 2 | +| **15.2.3** | Verify that the production environment only includes functionality that is required for the application to function, and does not expose extraneous functionality such as test code, sample snippets, and development functionality. | 2 | +| **15.2.4** | Verify that third-party components and all of their transitive dependencies are included from the expected repository, whether internally owned or an external source, and that there is no risk of a dependency confusion attack. | 3 | +| **15.2.5** | Verify that the application implements additional protections around parts of the application which are documented as containing "dangerous functionality" or using third-party libraries considered to be "risky components". This could include techniques such as sandboxing, encapsulation, containerization or network level isolation to delay and deter attackers who compromise one part of an application from pivoting elsewhere in the application. | 3 | + +## V15.3 Defensive Coding + +This section covers vulnerability types, including type juggling, prototype pollution, and others, which result from using insecure coding patterns in a particular language. Some may not be relevant to all languages, whereas others will have language-specific fixes or may relate to how a particular language or framework handles a feature such as HTTP parameters. It also considers the risk of not cryptographically validating application updates. + +It also considers the risks associated with using objects to represent data items and accepting and returning these via external APIs. In this case, the application must ensure that data fields that should not be writable are not modified by user input (mass assignment) and that the API is selective about what data fields get returned. Where field access depends on a user's permissions, this should be considered in the context of the field-level access control requirement in the Authorization chapter. + +| # | Description | Level | +| :---: | :--- | :---: | +| **15.3.1** | Verify that the application only returns the required subset of fields from a data object. For example, it should not return an entire data object, as some individual fields should not be accessible to users. | 1 | +| **15.3.2** | Verify that where the application backend makes calls to external URLs, it is configured to not follow redirects unless it is intended functionality. | 2 | +| **15.3.3** | Verify that the application has countermeasures to protect against mass assignment attacks by limiting allowed fields per controller and action, e.g., it is not possible to insert or update a field value when it was not intended to be part of that action. | 2 | +| **15.3.4** | Verify that all proxying and middleware components transfer the user's original IP address correctly using trusted data fields that cannot be manipulated by the end user, and the application and web server use this correct value for logging and security decisions such as rate limiting, taking into account that even the original IP address may not be reliable due to dynamic IPs, VPNs, or corporate firewalls. | 2 | +| **15.3.5** | Verify that the application explicitly ensures that variables are of the correct type and performs strict equality and comparator operations. This is to avoid type juggling or type confusion vulnerabilities caused by the application code making an assumption about a variable type. | 2 | +| **15.3.6** | Verify that JavaScript code is written in a way that prevents prototype pollution, for example, by using Set() or Map() instead of object literals. | 2 | +| **15.3.7** | Verify that the application has defenses against HTTP parameter pollution attacks, particularly if the application framework makes no distinction about the source of request parameters (query string, body parameters, cookies, or header fields). | 2 | + +## V15.4 Safe Concurrency + +Concurrency issues such as race conditions, time-of-check to time-of-use (TOCTOU) vulnerabilities, deadlocks, livelocks, thread starvation, and improper synchronization can lead to unpredictable behavior and security risks. This section includes various techniques and strategies to help mitigate these risks. + +| # | Description | Level | +| :---: | :--- | :---: | +| **15.4.1** | Verify that shared objects in multi-threaded code (such as caches, files, or in-memory objects accessed by multiple threads) are accessed safely by using thread-safe types and synchronization mechanisms like locks or semaphores to avoid race conditions and data corruption. | 3 | +| **15.4.2** | Verify that checks on a resource's state, such as its existence or permissions, and the actions that depend on them are performed as a single atomic operation to prevent time-of-check to time-of-use (TOCTOU) race conditions. For example, checking if a file exists before opening it, or verifying a user’s access before granting it. | 3 | +| **15.4.3** | Verify that locks are used consistently to avoid threads getting stuck, whether by waiting on each other or retrying endlessly, and that locking logic stays within the code responsible for managing the resource to ensure locks cannot be inadvertently or maliciously modified by external classes or code. | 3 | +| **15.4.4** | Verify that resource allocation policies prevent thread starvation by ensuring fair access to resources, such as by leveraging thread pools, allowing lower-priority threads to proceed within a reasonable timeframe. | 3 | + +## References + +For more information, see also: + +* [OWASP Prototype Pollution Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Prototype_Pollution_Prevention_Cheat_Sheet.html) +* [OWASP Mass Assignment Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Mass_Assignment_Cheat_Sheet.html) +* [OWASP CycloneDX Bill of Materials Specification](https://owasp.org/www-project-cyclonedx/) +* [OWASP Web Security Testing Guide: Testing for HTTP Parameter Pollution](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/07-Input_Validation_Testing/04-Testing_for_HTTP_Parameter_Pollution) diff --git a/5.0/pt/0x25-V16-Security-Logging-and-Error-Handling.md b/5.0/pt/0x25-V16-Security-Logging-and-Error-Handling.md new file mode 100644 index 0000000000..4c55c9c4e7 --- /dev/null +++ b/5.0/pt/0x25-V16-Security-Logging-and-Error-Handling.md @@ -0,0 +1,84 @@ +# V16 Security Logging and Error Handling + +## Control Objective + +Security logs are distinct from error or performance logs and are used to record security-relevant events such as authentication decisions, access control decisions, and attempts to bypass security controls, such as input validation or business logic validation. Their purpose is to support detection, response, and investigation by providing high-signal, structured data for analysis tools like SIEMs. + +Logs should not include sensitive personal data unless legally required, and any logged data must be protected as a high-value asset. Logging must not compromise privacy or system security. Applications must also fail securely, avoiding unnecessary disclosure or disruption. + +For detailed implementation guidance, refer to the OWASP Cheat Sheets in the references section. + +## V16.1 Security Logging Documentation + +This section ensures a clear and complete inventory of logging across the application stack. This is essential for effective security monitoring, incident response, and compliance. + +| # | Description | Level | +| :---: | :--- | :---: | +| **16.1.1** | Verify that an inventory exists documenting the logging performed at each layer of the application's technology stack, what events are being logged, log formats, where that logging is stored, how it is used, how access to it is controlled, and for how long logs are kept. | 2 | + +## V16.2 General Logging + +This section provides requirements to ensure that security logs are consistently structured and contain the expected metadata. The goal is to make logs machine-readable and analyzable across distributed systems and tools. + +Naturally, security events often involve sensitive data. If such data is logged without consideration, the logs themselves become classified and therefore subject to encryption requirements, stricter retention policies, and potential disclosure during audits. + +Therefore, it is critical to log only what is necessary and to treat log data with the same care as other sensitive assets. + +The requirements below establish foundational requirements for logging metadata, synchronization, format, and control. + +| # | Description | Level | +| :---: | :--- | :---: | +| **16.2.1** | Verify that each log entry includes necessary metadata (such as when, where, who, what) that would allow for a detailed investigation of the timeline when an event happens. | 2 | +| **16.2.2** | Verify that time sources for all logging components are synchronized, and that timestamps in security event metadata use UTC or include an explicit time zone offset. UTC is recommended to ensure consistency across distributed systems and to prevent confusion during daylight saving time transitions. | 2 | +| **16.2.3** | Verify that the application only stores or broadcasts logs to the files and services that are documented in the log inventory. | 2 | +| **16.2.4** | Verify that logs can be read and correlated by the log processor that is in use, preferably by using a common logging format. | 2 | +| **16.2.5** | Verify that when logging sensitive data, the application enforces logging based on the data's protection level. For example, it may not be allowed to log certain data, such as credentials or payment details. Other data, such as session tokens, may only be logged by being hashed or masked, either in full or partially. | 2 | + +## V16.3 Security Events + +This section defines requirements for logging security-relevant events within the application. Capturing these events is critical for detecting suspicious behavior, supporting investigations, and fulfilling compliance obligations. + +This section outlines the types of events that should be logged but does not attempt to provide exhaustive detail. Each application has unique risk factors and operational context. + +Note that while ASVS includes logging of security events in scope, alerting and correlation (e.g., SIEM rules or monitoring infrastructure) are considered out of scope and are handled by operational and monitoring systems. + +| # | Description | Level | +| :---: | :--- | :---: | +| **16.3.1** | Verify that all authentication operations are logged, including successful and unsuccessful attempts. Additional metadata, such as the type of authentication or factors used, should also be collected. | 2 | +| **16.3.2** | Verify that failed authorization attempts are logged. For L3, this must include logging all authorization decisions, including logging when sensitive data is accessed (without logging the sensitive data itself). | 2 | +| **16.3.3** | Verify that the application logs the security events that are defined in the documentation and also logs attempts to bypass the security controls, such as input validation, business logic, and anti-automation. | 2 | +| **16.3.4** | Verify that the application logs unexpected errors and security control failures such as backend TLS failures. | 2 | + +## V16.4 Log Protection + +Logs are valuable forensic artifacts and must be protected. If logs can be easily modified or deleted, they lose their integrity and become unreliable for incident investigations or legal proceedings. Logs may expose internal application behavior or sensitive metadata, making them an attractive target for attackers. + +This section defines requirements to ensure that logs are protected from unauthorized access, tampering, and disclosure, and that they are safely transmitted and stored in secure, isolated systems. + +| # | Description | Level | +| :---: | :--- | :---: | +| **16.4.1** | Verify that all logging components appropriately encode data to prevent log injection. | 2 | +| **16.4.2** | Verify that logs are protected from unauthorized access and cannot be modified. | 2 | +| **16.4.3** | Verify that logs are securely transmitted to a logically separate system for analysis, detection, alerting, and escalation. The aim is to ensure that if the application is breached, the logs are not compromised. | 2 | + +## V16.5 Error Handling + +This section defines requirements to ensure that applications fail gracefully and securely without disclosing sensitive internal details. + +| # | Description | Level | +| :---: | :--- | :---: | +| **16.5.1** | Verify that a generic message is returned to the consumer when an unexpected or security-sensitive error occurs, ensuring no exposure of sensitive internal system data such as stack traces, queries, secret keys, and tokens. | 2 | +| **16.5.2** | Verify that the application continues to operate securely when external resource access fails, for example, by using patterns such as circuit breakers or graceful degradation. | 2 | +| **16.5.3** | Verify that the application fails gracefully and securely, including when an exception occurs, preventing fail-open conditions such as processing a transaction despite errors resulting from validation logic. | 2 | +| **16.5.4** | Verify that a "last resort" error handler is defined which will catch all unhandled exceptions. This is both to avoid losing error details that must go to log files and to ensure that an error does not take down the entire application process, leading to a loss of availability. | 3 | + +Note: Certain languages, (including Swift, Go, and through common design practice, many functional languages,) do not support exceptions or last-resort event handlers. In this case, architects and developers should use a pattern, language, or framework-friendly way to ensure that applications can securely handle exceptional, unexpected, or security-related events. + +## References + +For more information, see also: + +* [OWASP Web Security Testing Guide: Testing for Error Handling](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/README) +* [OWASP Authentication Cheat Sheet section about error messages](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html#authentication-and-error-messages) +* [OWASP Logging Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html) +* [OWASP Application Logging Vocabulary Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Vocabulary_Cheat_Sheet.html) diff --git a/5.0/pt/0x26-V17-WebRTC.md b/5.0/pt/0x26-V17-WebRTC.md new file mode 100644 index 0000000000..cf25614600 --- /dev/null +++ b/5.0/pt/0x26-V17-WebRTC.md @@ -0,0 +1,75 @@ +# V17 WebRTC + +## Control Objective + +Web Real-Time Communication (WebRTC) enables real-time voice, video, and data exchange in modern applications. As adoption increases, securing WebRTC infrastructure becomes critical. This section provides security requirements for stakeholders who develop, host, or integrate WebRTC systems. + +The WebRTC market can be broadly categorized into three segments: + +1. Product Developers: Proprietary and open-source vendors that create and supply WebRTC products and solutions. Their focus is on developing robust and secure WebRTC technologies that can be used by others. + +2. Communication Platforms as a Service (CPaaS): Providers that offer APIs, SDKs, and the necessary infrastructure or platforms to enable WebRTC functionalities. CPaaS providers may use products from the first category or develop their own WebRTC software to offer these services. + +3. Service Providers: Organizations that leverage products from product developers or CPaaS providers, or develop their own WebRTC solutions. They create and implement applications for online conferencing, healthcare, e-learning, and other domains where real-time communication is crucial. + +The security requirements outlined here are primarily focused on Product Developers, CPaaS, and Service Providers who: + +* Utilize open-source solutions to build their WebRTC applications. +* Use commercial WebRTC products as part of their infrastructure. +* Use internally developed WebRTC solutions or integrate various components into a cohesive service offering. + +It is important to note that these security requirements do not apply to developers who exclusively use SDKs and APIs provided by CPaaS vendors. For such developers, the CPaaS providers are typically responsible for most of the underlying security concerns within their platforms, and a generic security standard like ASVS may not fully address their needs. + +## V17.1 TURN Server + +This section defines security requirements for systems that operate their own TURN (Traversal Using Relays around NAT) servers. TURN servers assist in relaying media in restrictive network environments but can pose risks if misconfigured. These controls focus on secure address filtering and protection against resource exhaustion. + +| # | Description | Level | +| :---: | :--- | :---: | +| **17.1.1** | Verify that the Traversal Using Relays around NAT (TURN) service only allows access to IP addresses that are not reserved for special purposes (e.g., internal networks, broadcast, loopback). Note that this applies to both IPv4 and IPv6 addresses. | 2 | +| **17.1.2** | Verify that the Traversal Using Relays around NAT (TURN) service is not susceptible to resource exhaustion when legitimate users attempt to open a large number of ports on the TURN server. | 3 | + +## V17.2 Media + +These requirements only apply to systems that host their own WebRTC media servers, such as Selective Forwarding Units (SFUs), Multipoint Control Units (MCUs), recording servers, or gateway servers. Media servers handle and distribute media streams, making their security critical to protect communication between peers. Safeguarding media streams is paramount in WebRTC applications to prevent eavesdropping, tampering, and denial-of-service attacks that could compromise user privacy and communication quality. + +In particular, it is necessary to implement protections against flood attacks such as rate limiting, validating timestamps, using synchronized clocks to match real-time intervals, and managing buffers to prevent overflow and maintain proper timing. If packets for a particular media session arrive too quickly, excess packets should be dropped. It is also important to protect the system from malformed packets by implementing input validation, safely handling integer overflows, preventing buffer overflows, and employing other robust error-handling techniques. + +Systems that rely solely on peer-to-peer media communication between web browsers, without the involvement of intermediate media servers, are excluded from these specific media-related security requirements. + +This section refers to the use of Datagram Transport Layer Security (DTLS) in the context of WebRTC. A requirement related to having a documented policy for the management of cryptographic keys can be found in the "Cryptography" chapter. Information on approved cryptographic methods can be found either in the Cryptography Appendix of the ASVS or in documents such as NIST SP 800‑52 Rev. 2 or BSI TR‑02102‑2 (Version 2025‑01). + +| # | Description | Level | +| :---: | :--- | :---: | +| **17.2.1** | Verify that the key for the Datagram Transport Layer Security (DTLS) certificate is managed and protected based on the documented policy for management of cryptographic keys. | 2 | +| **17.2.2** | Verify that the media server is configured to use and support approved Datagram Transport Layer Security (DTLS) cipher suites and a secure protection profile for the DTLS Extension for establishing keys for the Secure Real-time Transport Protocol (DTLS-SRTP). | 2 | +| **17.2.3** | Verify that Secure Real-time Transport Protocol (SRTP) authentication is checked at the media server to prevent Real-time Transport Protocol (RTP) injection attacks from leading to either a Denial of Service condition or audio or video media insertion into media streams. | 2 | +| **17.2.4** | Verify that the media server is able to continue processing incoming media traffic when encountering malformed Secure Real-time Transport Protocol (SRTP) packets. | 2 | +| **17.2.5** | Verify that the media server is able to continue processing incoming media traffic during a flood of Secure Real-time Transport Protocol (SRTP) packets from legitimate users. | 3 | +| **17.2.6** | Verify that the media server is not susceptible to the "ClientHello" Race Condition vulnerability in Datagram Transport Layer Security (DTLS) by checking if the media server is publicly known to be vulnerable or by performing the race condition test. | 3 | +| **17.2.7** | Verify that any audio or video recording mechanisms associated with the media server are able to continue processing incoming media traffic during a flood of Secure Real-time Transport Protocol (SRTP) packets from legitimate users. | 3 | +| **17.2.8** | Verify that the Datagram Transport Layer Security (DTLS) certificate is checked against the Session Description Protocol (SDP) fingerprint attribute, terminating the media stream if the check fails, to ensure the authenticity of the media stream. | 3 | + +## V17.3 Signaling + +This section defines requirements for systems that operate their own WebRTC signaling servers. Signaling coordinates peer-to-peer communication and must be resilient against attacks that could disrupt session establishment or control. + +To ensure secure signaling, systems must handle malformed inputs gracefully and remain available under load. + +| # | Description | Level | +| :---: | :--- | :---: | +| **17.3.1** | Verify that the signaling server is able to continue processing legitimate incoming signaling messages during a flood attack. This should be achieved by implementing rate limiting at the signaling level. | 2 | +| **17.3.2** | Verify that the signaling server is able to continue processing legitimate signaling messages when encountering malformed signaling message that could cause a denial of service condition. This could include implementing input validation, safely handling integer overflows, preventing buffer overflows, and employing other robust error-handling techniques. | 2 | + +## References + +For more information, see also: + +* The WebRTC DTLS ClientHello DoS is best documented at [Enable Security's blog post aimed at security professionals](https://www.enablesecurity.com/blog/novel-dos-vulnerability-affecting-webrtc-media-servers/) and the associated [white paper aimed at WebRTC developers](https://www.enablesecurity.com/blog/webrtc-hello-race-conditions-paper/) +* [RFC 3550 - RTP: A Transport Protocol for Real-Time Applications](https://www.rfc-editor.org/rfc/rfc3550) +* [RFC 3711 - The Secure Real-time Transport Protocol (SRTP)](https://datatracker.ietf.org/doc/html/rfc3711) +* [RFC 5764 - Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP))](https://datatracker.ietf.org/doc/html/rfc5764) +* [RFC 8825 - Overview: Real-Time Protocols for Browser-Based Applications](https://www.rfc-editor.org/info/rfc8825) +* [RFC 8826 - Security Considerations for WebRTC](https://www.rfc-editor.org/info/rfc8826) +* [RFC 8827 - WebRTC Security Architecture](https://www.rfc-editor.org/info/rfc8827) +* [DTLS-SRTP Protection Profiles](https://www.iana.org/assignments/srtp-protection/srtp-protection.xhtml) diff --git a/5.0/pt/0x90-Appendix-A_Glossary.md b/5.0/pt/0x90-Appendix-A_Glossary.md new file mode 100644 index 0000000000..146baa7b95 --- /dev/null +++ b/5.0/pt/0x90-Appendix-A_Glossary.md @@ -0,0 +1,89 @@ +# Appendix A: Glossary + +* **Absolute Maximum Session Lifetime** – Also referred to as "Overall Timeout" by NIST, this is the maximal amount of time a session can remain active following authentication regardless of user interaction. This is a component of session expiration. +* **Allowlist** – A list of permitted data or operations, for example, a list of characters that are allowed to perform input validation. +* **Anti-forgery token** – A mechanism by which one or more tokens are passed in a request and validated by the application server to ensure that the request has come from an expected endpoint. +* **Application Security** – Application-level security focuses on the analysis of components that comprise the application layer of the Open Systems Interconnection Reference Model (OSI Model), rather than focusing on for example the underlying operating system or connected networks. +* **Application Security Verification** – The technical assessment of an application against the OWASP ASVS. +* **Application Security Verification Report** – A report that documents the overall results and supporting analysis produced by the verifier for a particular application. +* **Authentication** – The verification of the claimed identity of an application user. +* **Automated Verification** – The use of automated tools (either dynamic analysis tools, static analysis tools, or both) that use vulnerability signatures to find problems. +* **Black box testing** – A method of software testing that examines the functionality of an application without peering into its internal structures or workings. +* **Common Weakness Enumeration** (CWE) – A community-developed list of common software security weaknesses. It serves as a common language, a measuring stick for software security tools, and a baseline for weakness identification, mitigation, and prevention efforts. +* **Component** – A self-contained unit of code, with associated disk and network interfaces that communicates with other components. +* **Credential Service Provider** (CSP) – Also called an Identity Provider (IdP). A source of user data which may be used as an authentication source by other applications. +* **Cross-Site Script Inclusion** (XSSI) - A variant of Cross-Site Scripting (XSS) attack in which a web application retrieves malicious code from an external resource and includes that code as part of its own content. +* **Cross-Site Scripting** (XSS) – A security vulnerability typically found in web applications allowing the injection of client-side scripts into content. +* **Cryptographic module** – Hardware, software, and/or firmware that implements cryptographic algorithms and/or generates cryptographic keys. +* **Cryptographically secure pseudo-random number generator** (CSPRNG) - A pseudorandom number generator with properties that make it suitable for use in cryptography, also referred to as a cryptographic random number generator (CRNG). +* **Datagram Transport Layer Security** (DTLS) – A cryptographic protocol which provides communication security over a network connection. It is based on the TLS protocol but adapted for protecting datagram-oriented protocols (usually over UDP). Defined in RFC 9147 for DTLS 1.3. +* **Datagram Transport Layer Security Extension to Establish Keys for the Secure Real-time Transport Protocol** (DTLS-SRTP) – A mechanism for using a DTLS handshake for establishing key material for a SRTP session. Defined in RFC 5764. +* **Design Verification** – The technical assessment of the security architecture of an application. +* **Dynamic Application Security Testing** (DAST) – Technologies are designed to detect conditions indicative of a security vulnerability in an application in its running state. +* **Dynamic Verification** – The use of automated tools that use vulnerability signatures to find problems during the execution of an application. +* **Fast IDentity Online** (FIDO) – A set of authentication standards that allow a variety of different authentication methods to be used including biometrics, Trusted Platform Modules (TPMs), USB security tokens, etc. +* **Hardware Security Module** (HSM) – Hardware component that stores cryptographic keys and other secrets in a protected manner. +* **Hibernate Query Language** (HQL) – A query language that is similar in appearance to SQL used by the Hibernate ORM library. +* **HTTP Strict Transport Security** (HSTS) – An policy which instructs the browser to only connect to the domain returning the header via TLS and when a valid certificate is presented. It is activated using the Strict-Transport-Security response header field. +* **HyperText Transfer Protocol** (HTTP) – An application protocol for distributed, collaborative, hypermedia information systems. It is the foundation of data communication for the World Wide Web. +* **HyperText Transfer Protocol over SSL/TLS** (HTTPS) – A method of securing HTTP communication by encrypting it using Transport Layer Security (TLS). +* **Identity Provider** (IdP) – Also called a Credential Service Provider (CSP) in NIST references. An entity that provides an authentication source for other applications. +* **Inactivity Timeout** – This is the length of time a session can remain active in the absence of user interaction with the application. This is a component of session expiration. +* **Input Validation** – The canonicalization and validation of untrusted user input. +* **JSON Web Token** (JWT) – RFC 7519 defines a standard for a JSON data object made up of a header section which explains how to validate the object, a body section containing a set of claims, and a signature section which contains a digital signature which can be used to validate the contents of the body section. It is a type of self-contained token. +* **Local File Inclusion** (LFI) - An attack that exploits vulnerable file inclusion procedures in an application, leading to the inclusion of local files already present on the server. +* **Malicious Code** – Code introduced into an application during its development unbeknownst to the application owner, which circumvents the application's intended security policy. Not the same as malware such as a virus or worm! +* **Malware** – Executable code that is introduced into an application during runtime without the knowledge of the application user or administrator. +* **Message authentication code** (MAC) - A cryptographic checksum on data, computed by a MAC generation algorithm, that is used to provide assurance on its integrity and authenticity. +* **Multi-factor authentication** (MFA) – Authentication which includes two or more of the single factors. +* **Mutual TLS** (mTLS) – See TLS client authentication. +* **Object-relational Mapping** (ORM) – A system used to allow a relational/table-based database to be referenced and queried within an application program using an application-compatible object model. +* **One-time Password** (OTP) – A password that is uniquely generated to be used on a single occasion. +* **Open Worldwide Application Security Project** (OWASP) – The Open Worldwide Application Security Project (OWASP) is a worldwide free and open community focused on improving the security of application software. Our mission is to make application security "visible," so that people and organizations can make informed decisions about application security risks. See: [https://www.owasp.org/](https://www.owasp.org/). +* **Password-Based Key Derivation Function 2** (PBKDF2) – A special one-way algorithm used to create a strong cryptographic key from an input text (such as a password) and an additional random salt value and can therefore be used to make it harder to crack a password offline if the resulting value is stored instead of the original password. +* **Public Key Infrastructure** (PKI) – An arrangement that binds public keys with respective identities of entities. The binding is established through a process of registration and issuance of certificates at and by a certificate authority (CA). +* **Public Switched Telephone Network** (PSTN) – The traditional telephone network that includes both fixed-line telephones and mobile telephones. +* **Real-time Transport Protocol** (RTP) and **Real-time Transport Control Protocol** (RTCP) – Two protocols used in association for transporting multimedia streams. Used by the WebRTC stack. Defined in RFC 3550. +* **Reference Token** – A type of token that acts as a pointer or identifier to state or metadata stored on a server, sometimes referred to as random tokens or opaque tokens. Unlike self-contained tokens, which embed some of their relevant data within the token itself, reference tokens contain no intrinsic information, instead relying on the server for context. The reference token will either be or contain a session identifier. +* **Relying Party** (RP) – Generally an application which is relying on a user having authenticated against a separate authentication provider. The application relies on some sort of token or set of signed assertions provided by that authentication provider to trust that the user is who they say they are. +* **Remote File Inclusion** (RFI) - An attack that exploits vulnerable inclusion procedures in the application, resulting in the inclusion of remote files. +* **Scalable Vector Graphics** (SVG) – An XML-based markup language for describing two-dimensional based vector graphics. +* **Secure Real-time Transport Protocol** (SRTP) and **Secure Real-time Transport Control Protocol** (SRTCP) – A profile of the RTP and RTCP protocols providing support for message encryption, authentication and integrity protection. Defined in RFC 3711. +* **Security Architecture** – An abstraction of an application's design that identifies and describes where and how security controls are used, and also identifies and describes the location and sensitivity of both user and application data. +* **Security Assertion Markup Language** (SAML) – An open standard for single sign-on authentication based on passing signed assertions (usually XML objects) between the identity provider and the relying party. +* **Security Configuration** – The runtime configuration of an application that affects how security controls are used. +* **Security Control** – A function or component that performs a security check (e.g., an authorization check) or when called results in a security effect (e.g., generating an audit record). +* **Security information and event management** (SIEM) - A system for threat detection, compliance and security incident management through the collection and analysis of security-related data from various sources within an organization's IT infrastructure. +* **Self-Contained Token** – A token that encapsulates one or more attributes that do not rely on server-side state or other external storage. These tokens ensure the authenticity and integrity of their contained attributes, enabling secure, "stateless" information exchange across systems. Self-contained tokens are generally secured using cryptographic techniques, such as digital signatures or message authentication codes (MACs), to ensure the authenticity, integrity, and in some cases the confidentiality of its data. Common examples include SAML Assertions and JWTs. +* **Server-side Request Forgery** (SSRF) – An attack that abuses functionality on the server to read or update internal resources. The attacker supplies or modifies a URL, which the code running on the server will read or submit data to. +* **Session Description Protocol** (SDP) – A message format for setting up multimedia session (used for example in WebRTC). Defined in RFC 4566. +* **Session Identifier** or **Session ID** – A key which identifies a stateful session stored at the back end. Will be transfered to and from the client either as or inside a "Reference Token". +* **Session Token** – A "catch-all" phrase used in this standard to refer to the token or value used in either stateless session mechanisms (which use a self-contained token) or stateful session mechanisms (which use a reference token). +* **Session Traversal Utilities for NAT** (STUN) – A protocol used to assist NAT traversal in order to establish peer-to-peer communications. Defined in RFC 3489. +* **Single-factor authenticator** – A mechanism to check that a user is authenticated. It should either be something you know (memorized secrets, passwords, passphrases, PINs), something you are (biometrics, fingerprint, face scans), or something you have (OTP tokens, a cryptographic device such as a smart card). +* **Single Sign-on Authentication** (SSO) – This occurs when a user logs into one application and is then automatically logged into other applications without having to re-authenticate. For example, when logging into Google, the user will be automatically logged into other Google services such as YouTube, Google Docs, and Gmail. +* **Software bill of materials** (SBOM) - A structured, comprehensive list of all components, modules, libraries, frameworks and other resources required to build or assemble a software application. +* **Software Composition Analysis** (SCA) – A set of technologies designed to analyze application composition, dependencies, libraries and packages for security vulnerabilities of specific component versions in use. This is not to be confused with source-code analysis which is now commonly referred to as SAST. +* **Software development lifecycle** (SDLC) – The step-by-step process by which software is developed going from the initial requirements to deployment and maintenance. +* **SQL Injection** (SQLi) – A code injection technique used to attack data-driven applications, in which malicious SQL statements are inserted into an entry point. +* **Stateful Session Mechanism** – In a stateful session mechanism, the application retains session state at the backend which typically corresponds to a session token, generated using a cryptographically secure pseudo-random number generator (CSPRNG), which is issued to the end user. +* **Stateless Session Mechanism** – A stateless session mechanism will use a self-contained token which is passed to clients, and contains session information that is not necessarily stored within the service which then receives and validates the token. In reality, a service will need to have access to some session information (such as a JWT revocation list) in order to be able to enforce required security controls. +* **Static application security testing** (SAST) – A set of technologies designed to analyze application source code, byte code and binaries for coding and design conditions that are indicative of security vulnerabilities. SAST solutions analyze an application from the “inside out” in a nonrunning state. +* **Threat Modeling** – A technique consisting of developing increasingly refined security architectures to identify threat agents, security zones, security controls, and important technical and business assets. +* **Time-of-check to time-of-use** (TOCTOU) – A situation where an application checks the state of a resource before using that resource, but the resource's state can be changed between the check and the use. This can invalidate the results of the check and cause a situation where the application performs invalid actions due to this state mismatch. +* **Time based One-time Passwords** (TOTPs) - A method of generating an OTP where the current time acts as part of the algorithm to generate the password. +* **TLS client authentication**, also called **Mutual TLS** (mTLS) – In a standard TLS connection, a client can use the certificate provided by the server to validate the server's identity. Where TLS client authentication is used, the client also uses its own private key and certificate to allow the server to also validate the client's identity. +* **Transport Layer Security** (TLS) – Cryptographic protocols that provide communication security over a network connection. +* **Traversal Using Relays around NAT** (TURN) – An extension of the STUN protocol using a TURN server as a relay when direct peer-to-peer connections cannot be established. Defined in RFC 8656. +* **Trusted execution environment** (TEE) - An isolated processing environment in which applications can be securely executed irrespective of the rest of the system. +* **Trusted Platform Module** (TPM) – A type of HSM that is usually attached to a larger hardware component such as a motherboard and acts as the "root of trust" for that system. +* **Trusted Service Layer** – Any trusted control enforcement point, such as a microservice, serverless API, server-side, a trusted API on a client device that has secure boot, partner or external APIs, and so on. Trusted means that there is no concern that an untrusted user will be able to bypass or skip the layer or controls implemented at that layer. +* **Uniform Resource Identifier** (URI)- A unique string of characters that identifies a resource, such as webpage, mail address, places. +* **Uniform Resource Locator** (URL) – A string that specifies the location of resource on the Internet. +* **Universally Unique Identifier** (UUID) – A unique reference number used as an identifier in software. +* **Verifier** – The person or team that is reviewing an application against the OWASP ASVS requirements. +* **Web Real-Time Communication** (WebRTC) – A protocol stack and associated web API used for the transport of multimedia streams in web applications, usually in the context of teleconferencing. Based on SRTP, SRTCP, DTLS, SDP and STUN/TURN. +* **WebSocket over TLS** (WSS) – A practice of securing WebSocket communication by layering WebSocket over TLS protocol. +* **What You See Is What You Get** (WYSIWYG) – A type of rich content editor that shows how the content will actually look when rendered rather than showing the coding used to govern the rendering. +* **X.509 Certificate** – An X.509 certificate is a digital certificate that uses the widely accepted international X.509 public key infrastructure (PKI) standard to verify that a public key belongs to the user, computer or service identity contained within the certificate. +* **XML eXternal Entity** (XXE) – A type of XML entity that can access local or remote content via a declared system identifier. This may lead to various injection attacks. diff --git a/5.0/pt/0x91-Appendix-B_References.md b/5.0/pt/0x91-Appendix-B_References.md new file mode 100644 index 0000000000..a0fdd1babb --- /dev/null +++ b/5.0/pt/0x91-Appendix-B_References.md @@ -0,0 +1,43 @@ +# Appendix B: References + +The following OWASP projects are most likely to be useful to users/adopters of this standard: + +## OWASP Core Projects + +1. OWASP Top 10 Project: [https://owasp.org/www-project-top-ten/](https://owasp.org/www-project-top-ten/) +2. OWASP Web Security Testing Guide: [https://owasp.org/www-project-web-security-testing-guide/](https://owasp.org/www-project-web-security-testing-guide/) +3. OWASP Proactive Controls: [https://owasp.org/www-project-proactive-controls/](https://owasp.org/www-project-proactive-controls/) +4. OWASP Software Assurance Maturity Model (SAMM): [https://owasp.org/www-project-samm/](https://owasp.org/www-project-samm/) +5. OWASP Secure Headers Project: [https://owasp.org/www-project-secure-headers/](https://owasp.org/www-project-secure-headers/) + +## OWASP Cheat Sheet Series project + +[This project](https://owasp.org/www-project-cheat-sheets/) has several cheat sheets that will be relevant to different topics in the ASVS. + +There is a mapping to the ASVS which can be found here: [https://cheatsheetseries.owasp.org/IndexASVS.html](https://cheatsheetseries.owasp.org/IndexASVS.html) + +## Mobile Security Related Projects + +1. OWASP Mobile Security Project: [https://owasp.org/www-project-mobile-security/](https://owasp.org/www-project-mobile-security/) +2. OWASP Mobile Top 10 Risks: [https://owasp.org/www-project-mobile-top-10/](https://owasp.org/www-project-mobile-top-10/) +3. OWASP Mobile Security Testing Guide and Mobile Application Security Verification Standard: [https://owasp.org/www-project-mobile-security-testing-guide/](https://owasp.org/www-project-mobile-security-testing-guide/) + +## OWASP Internet of Things related projects + +1. OWASP Internet of Things Project: [https://owasp.org/www-project-internet-of-things/](https://owasp.org/www-project-internet-of-things/) + +## OWASP Serverless projects + +1. OWASP Serverless Project: [https://owasp.org/www-project-serverless-top-10/](https://owasp.org/www-project-serverless-top-10/) + +## Others + +Similarly, the following websites are most likely to be useful to users/adopters of this standard + +1. SecLists Github: [https://github.com/danielmiessler/SecLists](https://github.com/danielmiessler/SecLists) +2. MITRE Common Weakness Enumeration: [https://cwe.mitre.org/](https://cwe.mitre.org/) +3. PCI Security Standards Council: [https://www.pcisecuritystandards.org/](https://www.pcisecuritystandards.org/) +4. PCI Data Security Standard (DSS) v3.2.1 Requirements and Security Assessment Procedures: [https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf](https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf) +5. PCI Software Security Framework - Secure Software Requirements and Assessment Procedures: [https://www.pcisecuritystandards.org/documents/PCI-Secure-Software-Standard-v1_0.pdf](https://www.pcisecuritystandards.org/documents/PCI-Secure-Software-Standard-v1_0.pdf) +6. PCI Secure Software Lifecycle (Secure SLC) Requirements and Assessment Procedures: [https://www.pcisecuritystandards.org/documents/PCI-Secure-SLC-Standard-v1_0.pdf](https://www.pcisecuritystandards.org/documents/PCI-Secure-SLC-Standard-v1_0.pdf) +7. OWASP ASVS 4.0 Testing Guide [https://github.com/BlazingWind/OWASP-ASVS-4.0-testing-guide](https://github.com/BlazingWind/OWASP-ASVS-4.0-testing-guide) diff --git a/5.0/pt/0x92-Appendix-C_Cryptography.md b/5.0/pt/0x92-Appendix-C_Cryptography.md new file mode 100644 index 0000000000..93f5cebec4 --- /dev/null +++ b/5.0/pt/0x92-Appendix-C_Cryptography.md @@ -0,0 +1,311 @@ +# Appendix C: Cryptography Standards + +The "Cryptography" chapter goes beyond simply defining best practices. It aims to enhance understanding of cryptography principles and encourage the adoption of more resilient, modern security methods. This appendix provides detailed technical information regarding each requirement, complementing the overarching standards outlined in the "Cryptography" chapter. + +This appendix defines the level of approval for different cryptographic mechanisms: + +* Approved (A) mechanisms can be used in applications. +* Legacy mechanisms (L) should not be used in applications but might still be used for compatibility with existing legacy applications or code onyly. While the usage of such these mechanisms is currently not considered to be a vulnerability in itself, they should be replaced by more secure and future-proof mechanisms as soon as possible. +* Disallowed mechanisms (D) must not be used because they are currently considered broken or do not provide sufficient security. + +This list may be overridden in the context of a given application for various reasons including: + +* new evolutions in the field of cryptography; +* compliance with regulation. + +## Cryptographic Inventory and Documentation + +This section provides additional information +for V11.1 Cryptographic Inventory and Documentation. + +It is important to ensure that all cryptographic assets, such as algorithms, keys, and certificates, are regularly discovered, inventoried, and assessed. For Level 3, this should include the use of static and dynamic scanning to discover the use of cryptography in an application. Tools such as SAST and DAST may help with this but it is possible that dedicated tools would be needed to get more comprehensive coverage. Freeware examples of tools include: + +* [CryptoMon - Network Cryptography Monitor - using eBPF, written in python](https://github.com/Santandersecurityresearch/CryptoMon) +* [Cryptobom Forge Tool: Generating Comprehensive CBOMs from CodeQL Outputs](https://github.com/Santandersecurityresearch/cryptobom-forge) + +## Equivalent Strengths of Cryptographic Parameters + +The relative security strengths for various cryptographic systems are in this table (from [NIST SP 800-57 Part 1](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final), p.71): + +| Security Strength | Symmetric Key Algorithms | Finite Field | Integer Factorisation | Elliptic Curve | +|--|--|--|--|--| +| <= 80 | 2TDEA | L = 1024
N = 160 | k = 1024 | f = 160-223 | +| 112 | 3TDEA | L = 2048
N = 224 | k = 2048 | f = 224-255 | +| 128 | AES-128 | L = 3072
N = 256 | k = 3072 | f = 256-383 | +| 192 | AES-192 | L = 7680
N = 384 | k = 7680 | f = 384-511 | +| 256 | AES-256 | L = 15360
N = 512 | k = 15360 | f = 512+ | + +Example of applications: + +* Finite Field Cryptography: DSA, FFDH, MQV +* Integer Factorisation Cryptography: RSA +* Elliptic Curve Cryptography: ECDSA, EdDSA, ECDH, MQV + +Note: that this section assumes that no quantum computer exists; if such a computer would exist, the estimates for the last 3 columns would be no longer valid. + +## Random Values + +This section provides additional information +for V11.5 Random Values. + +| Name | Version/Reference | Notes | Status | +|:---|:----|:----|:-:| +| `/dev/random` | Linux 4.8+ [(Oct 2016)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=818e607b57c94ade9824dad63a96c2ea6b21baf3), also found in iOS, Android, and other Linux-based POSIX operating systems. Based on [RFC7539](https://datatracker.ietf.org/doc/html/rfc7539) | Utilizing ChaCha20 stream. Found in iOS [`SecRandomCopyBytes`](https://developer.apple.com/documentation/security/secrandomcopybytes(_:_:_:)?language=objc) and Android [`Secure Random`](https://developer.android.com/reference/java/security/SecureRandom) with the correct settings provided to each. | A | +| `/dev/urandom` | Linux kernel's special file for providing random data | Provides high-quality, entropy sources from hardware randomness | A | +| `AES-CTR-DRBG` | [NIST SP800-90A](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf) | As used in common implementations, such as [Windows CNG API `BCryptGenRandom`](https://learn.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptgenrandom) set by [`BCRYPT_RNG_ALGORITHM`](https://learn.microsoft.com/en-us/windows/win32/seccng/cng-algorithm-identifiers). | A | +| `HMAC-DRBG` | [NIST SP800-90A](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf) | | A | +| `Hash-DRBG` | [NIST SP800-90A](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf) | | A | +| `getentropy()` | [OpenBSD](https://man.openbsd.org/getentropy.2), available in [Linux glibc 2.25+](https://man7.org/linux/man-pages/man3/getentropy.3.html) and [macOS 10.12+](https://support.apple.com/en-gb/guide/security/seca0c73a75b/web) | Provides secure random bytes directly from the kernel's entropy source with a straightforward and minimal API. It’s more modern and avoids pitfalls associated with older APIs. | A | + +The underlying hash function used with HMAC-DRBG or Hash-DRBG must be approved for this usage. + +## Cipher Algorithms + +This section provides additional information +for V11.3 Encryption Algorithms. + +Approved cipher algorithms are listed in order of preference. + +| Symmetric Key Algorithms | Reference | Status | +| ------ | ------ |:-:| +| AES-256 | [FIPS 197](https://csrc.nist.gov/pubs/fips/197/final) | A | +| Salsa20 | [Salsa 20 specification](https://cr.yp.to/snuffle/spec.pdf) | A | +| XChaCha20 | [XChaCha20 Draft](https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-xchacha-03) | A | +| XSalsa20 | [Extending the Salsa20 nonce](https://cr.yp.to/snuffle/xsalsa-20110204.pdf) | A | +| ChaCha20 | [RFC 8439](https://www.rfc-editor.org/info/rfc8439) | A | +| AES-192 | [FIPS 197](https://csrc.nist.gov/pubs/fips/197/final) | A | +| AES-128 | [FIPS 197](https://csrc.nist.gov/pubs/fips/197/final) | L | +| 2TDEA | | D | +| TDEA (3DES/3DEA) | | D | +| IDEA | | D | +| RC4 | | D | +| Blowfish| | D | +| ARC4 | | D | +| DES | | D | + +### AES Cipher Modes + +Block ciphers, such as AES, can be used with different modes of operations. Many modes of operations, such as Electronic codebook (ECB), are insecure and must not be used. The Galois/Counter Mode (GCM) and Counter with cipher block chaining message authentication code (CCM) modes of operations provide authenticated encryption and should be used in modern applications. + +Approved modes are listed in order of preference. + +| Mode | Authenticated | Reference | Status | Restriction | +|--|--|--|:-:|--| +| GCM | Yes | [NIST SP 800-38D](https://csrc.nist.gov/pubs/sp/800/38/d/final) | A | | +| CCM | Yes | [NIST SP 800-38C](https://csrc.nist.gov/pubs/sp/800/38/c/upd1/final) | A | | +| CBC | No | [NIST SP 800-38A](https://csrc.nist.gov/pubs/sp/800/38/a/final) | L | | +| CCM-8 | Yes | | D | | +| ECB | No | | D | | +| CFB | No | | D | | +| OFB | No | | D | | +| CTR | No | | D | | + +Notes: + +* All encrypted messages must be authenticated. For ANY use of CBC mode there MUST be an associated hashing MAC algorithm to validate the message. In general, this MUST be applied in the Encrypt-Then-Hash method (but TLS 1.2 uses Hash-Then-Encrypt instead). If this cannot be guaranteed, then CBC MUST NOT be used. The only application where encryption without a MAC algorithm is allowed is disk encryption. +* If CBC is used, it shall be guaranteed that the verification of the padding is performed in constant time. +* When using CCM-8, the MAC tag only has 64 bits of security. This does not conform to requirement 6.2.9 which requires at least 128 bits of security. +* Disk encryption is considered out of scope for the ASVS. Therefore this appendix does not list any approved method for disk encryption. For this usage, encryption without authentication is usually accepted and the XTS, XEX and LRW modes are typically used. + +### Key Wrapping + +Cryptographic key wrap (and corresponding key unwrap) is a method of protecting an existing key by encapsulating (i.e., wrapping) it by employing an additional encryption mechanism so that the original key is not obviously exposed, e.g., during a transfer. This additional key used to protect the original key is referred to as the wrap key. + +This operation may be performed when it is desirable to protect keys in places deemed untrustworthy, or to send sensitive keys over untrusted networks or within applications. +However, serious consideration should be given to understanding the nature (e.g., the identity and the purpose) of the original key prior to committing to a wrap/unwrap procedure as this may have repercussions for both source and target systems/applications in terms of security and especially compliance which may include audit trails of a key's function (e.g., signing) as well as appropriate key storage. + +Specifically, AES-256 MUST be used for key wrapping, following [NIST SP 800-38F](https://csrc.nist.gov/pubs/sp/800/38/f/final) and considering forward-looking provisions against the quantum threat. Cipher modes using AES are the following, in order of preference: + +| Key Wrapping | Reference | Status | +|--|--|:-:| +| KW | [NIST SP 800-38F](https://csrc.nist.gov/pubs/sp/800/38/f/final) | A | +| KWP | [NIST SP 800-38F](https://csrc.nist.gov/pubs/sp/800/38/f/final) | A | + +AES-192 and AES-128 MAY be used if the use case demands it, but its motivation MUST be documented in the entity's cryptography inventory. + +### Authenticated Encryption + +With the exception of disk encryption, encrypted data must be protected against unauthorized modification using some form of authenticated encryption (AE) scheme, usually using an authenticated encryption with associated data (AEAD) scheme. + +The application should preferably use an approved AEAD scheme. It might alternatively combine an approved cipher scheme and an approved MAC algorithm with a Encrypt-then-MAC construct. + +MAC-then-encrypt is still allowed for compatibility with legacy applications. It is used in TLS v1.2 with old ciphers suites. + +| AEAD mechanism | Reference | Status | +|---|---------|:-:| +|AES-GCM | [SP 800-38D](https://csrc.nist.gov/pubs/sp/800/38/d/final) | A | +|AES-CCM | [SP 800-38C](https://csrc.nist.gov/pubs/sp/800/38/c/upd1/final) | A | +|ChaCha-Poly1305 | [RFC 7539](https://datatracker.ietf.org/doc/html/rfc7539) | A | +|AEGIS-256 | [AEGIS: A Fast Authenticated Encryption Algorithm (v1.1)](https://competitions.cr.yp.to/round3/aegisv11.pdf) | A | +|AEGIS-128 | [AEGIS: A Fast Authenticated Encryption Algorithm (v1.1)](https://competitions.cr.yp.to/round3/aegisv11.pdf) | A | +|AEGIS-128L| [AEGIS: A Fast Authenticated Encryption Algorithm (v1.1)](https://competitions.cr.yp.to/round3/aegisv11.pdf) | A | +|Encrypt-then-MAC | | A | +|MAC-then-encrypt | | L | + +## Hash Functions + +This section provides additional information +for V11.4 Hashing and Hash-based Functions. + +### Hash Functions for General Use Cases + +The following table lists hash functions approved in general cryptographic use cases such as digital signatures: + +* Approved hash functions provide strong collision resistance and are suitable for high-security applications. +* Some of these algorithms offer strong resistance to attacks when used with proper cryptographic key management, and so are additionally approved for HMAC, KDF, and RBG functions. +* Hash function with less than 254 bit of output have insufficient collision resistancea and must not be used for digital signature or other applications requiring collision resistance. For other usages, they might be used for compatibility and verification ONLY with legacy systems but must not be used in new designs. + +| Hash function | Reference | Status | Restrictions | +| ------ | ----------- |:-:| ---------- | +| SHA3-512 |[FIPS 202](https://csrc.nist.gov/pubs/fips/202/final) | A | | +| SHA-512 |[FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | A | | +| SHA3-384 |[FIPS 202](https://csrc.nist.gov/pubs/fips/202/final) | A | | +| SHA-384 |[FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | A | | +| SHA3-256 |[FIPS 202](https://csrc.nist.gov/pubs/fips/202/final) | A | | +| SHA-512/256 |[FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | A | | +| SHA-256 |[FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | A | | +| SHAKE256 |[FIPS 202](https://csrc.nist.gov/pubs/fips/202/final) | A | | +| BLAKE2s | [BLAKE2: simpler, smaller, fast as MD5](https://eprint.iacr.org/2013/322) | A | | +| BLAKE2b | [BLAKE2: simpler, smaller, fast as MD5](https://eprint.iacr.org/2013/322) | A | | +| BLAKE3 | [BLAKE3 one function, fast everywhere](https://github.com/BLAKE3-team/BLAKE3-specs/raw/master/blake3.pdf) | A | | +| SHA-224 | [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | L | Not suitable for HMAC, KDF, RBG, digital signatures | +| SHA-512/224 | [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | L | Not suitable for HMAC, KDF, RBG, digital signatures | +| SHA3-224 | [FIPS 202](https://csrc.nist.gov/pubs/fips/202/final) | L | Not suitable for HMAC, KDF, RBG, digital signatures | +| SHA-1 | [RFC 3174](https://www.rfc-editor.org/info/rfc3174) & [RFC 6194](https://www.rfc-editor.org/info/rfc6194) | L | Not suitable for HMAC, KDF, RBG, digital signatures | +| CRC (any length) | | D | | +| MD4 | [RFC 1320](https://www.rfc-editor.org/info/rfc1320) | D | | +| MD5 | [RFC 1321](https://www.rfc-editor.org/info/rfc1321) | D | | + +### Hash Functions for Password Storage + +For secure password hashing, dedicated hash functions must be used. These slow-hashing algorithms mitigate brute-force and dictionary attacks by increasing the computational difficulty of password cracking. + +| KDF | Reference | Required Parameters | Status | +| ---------- | --------- | ------------ |:-:| +| argon2id | [RFC 9106](https://www.rfc-editor.org/info/rfc9106) | t = 1: m ≥ 47104 (46 MiB), p = 1 | A | +| | | t = 2: m ≥ 19456 (19 MiB), p = 1 | A | +| | | t ≥ 3: m ≥ 12288 (12 MiB), p = 1 | A | +| scrypt | [RFC 7914](https://www.rfc-editor.org/info/rfc7914) | p = 1: N ≥ 2^17 (128 MiB), r = 8 | A | +| | | p = 2: N ≥ 2^16 (64 MiB), r = 8 | A | +| | | p ≥ 3: N ≥ 2^15 (32 MiB), r = 8 | A | +| bcrypt | [A Future-Adaptable Password Scheme](https://www.researchgate.net/publication/2519476_A_Future-Adaptable_Password_Scheme) | cost ≥ 10 | A | +| PBKDF2-HMAC-SHA-512 | [NIST SP 800-132](https://csrc.nist.gov/pubs/sp/800/132/final), [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | iterations ≥ 210,000 | A | +| PBKDF2-HMAC-SHA-256 | [NIST SP 800-132](https://csrc.nist.gov/pubs/sp/800/132/final), [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | iterations ≥ 600,000 | A | +| PBKDF2-HMAC-SHA-1 | [NIST SP 800-132](https://csrc.nist.gov/pubs/sp/800/132/final), [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | iterations ≥ 1,300,000 | L | + +Approved password-based key derivations functions can be used for password storage. + +## Key Derivation Functions (KDFs) + +### General Key Derivation Functions + +| KDF | Reference | Status | +| ---------------- | -------- |:-:| +| HKDF | [RFC 5869](https://www.rfc-editor.org/info/rfc5869) | A | +| TLS 1.2 PRF | [RFC 5248](https://www.rfc-editor.org/info/rfc5248) | L | +| MD5-based KDFs | [RFC 1321](https://www.rfc-editor.org/info/rfc1321) | D | +| SHA-1-based KDFs | [RFC 3174](https://www.rfc-editor.org/info/rfc3174) & [RFC 6194](https://www.rfc-editor.org/info/rfc6194) | D | + +### Password-based Key Derivation Functions + +| KDF | Reference | Required Parameters | Status | +| ---------- | --------- | ------------ |:-:| +| argon2id | [RFC 9106](https://www.rfc-editor.org/info/rfc9106) | t = 1: m ≥ 47104 (46 MiB), p = 1 | A | +| | | t = 2: m ≥ 19456 (19 MiB), p = 1 | A | +| scrypt | [RFC 7914](https://www.rfc-editor.org/info/rfc7914) | p = 1: N ≥ 2^17 (128 MiB), r = 8 | A | +| | | p = 2: N ≥ 2^16 (64 MiB), r = 8 | A | +| | | p ≥ 3: N ≥ 2^15 (32 MiB), r = 8 | A | +| PBKDF2-HMAC-SHA-512 | [NIST SP 800-132](https://csrc.nist.gov/pubs/sp/800/132/final), [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | iterations ≥ 210,000 | A | +| PBKDF2-HMAC-SHA-256 | [NIST SP 800-132](https://csrc.nist.gov/pubs/sp/800/132/final), [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | iterations ≥ 600,000 | A | +| PBKDF2-HMAC-SHA-1 | [NIST SP 800-132](https://csrc.nist.gov/pubs/sp/800/132/final), [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | iterations ≥ 1,300,000 | L | + +## Key Exchange Mechanisms + +This section provides additional information +for V11.6 Public Key Cryptography. + +### KEX Schemes + +A security strength of 112 bits or above MUST be ensured for all Key Exchange schemes, and their implementation MUST follow the parameter choices in the following table. + +| Scheme | Domain Parameters | Forward Secrecy |Status | +|--|--|--|:-:| +| Finite Field Diffie-Hellman (FFDH) | L >= 3072 & N >= 256 | Yes | A | +| Elliptic Curve Diffie-Hellman (ECDH) | f >= 256-383 | Yes | A | +| Encrypted key transport with RSA-PKCS#1 v1.5 | | No | D | + +Where the following parameters are: + +* k is the key size for RSA keys. +* L is the size of the public key and N is the size of the private key for finite field cryptography. +* f is the range of key sizes for ECC. + +Any new implementation MUST NOT use any scheme that is NOT compliant with [NIST SP 800-56A](https://csrc.nist.gov/pubs/sp/800/56/a/r3/final) & [B](https://csrc.nist.gov/pubs/sp/800/56/b/r2/final) and [NIST SP 800-77](https://csrc.nist.gov/pubs/sp/800/77/r1/final). Specifically, IKEv1 MUST NOT be used in production. + +### Diffie-Hellman groups + +The following groups are approved for implementations of Diffie-Hellman key exchange. Security strengths are documented in [NIST SP 800-56A](https://csrc.nist.gov/pubs/sp/800/56/a/r3/final), Appendix D, and [NIST SP 800-57 Part 1 Rev.5](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final). + +| Group | Status | +|------------------|:------:| +| P-224, secp224r1 | A | +| P-256, secp256r1 | A | +| P-384, secp384r1 | A | +| P-521, secp521r1 | A | +| K-233, sect233k1 | A | +| K-283, sect283k1 | A | +| K-409, sect409k1 | A | +| K-571, sect571k1 | A | +| B-233, sect233r1 | A | +| B-283, sect283r1 | A | +| B-409, sect409r1 | A | +| B-571, sect571r1 | A | +| Curve448 | A | +| Curve25519 | A | +| MODP-2048 | A | +| MODP-3072 | A | +| MODP-4096 | A | +| MODP-6144 | A | +| MODP-8192 | A | +| ffdhe2048 | A | +| ffdhe3072 | A | +| ffdhe4096 | A | +| ffdhe6144 | A | +| ffdhe8192 | A | + +## Message Authentication Codes (MAC) + +Message Authentication Codes (MACs) are cryptographic constructs used to verify the integrity and authenticity of a message. A MAC takes a message and a secret key as inputs and produces a fixed-size tag (the MAC value). MACs are widely used in secure communication protocols (e.g., TLS/SSL) to ensure that messages exchanged between parties are authentic and intact. + +| MAC Algorithm | Reference | Status | +| ---------- | --------------- |:-:| +| HMAC-SHA-256 | [RFC 2104](https://www.rfc-editor.org/info/rfc2104) & [FIPS 198-1](https://csrc.nist.gov/pubs/fips/198-1/final) | A | +| HMAC-SHA-384 | [RFC 2104](https://www.rfc-editor.org/info/rfc2104) & [FIPS 198-1](https://csrc.nist.gov/pubs/fips/198-1/final) | A | +| HMAC-SHA-512 | [RFC 2104](https://www.rfc-editor.org/info/rfc2104) & [FIPS 198-1](https://csrc.nist.gov/pubs/fips/198-1/final) | A | +| KMAC128 | [NIST SP 800-185](https://csrc.nist.gov/pubs/sp/800/185/final) | A | +| KMAC256 | [NIST SP 800-185](https://csrc.nist.gov/pubs/sp/800/185/final) | A | +| BLAKE3 (keyed_hash mode) | [BLAKE3 one function, fast everywhere](https://github.com/BLAKE3-team/BLAKE3-specs/raw/master/blake3.pdf) | A | +| AES-CMAC | [RFC 4493](https://datatracker.ietf.org/doc/html/rfc4493) & [NIST SP 800-38B](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38b.pdf) | A | +| AES-GMAC | [NIST SP 800-38D](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf) | A | +| Poly1305-AES | [The Poly1305-AES message-authentication code](https://cr.yp.to/mac/poly1305-20050329.pdf) | A | +| HMAC-SHA-1 | [RFC 2104](https://www.rfc-editor.org/info/rfc2104) & [FIPS 198-1](https://csrc.nist.gov/pubs/fips/198-1/final) | L | +| HMAC-MD5 | [RFC 1321](https://www.rfc-editor.org/info/rfc1321) | D | + +## Digital Signatures + +Signature schemes MUST use approved key sizes and parameters per [NIST SP 800-57 Part 1](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final). + +| Signature Algorithm | Reference | Status | +| ------------------------------ | --------------------------------------------- | :-: | +| EdDSA (Ed25519, Ed448) | [RFC 8032](https://www.rfc-editor.org/info/rfc8032) | A | +| XEdDSA (Curve25519, Curve448) | [XEdDSA](https://signal.org/docs/specifications/xeddsa/) | A | +| ECDSA (P-256, P-384, P-521) | [FIPS 186-4](https://csrc.nist.gov/pubs/fips/186-5/final) | A | +| RSA-RSSA-PSS | [RFC 8017](https://www.rfc-editor.org/info/rfc8017) | A | +| RSA-SSA-PKCS#1 v1.5 | [RFC 8017](https://www.rfc-editor.org/info/rfc8017) | D | +| DSA (any key size) | [FIPS 186-4](https://csrc.nist.gov/pubs/fips/186-4/final) | D | + +## Post-Quantum Encryption Standards + +PQC implementations must be in line with [FIPS-203](https://csrc.nist.gov/pubs/fips/203/ipd)/[204](https://csrc.nist.gov/pubs/fips/204/ipd)/[205](https://csrc.nist.gov/pubs/fips/205/ipd) as there is minimal hardened code nor implementation reference yet. https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards + +The proposed [mlkem768x25519](https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-mlkem/03/) post-quantum hybrid TLS key agreement method is supported by major browsers such as [Firefox release 132](https://www.mozilla.org/en-US/firefox/132.0/releasenotes/) and [Chrome release 131](https://security.googleblog.com/2024/09/a-new-path-for-kyber-on-web.html). It may be used in cryptographic testing environments or when available within industry- or government-approved libraries. diff --git a/5.0/pt/0x93-Appendix-D_Recommendations.md b/5.0/pt/0x93-Appendix-D_Recommendations.md new file mode 100644 index 0000000000..496dd5ba61 --- /dev/null +++ b/5.0/pt/0x93-Appendix-D_Recommendations.md @@ -0,0 +1,49 @@ +# Appendix D: Recommendations + +## Introduction + +Whilst preparing version 5.0 of the Application Security Verification Standard (ASVS), it became clear that there were a number of existing and newly suggested items that shouldn't be included as requirements in 5.0. This may have been because they were not in scope for ASVS as per the definition for 5.0 or alternatively it was felt that while they were a good idea, they could not be made mandatory. + +Not wanting to lose all these items entirely, some have been captured in this appendix. + +## Recommended, in-scope mechanisms + +The following items are in-scope for ASVS. They should not be made mandatory but it is strongly recommended to consider them as part of a secure application. + +* A password strength meter should provided to help users set a stronger password. +* Create a publicly available security.txt file at the root or .well-known directory of the application that clearly defines a link or e-mail address for people to contact owners about security issues. +* Client-side input validation should be enforced in addition to validation at a trusted service layer as this provides a good opportunity to discover when someone has bypassed client-side controls in an attempt to attack the application. +* Prevent accidentally accessible and sensitive pages from appearing in search engines using a robots.txt file, the X-Robots-Tag response header or a robots html meta tag. +* When using GraphQL, implement authorization logic at the business logic layer instead of the GraphQL or resolver layer to avoid having to handle authorization on every separate interface. + +References: + +* [More information on security.txt including a link to the RFC](https://securitytxt.org/) + +## Software Security principles + +The following items were previously in ASVS but are not really requirements. Rather they are principles to consider when implementing security controls that when followed will lead to more robust controls. These include: + +* Security controls should be centralized, simple (economy of design), verifiably secure, and reusable. This should avoid duplicate, missing, or ineffective controls. +* Wherever possible, use previously written and well-vetted security control implementations rather than relying on implementing controls from scratch. +* Ideally, a single access control mechanism should be used to access protected data and resources. All requests should pass through this single mechanism to avoid copy and paste or insecure alternative paths. +* Attribute or feature-based access control is a recommended pattern whereby the code checks the user's authorization for a feature or data item rather than just their role. Permissions should still be allocated using roles. + +## Software Security processes + +There are a number of security processes which were removed from ASVS 5.0 but are still a good idea. The OWASP SAMM project may be a good source for how to effectively implement these processes. The items which were previously in ASVS include: + +* Verify the use of a secure software development lifecycle that addresses security in all stages of development. +* Verify the use of threat modeling for every design change or sprint planning to identify threats, plan for countermeasures, facilitate appropriate risk responses, and guide security testing. +* Verify that all user stories and features contain functional security constraints, such as "As a user, I should be able to view and edit my profile. I should not be able to view or edit anyone else's profile" +* Verify availability of a secure coding checklist, security requirements, guideline, or policy to all developers and testers. +* Verify that an ongoing process exists to ensure that the application source code is free from backdoors, malicious code (e.g., salami attacks, logic bombs, time bombs), and undocumented or hidden features (e.g., Easter eggs, insecure debugging tools). Complying with this section is not possible without complete access to source code, including third-party libraries, and is therefore probably only suitable for applications requiring the very highest levels of security. +* Verify that mechanisms are in place to detect and respond to configuration drift in deployed environments. This may include using immutable infrastructure, automated redeployment from a secure baseline, or drift detection tools that compare current state against approved configurations. +* Verify that configuration hardening is performed on all third-party products, libraries, frameworks, and services as per their individual recommendations. + +References: + +* [OWASP Threat Modeling Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html) +* [OWASP Threat modeling](https://owasp.org/www-community/Application_Threat_Modeling) +* [OWASP Software Assurance Maturity Model Project](https://owasp.org/www-project-samm/) +* [Microsoft SDL](https://www.microsoft.com/en-us/securityengineering/sdl/) diff --git a/5.0/pt/0x94-Appendix-E_Contributors.md b/5.0/pt/0x94-Appendix-E_Contributors.md new file mode 100644 index 0000000000..88508b2fdc --- /dev/null +++ b/5.0/pt/0x94-Appendix-E_Contributors.md @@ -0,0 +1,71 @@ +# Appendix E - Contributors + +We gratefully acknowledge the contributions of the following people who have commented or opened pull requests since the the release of ASVS 4.0.0. + +If you are aware of any mistakes or would like your name to appear differently, please let us know. + +| | | | | +|---|---|---|---| +| Johan Sydseter ([sydseter](https://github.com/sydseter)) | luis servin ([lfservin](https://github.com/lfservin)) | Oleksii Dovydkov ([oleksiidov](https://github.com/oleksiidov)) | IZUKA Masahiro ([maizuka](https://github.com/maizuka)) | +| James Sulinski ([jsulinski](https://github.com/jsulinski)) | Eli Saad ([ThunderSon](https://github.com/ThunderSon)) | [kkshitish9](https://github.com/kkshitish9) | Andrew van der Stock ([vanderaj](https://github.com/vanderaj)) | +| Rick M ([kingthorin](https://github.com/kingthorin)) | Bankde Eakasit ([Bankde](https://github.com/Bankde)) | Michael Gargiullo ([mgargiullo](https://github.com/mgargiullo)) | Raphael Dunant ([Racater](https://github.com/Racater)) | +| Cesar Kohl ([cesarkohl](https://github.com/cesarkohl)) | [inaz0](https://github.com/inaz0) | Joerg Bruenner ([JoergBruenner](https://github.com/JoergBruenner)) | David Deatherage ([securitydave](https://github.com/securitydave)) | +| John Carroll ([yosignals](https://github.com/yosignals)) | Jim Fenton ([jimfenton](https://github.com/jimfenton)) | Matteo Pace ([M4tteoP](https://github.com/M4tteoP)) | Sebastien gioria ([SPoint42](https://github.com/SPoint42)) | +| Steven van der Baan ([vdbaan](https://github.com/vdbaan)) | Jeremy Bonghwan Choi ([jeremychoi](https://github.com/jeremychoi)) | [craig-shony](https://github.com/craig-shony) | Riccardo Sirigu ([ricsirigu](https://github.com/ricsirigu)) | +| Tomasz Wrobel ([tw2as](https://github.com/tw2as)) | Alena Dubeshko ([belalena](https://github.com/belalena)) | Rafael Green ([RafaelGreen1](https://github.com/RafaelGreen1)) | [mjang-cobalt](https://github.com/mjang-cobalt) | +| [clallier94](https://github.com/clallier94) | Kevin W. Wall ([kwwall](https://github.com/kwwall)) | Jordan Sherman ([jsherm-fwdsec](https://github.com/jsherm-fwdsec) / [deleterepo](https://github.com/deleterepo)) | Ingo Rauner ([ingo-rauner](https://github.com/ingo-rauner)) | +| Dirk Wetter ([drwetter](https://github.com/drwetter)) | Moshe Zioni ([moshe-apiiro](https://github.com/moshe-apiiro)) | Patrick Dwyer ([coderpatros](https://github.com/coderpatros)) | David Clarke ([davidclarke-au](https://github.com/davidclarke-au)) | +| Takaharu Ogasa ([takaharuogasa](https://github.com/takaharuogasa)) | Arkadii Yakovets ([arkid15r](https://github.com/arkid15r)) | Motoyasu Saburi ([motoyasu-saburi](https://github.com/motoyasu-saburi)) | [leirn](https://github.com/leirn) | +| [wet-certitude](https://github.com/wet-certitude) | [timhemel](https://github.com/timhemel) | RL Thornton ([thornshadow99](https://github.com/thornshadow99)) | Thomas Bandt ([aspnetde](https://github.com/aspnetde)) | +| Roel Storms ([roelstorms](https://github.com/roelstorms)) | Jeroen Willemsen ([commjoen](https://github.com/commjoen)) | [anonymous-31](https://github.com/anonymous-31) | Kamran Saifullah ([deFr0ggy](https://github.com/deFr0ggy)) | +| Steve Springett ([stevespringett](https://github.com/stevespringett)) | Spyros ([northdpole](https://github.com/northdpole)) | Hans Herrera ([hansphp](https://github.com/hansphp)) | [Marx314](https://github.com/Marx314) | +| [CarlosAllendes](https://github.com/CarlosAllendes) | Yonah Russ ([yruss972](https://github.com/yruss972)) | Sander Maijers ([sanmai-NL](https://github.com/sanmai-NL)) | Luboš Bretschneider ([bretik](https://github.com/bretik)) | +| Eva Sarafianou ([esarafianou](https://github.com/esarafianou)) | [ataseren](https://github.com/ataseren) | Steve Thomas ([Sc00bz](https://github.com/Sc00bz)) | Dominique RIGHETTO ([righettod](https://github.com/righettod)) | +| Steven van der Baan ([svdb-ncc](https://github.com/svdb-ncc)) | Michael Vacarella ([Aif4thah](https://github.com/Aif4thah)) | Tonimir Kisasondi ([tkisason](https://github.com/tkisason)) | Stefan Streichsbier ([streichsbaer](https://github.com/streichsbaer)) | +| [hi-unc1e](https://github.com/hi-unc1e) | sb3k ([starbuck3000](https://github.com/starbuck3000)) | [mario-platt](https://github.com/mario-platt) | Devdatta Akhawe ([devd](https://github.com/devd)) | +| Michael Gissing ([scolytus](https://github.com/scolytus)) | Jet Anderson ([thatsjet](https://github.com/thatsjet)) | Dave Wichers ([davewichers](https://github.com/davewichers)) | Jonny Schnittger ([JonnySchnittger](https://github.com/JonnySchnittger)) | +| Silvia Väli ([silviavali](https://github.com/silviavali)) | [jackgates73](https://github.com/jackgates73) | [1songb1rd](https://github.com/1songb1rd) | Timur - ([timurozkul](https://github.com/timurozkul)) | +| Gareth Heyes ([hackvertor](https://github.com/hackvertor)) | [appills](https://github.com/appills) | [suvikaartinen](https://github.com/suvikaartinen) | chaals ([chaals](https://github.com/chaals)) | +| DanielPharos ([AtlasHackert](https://github.com/AtlasHackert)) | will Farrell ([willfarrell](https://github.com/willfarrell)) | Alina Vasiljeva ([avasiljeva](https://github.com/avasiljeva)) | Paul McCann ([ismisepaul](https://github.com/ismisepaul)) | +| Sage ([SajjadPourali](https://github.com/SajjadPourali)) | [rbsec](https://github.com/rbsec) | Benedikt Bauer ([mastacheata](https://github.com/mastacheata)) | James Jardine ([jamesjardine](https://github.com/jamesjardine)) | +| Mark Burnett ([m8urnett](https://github.com/m8urnett)) | [dschwarz91](https://github.com/dschwarz91) | Cyber-AppSec ([Cyber-AppSec](https://github.com/Cyber-AppSec)) | [Tib3rius](https://github.com/Tib3rius) | +| BitnessWise ([bitnesswise](https://github.com/bitnesswise)) | damienbod ([damienbod](https://github.com/damienbod)) | Jared Meit ([jmeit-fwdsec](https://github.com/jmeit-fwdsec)) | Stefan Seelmann ([sseelmann](https://github.com/sseelmann)) | +| Brendan O'Connor ([ussjoin](https://github.com/ussjoin)) | Andrei Titov ([andrettv](https://github.com/andrettv)) | Hans-Petter Fjeld ([atluxity](https://github.com/atluxity)) | [markehack](https://github.com/markehack) | +| Neil Madden ([NeilMadden](https://github.com/NeilMadden)) | Michael Geramb ([mgeramb](https://github.com/mgeramb)) | Osama Elnaggar ([ossie-git](https://github.com/ossie-git)) | [mackowski](https://github.com/mackowski) | +| Ravi Balla ([raviballa](https://github.com/raviballa)) | Hazana ([hazanasec](https://github.com/hazanasec)) | David Means ([dmeans82](https://github.com/dmeans82)) | Alexander Stein ([tohch4](https://github.com/tohch4)) | +| BaeSenseii ([baesenseii](https://github.com/baesenseii)) | Vincent De Schutter ([VincentDS](https://github.com/VincentDS)) | S Bani ([sbani](https://github.com/sbani)) | Mitsuaki Akiyama ([mak1yama](https://github.com/mak1yama)) | +| Christopher Loessl ([hashier](https://github.com/hashier)) | [victorxm](https://github.com/victorxm) | Michal Rada ([michalradacz](https://github.com/michalradacz)) | Veeresh Devireddy ([drveresh](https://github.com/drveresh)) | +| [MaknaSEO](https://github.com/MaknaSEO) | [darkzero2022](https://github.com/darkzero2022) | Liam ([LiamDobbelaere](https://github.com/LiamDobbelaere)) | Frank Denis ([jedisct1](https://github.com/jedisct1)) | +| Otto Sulin ([ottosulin](https://github.com/ottosulin)) | [carllaw6885](https://github.com/carllaw6885) | Anders Johan Holmefjord ([aholmis](https://github.com/aholmis)) | Richard Fritsch ([rfricz](https://github.com/rfricz)) | +| [mesutgungor](https://github.com/mesutgungor) | Scott Helme ([ScottHelme](https://github.com/ScottHelme)) | Carlo Reggiani ([carloreggiani](https://github.com/carloreggiani)) | Suyash Srivastava ([suyash5053](https://github.com/suyash5053)) | +| Mark Potter ([markonweb](https://github.com/markonweb)) | Arjan Lamers ([alamers](https://github.com/alamers)) | Gøran Breivik ([gobrtg](https://github.com/gobrtg)) | [flo-blg](https://github.com/flo-blg) | +| Guillaume Déflache ([guillaume-d](https://github.com/guillaume-d)) | Toufik Airane ([toufik-airane](https://github.com/toufik-airane)) | Keith Hoodlet ([securingdev](https://github.com/securingdev)) | Sinner ([SoftwareSinner](https://github.com/SoftwareSinner)) | +| [iloving](https://github.com/iloving) | Jeroen Beckers ([TheDauntless](https://github.com/TheDauntless)) | Joubin Jabbari ([joubin](https://github.com/joubin)) | yu fujioka ([fujiokayu](https://github.com/fujiokayu)) | +| execjosh ([execjosh](https://github.com/execjosh)) | Alicja Kario ([tomato42](https://github.com/tomato42)) | Sidney Ribeiro ([srjsoftware](https://github.com/srjsoftware)) | Gabriel Marquet ([Gby56](https://github.com/Gby56)) | +| Drew Schulz ([drschulz](https://github.com/drschulz)) | [bedirhan](https://github.com/bedirhan) | [muralito](https://github.com/muralito) | Ronnie Flathers ([ropnop](https://github.com/ropnop)) | +| Philippe De Ryck ([philippederyck](https://github.com/philippederyck)) | Malte ([mal33](https://github.com/mal33)) | [MazeOfThoughts](https://github.com/MazeOfThoughts) | Andreas Falk ([andifalk](https://github.com/andifalk)) | +| Javi ([javixeneize](https://github.com/javixeneize)) | Daniel Hahn ([averell23](https://github.com/averell23)) | [borislav-c](https://github.com/borislav-c) | Robin Wood ([digininja](https://github.com/digininja)) | +| [miro2ns](https://github.com/miro2ns) | Jan Dockx ([jandockx](https://github.com/jandockx)) | [vipinsaini434](https://github.com/vipinsaini434) | [priyanshukumar397](https://github.com/priyanshukumar397) | +| Nat Sakimura ([sakimura](https://github.com/sakimura)) | Benjamin Häublein ([BenjaminHae](https://github.com/BenjaminHae)) | [unknown-user-from](https://github.com/unknown-user-from) | Ali Ramazan TAŞDELEN ([alitasdln](https://github.com/alitasdln)) | +| Pedro Escaleira ([oEscal](https://github.com/oEscal)) | Josh ([josh-hemphill](https://github.com/josh-hemphill)) | Tim Würtele ([SECtim](https://github.com/SECtim)) | AviD ([avidouglen](https://github.com/avidouglen)) | +| SheHacksPurple ([shehackspurple](https://github.com/shehackspurple)) | [fcerullo-cycubix](https://github.com/fcerullo-cycubix) | Hector Eryx Paredes Camacho ([heryxpc](https://github.com/heryxpc)) | Irene Michlin ([irene221b](https://github.com/irene221b)) | +| Jonah Y-M ([TG-Techie](https://github.com/TG-Techie)) | Dhiraj Bahroos ([bahroos](https://github.com/bahroos)) | Jef Meijvis ([jefmeijvis](https://github.com/jefmeijvis)) | [IzmaDoesItbeta](https://github.com/IzmaDoesItbeta) | +| Abdessamad TEMMAR ([TmmmmmR](https://github.com/TmmmmmR)) | [sectroyer](https://github.com/sectroyer) | Soh Satoh ([sohsatoh](https://github.com/sohsatoh)) | [regoravalaz](https://github.com/regoravalaz) | +| james-t ([james-bitherder](https://github.com/james-bitherder)) | Aram Hovsepyan ([aramhovsepyan](https://github.com/aramhovsepyan)) | [JaimeGomezGarciaSan](https://github.com/JaimeGomezGarciaSan) | [ValdiGit01](https://github.com/ValdiGit01) | +| iwatachan ([ishowta](https://github.com/ishowta)) | Vinod Anandan ([VinodAnandan](https://github.com/VinodAnandan)) | Kevin Kien ([KevinKien](https://github.com/KevinKien)) | [paul-williamson-swoop](https://github.com/paul-williamson-swoop) | +| [endergzr](https://github.com/endergzr) | Radhwan Alshamamri ([Rado0z](https://github.com/Rado0z)) | Grant Ongers ([rewtd](https://github.com/rewtd)) | Cure53 ([cure53](https://github.com/cure53)) | +| [AliR2Linux](https://github.com/AliR2Linux) | Ads Dawson ([GangGreenTemperTatum](https://github.com/GangGreenTemperTatum)) | William Reyor ([BillReyor](https://github.com/BillReyor)) | gabe ([gcrow](https://github.com/gcrow)) | +| [mascotter](https://github.com/mascotter) | [luissaiz](https://github.com/luissaiz) | Suren Manukyan ([vx-sec](https://github.com/vx-sec)) | Piotr Gliźniewicz ([pglizniewicz](https://github.com/pglizniewicz)) | +| Tadeusz Wachowski ([tadeuszwachowski](https://github.com/tadeuszwachowski)) | Nasir aka Nate ([andesec](https://github.com/andesec)) | [settantasette](https://github.com/settantasette) | Lars Haulin ([LarsH](https://github.com/LarsH)) | +| Terence Eden ([edent](https://github.com/edent)) | [JasmineScholz](https://github.com/JasmineScholz) | Arun Sivadasan ([teavanist](https://github.com/teavanist)) | Yusuf GÜR ([yusuffgur](https://github.com/yusuffgur)) | +| Troy Marshall ([troymarshall](https://github.com/troymarshall)) | Tanner Prynn ([tprynn](https://github.com/tprynn)) | Nick K. ([nickific](https://github.com/nickific)) | [raoul361](https://github.com/raoul361) | +| Azeem Ilyas ([TheAxZim](https://github.com/TheAxZim)) | Evo Stamatov ([avioli](https://github.com/avioli)) | Tim Potter ([timpotter87](https://github.com/timpotter87)) | Gavin Ray ([GavinRay97](https://github.com/GavinRay97)) | +| monis ([demideus](https://github.com/demideus)) | Marcin Hoppe ([MarcinHoppe](https://github.com/MarcinHoppe)) | Grambulf ([ramshazar](https://github.com/ramshazar)) | Jordan Pike ([computersarebad](https://github.com/computersarebad)) | +| Jason Rogers ([jason-invision](https://github.com/jason-invision)) | Ben Hall ([benbhall](https://github.com/benbhall)) | JamesPoppyCock ([jamesly123](https://github.com/jamesly123)) | WhiteHackLabs ([whitehacklabs](https://github.com/whitehacklabs)) | +| Alex Gaynor ([alex](https://github.com/alex)) | Filip van Laenen ([filipvanlaenen](https://github.com/filipvanlaenen)) | [jeurgen](https://github.com/jeurgen) | [GraoMelo](https://github.com/GraoMelo) | +| Andreas Kurtz ([ay-kay](https://github.com/ay-kay)) | Tom Tervoort ([TomTervoort](https://github.com/TomTervoort)) | old man ([deveras](https://github.com/deveras)) | Marco Schnüriger ([marcortw](https://github.com/marcortw)) | +| [stiiin](https://github.com/stiiin) | infoseclearn ([teaminfoseclearn](https://github.com/teaminfoseclearn)) | [hljupkij](https://github.com/hljupkij) | Noe ([nmarher](https://github.com/nmarher)) | +| Lyz ([lyz-code](https://github.com/lyz-code)) | Martin Riedel ([mrtnrdl](https://github.com/mrtnrdl)) | KIM Jaesuck ([tcaesvk](https://github.com/tcaesvk)) | Barbara Schachner ([bschach](https://github.com/bschach)) | +| René Reuter ([AresSec](https://github.com/AresSec)) | [carhackpils](https://github.com/carhackpils) | Tyler ([tyler2cr](https://github.com/tyler2cr)) | Hugo ([hasousa](https://github.com/hasousa)) | +| Wouter Bloeyaert ([Someniak](https://github.com/Someniak)) | Mark de Rijk ([markderijkinfosec](https://github.com/markderijkinfosec)) | Ramin ([picohub](https://github.com/picohub)) | Philip D. Turner ([philipdturner](https://github.com/philipdturner)) | +| Will Chatham ([willc](https://github.com/willc)) | | | | From 3d6e8921aa744bd2801330b3460c13483b1f9ca5 Mon Sep 17 00:00:00 2001 From: Victor Hugo Nogueira Lima Date: Sun, 14 Jun 2026 18:51:16 -0300 Subject: [PATCH 2/2] docs(pt-BR): add translated markdown files and remove mapping CSV --- 5.0/docs_pt/OWASP_ASVS_v5_pt-BR.csv | 346 ------------------ 5.0/pt/0x00-Header.yaml | 6 +- 5.0/pt/0x01-Frontispiece.md | 29 +- 5.0/pt/0x02-Preface.md | 30 +- 5.0/pt/0x03-What-is-the-ASVS.md | 199 +++++----- 5.0/pt/0x04-Assessment_and_Certification.md | 48 +-- 5.0/pt/0x05-For-Users-Of-4.0.md | 94 ++--- 5.0/pt/0x10-V1-Encoding-and-Sanitization.md | 126 +++---- .../0x11-V2-Validation-and-Business-Logic.md | 84 ++--- 5.0/pt/0x12-V3-Web-Frontend-Security.md | 120 +++--- 5.0/pt/0x13-V4-API-and-Web-Service.md | 72 ++-- 5.0/pt/0x14-V5-File-Handling.md | 62 ++-- 5.0/pt/0x15-V6-Authentication.md | 200 +++++----- 5.0/pt/0x16-V7-Session-Management.md | 106 +++--- 5.0/pt/0x17-V8-Authorization.md | 66 ++-- 5.0/pt/0x18-V9-Self-contained-Tokens.md | 42 +-- 5.0/pt/0x19-V10-OAuth-and-OIDC.md | 196 +++++----- 5.0/pt/0x20-V11-Cryptography.md | 126 +++---- 5.0/pt/0x21-V12-Secure-Communication.md | 66 ++-- 5.0/pt/0x22-V13-Configuration.md | 86 ++--- 5.0/pt/0x23-V14-Data-Protection.md | 62 ++-- ...0x24-V15-Secure-Coding-and-Architecture.md | 92 ++--- ...V16-Security-Logging-and-Error-Handling.md | 94 ++--- 5.0/pt/0x26-V17-WebRTC.md | 78 ++-- 5.0/pt/0x90-Appendix-A_Glossary.md | 176 ++++----- 5.0/pt/0x91-Appendix-B_References.md | 26 +- 5.0/pt/0x92-Appendix-C_Cryptography.md | 242 ++++++------ 5.0/pt/0x93-Appendix-D_Recommendations.md | 58 +-- 5.0/pt/0x94-Appendix-E_Contributors.md | 8 +- 29 files changed, 1298 insertions(+), 1642 deletions(-) delete mode 100644 5.0/docs_pt/OWASP_ASVS_v5_pt-BR.csv diff --git a/5.0/docs_pt/OWASP_ASVS_v5_pt-BR.csv b/5.0/docs_pt/OWASP_ASVS_v5_pt-BR.csv deleted file mode 100644 index d6e3ad2c7a..0000000000 --- a/5.0/docs_pt/OWASP_ASVS_v5_pt-BR.csv +++ /dev/null @@ -1,346 +0,0 @@ -chapter_id,chapter_name,section_id,section_name,req_id,req_description,L -V1,Codificação e Sanitização,V1.1,Arquitetura de Codificação e Sanitização,V1.1.1,"Verificar que a entrada é decodificada ou sem escape para uma forma canônica apenas uma vez, e somente quando dados codificados nessa forma são esperados, e que isso é feito antes do processamento adicional da entrada — por exemplo, não após validação ou sanitização da entrada.",2 -V1,Codificação e Sanitização,V1.1,Arquitetura de Codificação e Sanitização,V1.1.2,"Verificar que a aplicação realiza codificação e escape de saída como etapa final antes de ser usada pelo interpretador ao qual se destina, ou pelo próprio interpretador.",2 -V1,Codificação e Sanitização,V1.2,Prevenção de Injeção,V1.2.1,"Verificar que a codificação de saída para uma resposta HTTP, documento HTML ou documento XML é adequada ao contexto exigido, como codificar os caracteres relevantes para elementos HTML, atributos HTML, comentários HTML, CSS ou campos de cabeçalho HTTP, a fim de evitar a alteração da estrutura da mensagem ou do documento.",1 -V1,Codificação e Sanitização,V1.2,Prevenção de Injeção,V1.2.2,"Verificar que, ao construir URLs dinamicamente, dados não confiáveis são codificados conforme seu contexto (por exemplo, codificação de URL ou codificação base64url para parâmetros de consulta ou caminho). Garantir que apenas protocolos de URL seguros sejam permitidos (por exemplo, desabilitar javascript: ou data:).",1 -V1,Codificação e Sanitização,V1.2,Prevenção de Injeção,V1.2.3,"Verificar que codificação ou escape de saída é usado ao construir dinamicamente conteúdo JavaScript (incluindo JSON), para evitar a alteração da estrutura da mensagem ou do documento (para evitar injeção de JavaScript e JSON).",1 -V1,Codificação e Sanitização,V1.2,Prevenção de Injeção,V1.2.4,"Verificar que seleção de dados ou consultas a bancos de dados (por exemplo, SQL, HQL, NoSQL, Cypher) utilizam consultas parametrizadas, ORMs, frameworks de entidade ou são protegidas de outra forma contra ataques de Injeção de SQL e outras injeções em banco de dados. Isso também se aplica ao criar stored procedures.",1 -V1,Codificação e Sanitização,V1.2,Prevenção de Injeção,V1.2.5,Verificar que a aplicação protege contra injeção de comandos do sistema operacional e que chamadas ao sistema operacional utilizam consultas de SO parametrizadas ou codificação contextual de saída da linha de comando.,1 -V1,Codificação e Sanitização,V1.2,Prevenção de Injeção,V1.2.6,"Verificar que a aplicação protege contra vulnerabilidades de injeção de LDAP, ou que controles de segurança específicos para prevenir injeção de LDAP foram implementados.",2 -V1,Codificação e Sanitização,V1.2,Prevenção de Injeção,V1.2.7,Verificar que a aplicação está protegida contra ataques de injeção de XPath por meio de parametrização de consultas ou consultas pré-compiladas.,2 -V1,Codificação e Sanitização,V1.2,Prevenção de Injeção,V1.2.8,"Verificar que os processadores LaTeX estão configurados de forma segura (como não usar o sinalizador ""--shell-escape"") e que uma lista de permissões de comandos é utilizada para prevenir ataques de injeção de LaTeX.",2 -V1,Codificação e Sanitização,V1.2,Prevenção de Injeção,V1.2.9,Verificar que a aplicação escapa caracteres especiais em expressões regulares (tipicamente usando barra invertida) para evitar que sejam interpretados como metacaracteres.,2 -V1,Codificação e Sanitização,V1.2,Prevenção de Injeção,V1.2.10,"Verificar que a aplicação está protegida contra Injeção de CSV e Fórmulas. A aplicação deve seguir as regras de escape definidas nas seções 2.6 e 2.7 da RFC 4180 ao exportar conteúdo CSV. Adicionalmente, ao exportar para CSV ou outros formatos de planilha (como XLS, XLSX ou ODF), caracteres especiais (incluindo '=', '+', '-', '@', '\t' (tabulação) e '\0' (caractere nulo)) devem ser escapados com aspas simples se aparecerem como primeiro caractere em um campo.",3 -V1,Codificação e Sanitização,V1.3,Sanitização,V1.3.1,Verificar que toda entrada HTML não confiável proveniente de editores WYSIWYG ou similares é sanitizada usando uma biblioteca de sanitização HTML conhecida e segura ou recurso de framework.,1 -V1,Codificação e Sanitização,V1.3,Sanitização,V1.3.2,"Verificar que a aplicação evita o uso de eval() ou outros recursos de execução dinâmica de código, como Spring Expression Language (SpEL). Quando não houver alternativa, qualquer entrada do usuário incluída deve ser sanitizada antes de ser executada.",1 -V1,Codificação e Sanitização,V1.3,Sanitização,V1.3.3,"Verificar que os dados passados para um contexto potencialmente perigoso são sanitizados previamente para aplicar medidas de segurança, como permitir apenas caracteres seguros para esse contexto e truncar entradas excessivamente longas.",2 -V1,Codificação e Sanitização,V1.3,Sanitização,V1.3.4,"Verificar que o conteúdo scriptável de Scalable Vector Graphics (SVG) fornecido pelo usuário é validado ou sanitizado para conter apenas tags e atributos (como elementos gráficos) que sejam seguros para a aplicação — por exemplo, sem scripts ou foreignObject.",2 -V1,Codificação e Sanitização,V1.3,Sanitização,V1.3.5,"Verificar que a aplicação sanitiza ou desabilita conteúdo scriptável ou em linguagem de template de expressão fornecido pelo usuário, como Markdown, folhas de estilo CSS ou XSL, BBCode ou similares.",2 -V1,Codificação e Sanitização,V1.3,Sanitização,V1.3.6,"Verificar que a aplicação protege contra ataques de Server-side Request Forgery (SSRF), validando dados não confiáveis contra uma lista de permissões de protocolos, domínios, caminhos e portas, e sanitizando caracteres potencialmente perigosos antes de usar os dados para chamar outro serviço.",2 -V1,Codificação e Sanitização,V1.3,Sanitização,V1.3.7,"Verificar que a aplicação protege contra ataques de injeção de templates, não permitindo que templates sejam construídos com base em entradas não confiáveis. Quando não houver alternativa, qualquer entrada não confiável incluída dinamicamente durante a criação do template deve ser sanitizada ou estritamente validada.",2 -V1,Codificação e Sanitização,V1.3,Sanitização,V1.3.8,Verificar que a aplicação sanitiza adequadamente entradas não confiáveis antes de usá-las em consultas JNDI (Java Naming and Directory Interface) e que o JNDI está configurado de forma segura para prevenir ataques de injeção de JNDI.,2 -V1,Codificação e Sanitização,V1.3,Sanitização,V1.3.9,Verificar que a aplicação sanitiza o conteúdo antes de enviá-lo ao memcache para prevenir ataques de injeção.,2 -V1,Codificação e Sanitização,V1.3,Sanitização,V1.3.10,Verificar que strings de formato que possam ser resolvidas de maneira inesperada ou maliciosa são sanitizadas antes de serem processadas.,2 -V1,Codificação e Sanitização,V1.3,Sanitização,V1.3.11,"Verificar que a aplicação sanitiza a entrada do usuário antes de passá-la para sistemas de e-mail, para proteger contra injeção de SMTP ou IMAP.",2 -V1,Codificação e Sanitização,V1.3,Sanitização,V1.3.12,"Verificar que as expressões regulares estão livres de elementos que causem retrocesso exponencial, e garantir que a entrada não confiável seja sanitizada para mitigar ataques ReDoS ou de expressões regulares descontroladas.",3 -V1,Codificação e Sanitização,V1.4,"Memória, Strings e Código Não Gerenciado",V1.4.1,"Verificar que a aplicação usa strings seguras em termos de memória, cópia de memória mais segura e aritmética de ponteiros para detectar ou prevenir estouros de pilha, buffer ou heap.",2 -V1,Codificação e Sanitização,V1.4,"Memória, Strings e Código Não Gerenciado",V1.4.2,"Verificar que técnicas de validação de sinal, intervalo e entrada são usadas para prevenir estouros de inteiros.",2 -V1,Codificação e Sanitização,V1.4,"Memória, Strings e Código Não Gerenciado",V1.4.3,"Verificar que a memória e os recursos alocados dinamicamente são liberados, e que referências ou ponteiros para memória liberada são removidos ou definidos como nulo para prevenir ponteiros pendentes e vulnerabilidades de use-after-free.",2 -V1,Codificação e Sanitização,V1.5,Desserialização Segura,V1.5.1,"Verificar que a aplicação configura os parsers XML para usar uma configuração restritiva e que recursos inseguros, como a resolução de entidades externas, estão desabilitados para prevenir ataques de XML eXternal Entity (XXE).",1 -V1,Codificação e Sanitização,V1.5,Desserialização Segura,V1.5.2,"Verificar que a desserialização de dados não confiáveis aplica tratamento seguro de entrada, como o uso de uma lista de permissões de tipos de objetos ou a restrição de tipos de objetos definidos pelo cliente, para prevenir ataques de desserialização. Mecanismos de desserialização explicitamente definidos como inseguros não devem ser usados com entradas não confiáveis.",2 -V1,Codificação e Sanitização,V1.5,Desserialização Segura,V1.5.3,"Verificar que diferentes parsers usados na aplicação para o mesmo tipo de dado (por exemplo, parsers JSON, XML, URL) realizam o parsing de forma consistente e utilizam o mesmo mecanismo de codificação de caracteres, para evitar problemas como vulnerabilidades de interoperabilidade JSON ou comportamentos diferentes de parsing de URI ou arquivo que possam ser explorados em ataques de Remote File Inclusion (RFI) ou Server-side Request Forgery (SSRF).",3 -V2,Validação e Lógica de Negócio,V2.1,Documentação de Validação e Lógica de Negócio,V2.1.1,"Verificar que a documentação da aplicação define regras de validação de entrada sobre como verificar a validade de itens de dados em relação a uma estrutura esperada. Isso pode incluir formatos de dados comuns, como números de cartão de crédito, endereços de e-mail, números de telefone, ou formatos de dados internos.",1 -V2,Validação e Lógica de Negócio,V2.1,Documentação de Validação e Lógica de Negócio,V2.1.2,"Verificar que a documentação da aplicação define como validar a consistência lógica e contextual de itens de dados combinados, como verificar se o bairro e o CEP correspondem.",2 -V2,Validação e Lógica de Negócio,V2.1,Documentação de Validação e Lógica de Negócio,V2.1.3,"Verificar que as expectativas de limites e validações da lógica de negócio estão documentadas, incluindo tanto por usuário quanto globalmente na aplicação.",2 -V2,Validação e Lógica de Negócio,V2.2,Validação de Entrada,V2.2.1,"Verificar que a entrada é validada para aplicar as expectativas de negócio ou funcionais para essa entrada. Isso deve usar validação positiva com base em uma lista de permissões de valores, padrões e intervalos, ou basear-se na comparação da entrada com uma estrutura esperada e limites lógicos conforme regras predefinidas. Para L1, pode-se focar em entradas usadas para tomar decisões específicas de negócio ou segurança. Para L2 e acima, deve-se aplicar a todas as entradas.",1 -V2,Validação e Lógica de Negócio,V2.2,Validação de Entrada,V2.2.2,"Verificar que a aplicação está projetada para aplicar a validação de entrada em uma camada de serviço confiável. Embora a validação no lado do cliente melhore a usabilidade e deva ser incentivada, ela não deve ser usada como controle de segurança.",1 -V2,Validação e Lógica de Negócio,V2.2,Validação de Entrada,V2.2.3,Verificar que a aplicação garante que combinações de itens de dados relacionados são razoáveis de acordo com as regras predefinidas.,2 -V2,Validação e Lógica de Negócio,V2.3,Segurança da Lógica de Negócio,V2.3.1,"Verificar que a aplicação processa fluxos de lógica de negócio para o mesmo usuário somente na ordem sequencial esperada, sem pular etapas.",1 -V2,Validação e Lógica de Negócio,V2.3,Segurança da Lógica de Negócio,V2.3.2,"Verificar que os limites da lógica de negócio são implementados conforme a documentação da aplicação, para evitar que falhas de lógica de negócio sejam exploradas.",2 -V2,Validação e Lógica de Negócio,V2.3,Segurança da Lógica de Negócio,V2.3.3,"Verificar que transações são usadas no nível da lógica de negócio, de modo que uma operação de lógica de negócio seja bem-sucedida em sua totalidade ou seja revertida ao estado correto anterior.",2 -V2,Validação e Lógica de Negócio,V2.3,Segurança da Lógica de Negócio,V2.3.4,Verificar que mecanismos de bloqueio em nível de lógica de negócio são usados para garantir que recursos de quantidade limitada (como assentos em teatro ou slots de entrega) não possam ser reservados em duplicidade por meio da manipulação da lógica da aplicação.,2 -V2,Validação e Lógica de Negócio,V2.3,Segurança da Lógica de Negócio,V2.3.5,"Verificar que fluxos de lógica de negócio de alto valor exigem aprovação de múltiplos usuários para evitar ações não autorizadas ou acidentais. Isso pode incluir, mas não se limita a, grandes transferências monetárias, aprovações de contratos, acesso a informações classificadas ou substituições de segurança em manufatura.",3 -V2,Validação e Lógica de Negócio,V2.4,Anti-automação,V2.4.1,"Verificar que controles de anti-automação estão implementados para proteger contra chamadas excessivas a funções da aplicação que possam levar à exfiltração de dados, criação de dados inválidos, esgotamento de cotas, violações de limite de taxa, negação de serviço ou uso excessivo de recursos onerosos.",2 -V2,Validação e Lógica de Negócio,V2.4,Anti-automação,V2.4.2,"Verificar que os fluxos de lógica de negócio exigem temporização realista para um humano, prevenindo submissões de transações excessivamente rápidas.",3 -V3,Segurança de Frontend Web,V3.1,Documentação de Segurança de Frontend Web,V3.1.1,"Verificar que a documentação da aplicação declara os recursos de segurança esperados que os navegadores que usam a aplicação devem suportar (como HTTPS, HTTP Strict Transport Security (HSTS), Content Security Policy (CSP) e outros mecanismos relevantes de segurança HTTP). Também deve definir como a aplicação deve se comportar quando alguns desses recursos não estiverem disponíveis (como avisar o usuário ou bloquear o acesso).",3 -V3,Segurança de Frontend Web,V3.2,Interpretação Não Intencional de Conteúdo,V3.2.1,"Verificar que controles de segurança estão implementados para evitar que os navegadores renderizem conteúdo ou funcionalidade em respostas HTTP em um contexto incorreto (por exemplo, quando uma API, arquivo enviado pelo usuário ou outro recurso é solicitado diretamente). Os controles possíveis podem incluir: não servir o conteúdo a menos que campos de cabeçalho HTTP (como Sec-Fetch-*) indiquem que é o contexto correto, usar a diretiva sandbox do cabeçalho Content-Security-Policy ou usar o tipo de disposição de anexo no cabeçalho Content-Disposition.",1 -V3,Segurança de Frontend Web,V3.2,Interpretação Não Intencional de Conteúdo,V3.2.2,"Verificar que o conteúdo destinado a ser exibido como texto, em vez de renderizado como HTML, é tratado usando funções de renderização seguras (como createTextNode ou textContent) para prevenir a execução não intencional de conteúdo como HTML ou JavaScript.",1 -V3,Segurança de Frontend Web,V3.2,Interpretação Não Intencional de Conteúdo,V3.2.3,"Verificar que a aplicação evita o DOM clobbering ao usar JavaScript no lado do cliente, por meio de declarações explícitas de variáveis, verificação de tipo estrita, evitando armazenar variáveis globais no objeto document e implementando isolamento de namespace.",3 -V3,Segurança de Frontend Web,V3.3,Configuração de Cookies,V3.3.1,"Verificar que os cookies têm o atributo 'Secure' definido e que, se o prefixo '__Host-' não for usado para o nome do cookie, o prefixo '__Secure-' deve ser usado.",1 -V3,Segurança de Frontend Web,V3.3,Configuração de Cookies,V3.3.2,"Verificar que o valor do atributo 'SameSite' de cada cookie é definido de acordo com a finalidade do cookie, para limitar a exposição a ataques de redirecionamento de interface de usuário e ataques de falsificação de requisição baseados no navegador, comumente conhecidos como cross-site request forgery (CSRF).",2 -V3,Segurança de Frontend Web,V3.3,Configuração de Cookies,V3.3.3,"Verificar que os cookies possuem o prefixo '__Host-' para o nome do cookie, a menos que sejam explicitamente projetados para ser compartilhados com outros hosts.",2 -V3,Segurança de Frontend Web,V3.3,Configuração de Cookies,V3.3.4,"Verificar que, se o valor de um cookie não deve ser acessível a scripts no lado do cliente (como um token de sessão), o cookie deve ter o atributo 'HttpOnly' definido e o mesmo valor (por exemplo, token de sessão) deve ser transferido ao cliente apenas via campo de cabeçalho 'Set-Cookie'.",2 -V3,Segurança de Frontend Web,V3.3,Configuração de Cookies,V3.3.5,"Verificar que, ao gravar um cookie, o comprimento combinado do nome e valor do cookie não ultrapasse 4096 bytes. Cookies excessivamente grandes não serão armazenados pelo navegador e, portanto, não serão enviados com as requisições, impedindo o usuário de usar funcionalidades da aplicação que dependem desse cookie.",3 -V3,Segurança de Frontend Web,V3.4,Cabeçalhos de Mecanismos de Segurança do Navegador,V3.4.1,"Verificar que um campo de cabeçalho Strict-Transport-Security está incluído em todas as respostas para aplicar uma política de HTTP Strict Transport Security (HSTS). Uma idade máxima de pelo menos 1 ano deve ser definida e, para L2 e acima, a política deve se aplicar a todos os subdomínios.",1 -V3,Segurança de Frontend Web,V3.4,Cabeçalhos de Mecanismos de Segurança do Navegador,V3.4.2,"Verificar que o campo de cabeçalho Access-Control-Allow-Origin do Cross-Origin Resource Sharing (CORS) é um valor fixo definido pela aplicação ou, se o valor do campo de cabeçalho Origin da requisição HTTP for usado, ele é validado em relação a uma lista de permissões de origens confiáveis. Quando 'Access-Control-Allow-Origin: *' precisar ser usado, verificar que a resposta não inclui nenhuma informação sensível.",1 -V3,Segurança de Frontend Web,V3.4,Cabeçalhos de Mecanismos de Segurança do Navegador,V3.4.3,"Verificar que as respostas HTTP incluem um campo de cabeçalho de resposta Content-Security-Policy que define diretivas para garantir que o navegador carregue e execute apenas conteúdo ou recursos confiáveis, a fim de limitar a execução de JavaScript malicioso. No mínimo, uma política global deve ser usada incluindo as diretivas object-src 'none' e base-uri 'none', e deve definir uma lista de permissões ou usar nonces ou hashes. Para uma aplicação L3, uma política por resposta com nonces ou hashes deve ser definida.",2 -V3,Segurança de Frontend Web,V3.4,Cabeçalhos de Mecanismos de Segurança do Navegador,V3.4.4,"Verificar que todas as respostas HTTP contêm um campo de cabeçalho 'X-Content-Type-Options: nosniff'. Isso instrui os navegadores a não usar detecção de conteúdo e adivinhação de tipo MIME para a resposta, exigindo que o valor do campo de cabeçalho Content-Type da resposta corresponda ao recurso de destino. Por exemplo, a resposta a uma requisição de estilo só é aceita se o Content-Type da resposta for 'text/css'. Isso também habilita o uso da funcionalidade Cross-Origin Read Blocking (CORB) pelo navegador.",2 -V3,Segurança de Frontend Web,V3.4,Cabeçalhos de Mecanismos de Segurança do Navegador,V3.4.5,"Verificar que a aplicação define uma política de referrer para prevenir o vazamento de dados tecnicamente sensíveis para serviços de terceiros via campo de cabeçalho HTTP 'Referer'. Isso pode ser feito usando o campo de cabeçalho HTTP de resposta Referrer-Policy ou por meio de atributos de elementos HTML. Dados sensíveis podem incluir dados de caminho e consulta na URL e, para aplicações internas não públicas, também o hostname.",2 -V3,Segurança de Frontend Web,V3.4,Cabeçalhos de Mecanismos de Segurança do Navegador,V3.4.6,"Verificar que a aplicação web usa a diretiva frame-ancestors do cabeçalho Content-Security-Policy em todas as respostas HTTP para garantir que ela não possa ser incorporada por padrão, e que a incorporação de recursos específicos seja permitida apenas quando necessário. Observar que o campo de cabeçalho X-Frame-Options, embora suportado por navegadores, está obsoleto e não deve ser utilizado como referência.",2 -V3,Segurança de Frontend Web,V3.4,Cabeçalhos de Mecanismos de Segurança do Navegador,V3.4.7,Verificar que o campo de cabeçalho Content-Security-Policy especifica um local para reportar violações.,3 -V3,Segurança de Frontend Web,V3.4,Cabeçalhos de Mecanismos de Segurança do Navegador,V3.4.8,"Verificar que todas as respostas HTTP que iniciam a renderização de um documento (como respostas com Content-Type text/html) incluem o campo de cabeçalho Cross-Origin-Opener-Policy com a diretiva same-origin ou a diretiva same-origin-allow-popups conforme necessário. Isso previne ataques que abusam do acesso compartilhado a objetos Window, como tabnabbing e contagem de frames.",3 -V3,Segurança de Frontend Web,V3.5,Separação de Origem do Navegador,V3.5.1,"Verificar que, se a aplicação não depende do mecanismo de preflight de CORS para prevenir requisições cross-origin não permitidas que usem funcionalidades sensíveis, essas requisições são validadas para garantir que se originam da própria aplicação. Isso pode ser feito usando e validando tokens anti-falsificação ou exigindo campos de cabeçalho HTTP extras que não sejam campos de cabeçalho de requisição seguros pelo CORS. Isso serve para defender contra ataques de falsificação de requisição baseados no navegador, comumente conhecidos como cross-site request forgery (CSRF).",1 -V3,Segurança de Frontend Web,V3.5,Separação de Origem do Navegador,V3.5.2,"Verificar que, se a aplicação depende do mecanismo de preflight de CORS para prevenir o uso cross-origin não permitido de funcionalidades sensíveis, não é possível chamar essa funcionalidade com uma requisição que não acione uma requisição de preflight CORS. Isso pode exigir a verificação dos valores dos campos de cabeçalho de requisição 'Origin' e 'Content-Type' ou o uso de um campo de cabeçalho extra que não seja um cabeçalho seguro pelo CORS.",1 -V3,Segurança de Frontend Web,V3.5,Separação de Origem do Navegador,V3.5.3,"Verificar que as requisições HTTP para funcionalidades sensíveis usam métodos HTTP adequados como POST, PUT, PATCH ou DELETE, e não métodos definidos pela especificação HTTP como 'seguros', como HEAD, OPTIONS ou GET. Alternativamente, a validação estrita dos campos de cabeçalho de requisição Sec-Fetch-* pode ser usada para garantir que a requisição não originou de uma chamada cross-origin inadequada, de uma requisição de navegação ou de um carregamento de recurso (como origem de imagem) onde isso não é esperado.",1 -V3,Segurança de Frontend Web,V3.5,Separação de Origem do Navegador,V3.5.4,"Verificar que aplicações separadas são hospedadas em hostnames diferentes para aproveitar as restrições fornecidas pela política de mesma origem, incluindo como documentos ou scripts carregados por uma origem podem interagir com recursos de outra origem, e restrições baseadas em hostname em cookies.",2 -V3,Segurança de Frontend Web,V3.5,Separação de Origem do Navegador,V3.5.5,Verificar que mensagens recebidas pela interface postMessage são descartadas se a origem da mensagem não for confiável ou se a sintaxe da mensagem for inválida.,2 -V3,Segurança de Frontend Web,V3.5,Separação de Origem do Navegador,V3.5.6,Verificar que a funcionalidade JSONP não está habilitada em nenhum lugar da aplicação para evitar ataques de Cross-Site Script Inclusion (XSSI).,3 -V3,Segurança de Frontend Web,V3.5,Separação de Origem do Navegador,V3.5.7,"Verificar que dados que requerem autorização não estão incluídos em respostas de recursos script, como arquivos JavaScript, para prevenir ataques de Cross-Site Script Inclusion (XSSI).",3 -V3,Segurança de Frontend Web,V3.5,Separação de Origem do Navegador,V3.5.8,"Verificar que recursos autenticados (como imagens, vídeos, scripts e outros documentos) só podem ser carregados ou incorporados em nome do usuário quando pretendido. Isso pode ser feito por validação estrita dos campos de cabeçalho HTTP Sec-Fetch-* para garantir que a requisição não originou de uma chamada cross-origin inadequada, ou definindo um campo de cabeçalho HTTP de resposta Cross-Origin-Resource-Policy restritivo para instruir o navegador a bloquear o conteúdo retornado.",3 -V3,Segurança de Frontend Web,V3.6,Integridade de Recursos Externos,V3.6.1,"Verificar que ativos no lado do cliente, como bibliotecas JavaScript, CSS ou fontes web, só são hospedados externamente (por exemplo, em uma Rede de Distribuição de Conteúdo) se o recurso for estático e versionado e se a Subresource Integrity (SRI) for usada para validar a integridade do ativo. Se isso não for possível, deve haver uma decisão de segurança documentada para justificar isso para cada recurso.",3 -V3,Segurança de Frontend Web,V3.7,Outras Considerações de Segurança do Navegador,V3.7.1,"Verificar que a aplicação usa apenas tecnologias do lado do cliente que ainda são suportadas e consideradas seguras. Exemplos de tecnologias que não atendem a esse requisito incluem plugins NSAPI, Flash, Shockwave, ActiveX, Silverlight, NACL ou applets Java no lado do cliente.",2 -V3,Segurança de Frontend Web,V3.7,Outras Considerações de Segurança do Navegador,V3.7.2,Verificar que a aplicação só redireciona automaticamente o usuário para um hostname ou domínio diferente (que não é controlado pela aplicação) quando o destino consta em uma lista de permissões.,2 -V3,Segurança de Frontend Web,V3.7,Outras Considerações de Segurança do Navegador,V3.7.3,"Verificar que a aplicação exibe uma notificação quando o usuário está sendo redirecionado para uma URL fora do controle da aplicação, com opção de cancelar a navegação.",3 -V3,Segurança de Frontend Web,V3.7,Outras Considerações de Segurança do Navegador,V3.7.4,"Verificar que o domínio de nível superior da aplicação (por exemplo, site.tld) foi adicionado à lista de pré-carregamento público de HTTP Strict Transport Security (HSTS). Isso garante que o uso de TLS para a aplicação seja incorporado diretamente nos principais navegadores, em vez de depender apenas do campo de cabeçalho de resposta Strict-Transport-Security.",3 -V3,Segurança de Frontend Web,V3.7,Outras Considerações de Segurança do Navegador,V3.7.5,Verificar que a aplicação se comporta conforme documentado (como avisar o usuário ou bloquear o acesso) se o navegador usado para acessar a aplicação não suportar os recursos de segurança esperados.,3 -V4,API e Serviço Web,V4.1,Segurança Genérica de Serviços Web,V4.1.1,"Verificar que toda resposta HTTP com corpo de mensagem contém um campo de cabeçalho Content-Type que corresponde ao conteúdo real da resposta, incluindo o parâmetro charset para especificar a codificação de caracteres segura (por exemplo, UTF-8, ISO-8859-1) conforme os tipos de mídia IANA, como ""text/"", ""/+xml"" e ""/xml"".",1 -V4,API e Serviço Web,V4.1,Segurança Genérica de Serviços Web,V4.1.2,"Verificar que apenas endpoints voltados ao usuário (destinados ao acesso manual via navegador web) redirecionam automaticamente de HTTP para HTTPS, enquanto outros serviços ou endpoints não implementam redirecionamentos transparentes. Isso evita uma situação em que um cliente envia erroneamente requisições HTTP não criptografadas, mas como as requisições são automaticamente redirecionadas para HTTPS, o vazamento de dados sensíveis passa despercebido.",2 -V4,API e Serviço Web,V4.1,Segurança Genérica de Serviços Web,V4.1.3,"Verificar que qualquer campo de cabeçalho HTTP usado pela aplicação e definido por uma camada intermediária, como um balanceador de carga, proxy web ou serviço backend-for-frontend, não pode ser sobrescrito pelo usuário final. Exemplos de cabeçalhos podem incluir X-Real-IP, X-Forwarded-* ou X-User-ID.",2 -V4,API e Serviço Web,V4.1,Segurança Genérica de Serviços Web,V4.1.4,Verificar que apenas os métodos HTTP explicitamente suportados pela aplicação ou sua API (incluindo OPTIONS durante requisições preflight) podem ser usados e que métodos não utilizados estão bloqueados.,3 -V4,API e Serviço Web,V4.1,Segurança Genérica de Serviços Web,V4.1.5,Verificar que assinaturas digitais por mensagem são usadas para fornecer garantia adicional além das proteções de transporte para requisições ou transações altamente sensíveis ou que atravessam vários sistemas.,3 -V4,API e Serviço Web,V4.2,Validação da Estrutura de Mensagens HTTP,V4.2.1,"Verificar que todos os componentes da aplicação (incluindo balanceadores de carga, firewalls e servidores de aplicação) determinam os limites de mensagens HTTP recebidas usando o mecanismo adequado para a versão HTTP, a fim de prevenir HTTP request smuggling. Em HTTP/1.x, se um campo de cabeçalho Transfer-Encoding estiver presente, o Content-Length deve ser ignorado conforme a RFC 2616. Ao usar HTTP/2 ou HTTP/3, se um campo de cabeçalho Content-Length estiver presente, o receptor deve garantir que seja consistente com o comprimento dos frames DATA.",2 -V4,API e Serviço Web,V4.2,Validação da Estrutura de Mensagens HTTP,V4.2.2,"Verificar que, ao gerar mensagens HTTP, o campo de cabeçalho Content-Length não conflita com o comprimento do conteúdo determinado pelo enquadramento do protocolo HTTP, a fim de prevenir ataques de request smuggling.",3 -V4,API e Serviço Web,V4.2,Validação da Estrutura de Mensagens HTTP,V4.2.3,"Verificar que a aplicação não envia nem aceita mensagens HTTP/2 ou HTTP/3 com campos de cabeçalho específicos de conexão, como Transfer-Encoding, para prevenir ataques de divisão de resposta e injeção de cabeçalho.",3 -V4,API e Serviço Web,V4.2,Validação da Estrutura de Mensagens HTTP,V4.2.4,"Verificar que a aplicação aceita apenas requisições HTTP/2 e HTTP/3 onde os campos de cabeçalho e valores não contêm sequências CR (\r), LF (\n) ou CRLF (\r\n), para prevenir ataques de injeção de cabeçalho.",3 -V4,API e Serviço Web,V4.2,Validação da Estrutura de Mensagens HTTP,V4.2.5,"Verificar que, se a aplicação (backend ou frontend) constrói e envia requisições, ela usa validação, sanitização ou outros mecanismos para evitar a criação de URIs (como para chamadas de API) ou campos de cabeçalho HTTP (como Authorization ou Cookie) que sejam longos demais para serem aceitos pelo componente receptor. Isso poderia causar negação de serviço, como ao enviar uma requisição excessivamente longa (por exemplo, um campo de cabeçalho de cookie longo), que resulta no servidor sempre respondendo com um status de erro.",3 -V4,API e Serviço Web,V4.3,GraphQL,V4.3.1,"Verificar que uma lista de permissões de consultas, limitação de profundidade, limitação de quantidade ou análise de custo de consulta é usada para prevenir Negação de Serviço (DoS) em GraphQL ou em camadas de expressão de dados como resultado de consultas aninhadas caras.",2 -V4,API e Serviço Web,V4.3,GraphQL,V4.3.2,"Verificar que as consultas de introspecção do GraphQL estão desabilitadas no ambiente de produção, a menos que a API GraphQL seja destinada ao uso por outras partes.",2 -V4,API e Serviço Web,V4.4,WebSocket,V4.4.1,Verificar que WebSocket sobre TLS (WSS) é usado para todas as conexões WebSocket.,1 -V4,API e Serviço Web,V4.4,WebSocket,V4.4.2,"Verificar que, durante o handshake HTTP inicial do WebSocket, o campo de cabeçalho Origin é verificado em relação a uma lista de origens permitidas para a aplicação.",2 -V4,API e Serviço Web,V4.4,WebSocket,V4.4.3,"Verificar que, se o gerenciamento de sessão padrão da aplicação não puder ser usado, tokens dedicados estejam sendo usados para isso, em conformidade com os requisitos de segurança de Gerenciamento de Sessão relevantes.",2 -V4,API e Serviço Web,V4.4,WebSocket,V4.4.4,Verificar que tokens dedicados de gerenciamento de sessão WebSocket são inicialmente obtidos ou validados por meio da sessão HTTPS previamente autenticada ao fazer a transição de uma sessão HTTPS existente para um canal WebSocket.,2 -V5,Manipulação de Arquivos,V5.1,Documentação de Manipulação de Arquivos,V5.1.1,"Verificar que a documentação define os tipos de arquivos permitidos, extensões de arquivo esperadas e tamanho máximo (incluindo o tamanho descompactado) para cada funcionalidade de upload. Além disso, garantir que a documentação especifique como os arquivos são tornados seguros para download e processamento pelos usuários finais, como o comportamento da aplicação quando um arquivo malicioso é detectado.",2 -V5,Manipulação de Arquivos,V5.2,Upload de Arquivos e Conteúdo,V5.2.1,Verificar que a aplicação aceitará apenas arquivos de tamanho que ela possa processar sem causar perda de desempenho ou um ataque de negação de serviço.,1 -V5,Manipulação de Arquivos,V5.2,Upload de Arquivos e Conteúdo,V5.2.2,"Verificar que, ao aceitar um arquivo, seja isoladamente ou dentro de um arquivo comprimido como um zip, a aplicação verifica se a extensão do arquivo corresponde a uma extensão esperada e valida que o conteúdo corresponde ao tipo representado pela extensão. Isso inclui, mas não se limita a, verificar os 'bytes mágicos' iniciais, realizar reescrita de imagens e usar bibliotecas especializadas para validação de conteúdo de arquivo. Para L1, isso pode focar apenas em arquivos usados para tomar decisões específicas de negócio ou segurança. Para L2 e acima, deve ser aplicado a todos os arquivos recebidos.",1 -V5,Manipulação de Arquivos,V5.2,Upload de Arquivos e Conteúdo,V5.2.3,"Verificar que a aplicação verifica arquivos comprimidos (por exemplo, zip, gz, docx, odt) em relação ao tamanho máximo permitido descompactado e ao número máximo de arquivos antes de descompactar o arquivo.",2 -V5,Manipulação de Arquivos,V5.2,Upload de Arquivos e Conteúdo,V5.2.4,Verificar que uma cota de tamanho de arquivo e número máximo de arquivos por usuário são aplicados para garantir que um único usuário não possa preencher o armazenamento com muitos arquivos ou arquivos excessivamente grandes.,3 -V5,Manipulação de Arquivos,V5.2,Upload de Arquivos e Conteúdo,V5.2.5,"Verificar que a aplicação não permite o upload de arquivos comprimidos contendo links simbólicos, a menos que isso seja especificamente necessário (caso em que será necessário aplicar uma lista de permissões dos arquivos para os quais links simbólicos podem apontar).",3 -V5,Manipulação de Arquivos,V5.2,Upload de Arquivos e Conteúdo,V5.2.6,"Verificar que a aplicação rejeita imagens enviadas com tamanho em pixels maior que o máximo permitido, para prevenir ataques de pixel flood.",3 -V5,Manipulação de Arquivos,V5.3,Armazenamento de Arquivos,V5.3.1,Verificar que arquivos enviados por usuários ou gerados a partir de entradas não confiáveis e armazenados em uma pasta pública não são executados como código de programa no lado do servidor quando acessados diretamente por uma requisição HTTP.,1 -V5,Manipulação de Arquivos,V5.3,Armazenamento de Arquivos,V5.3.2,"Verificar que, ao criar caminhos de arquivo para operações com arquivos, a aplicação usa dados gerados internamente ou confiáveis, em vez de nomes de arquivos enviados pelo usuário, ou, se nomes de arquivos ou metadados enviados pelo usuário precisarem ser usados, validação e sanitização estritas devem ser aplicadas. Isso serve para proteger contra ataques de path traversal, inclusão de arquivo local ou remoto (LFI, RFI) e Server-side Request Forgery (SSRF).",1 -V5,Manipulação de Arquivos,V5.3,Armazenamento de Arquivos,V5.3.3,"Verificar que o processamento de arquivo no lado do servidor, como descompressão de arquivos, ignora as informações de caminho fornecidas pelo usuário para prevenir vulnerabilidades como zip slip.",3 -V5,Manipulação de Arquivos,V5.4,Download de Arquivos,V5.4.1,"Verificar que a aplicação valida ou ignora nomes de arquivos enviados pelo usuário, incluindo em parâmetros JSON, JSONP ou URL, e especifica um nome de arquivo no campo de cabeçalho Content-Disposition na resposta.",2 -V5,Manipulação de Arquivos,V5.4,Download de Arquivos,V5.4.2,"Verificar que os nomes de arquivos servidos (por exemplo, em campos de cabeçalho de resposta HTTP ou anexos de e-mail) são codificados ou sanitizados (por exemplo, seguindo a RFC 6266) para preservar a estrutura do documento e prevenir ataques de injeção.",2 -V5,Manipulação de Arquivos,V5.4,Download de Arquivos,V5.4.3,Verificar que arquivos obtidos de fontes não confiáveis são verificados por scanners antivírus para prevenir o fornecimento de conteúdo malicioso conhecido.,2 -V6,Autenticação,V6.1,Documentação de Autenticação,V6.1.1,"Verificar que a documentação da aplicação define como controles como limitação de taxa, anti-automação e resposta adaptativa são usados para se defender contra ataques como credential stuffing e força bruta de senha. A documentação deve deixar claro como esses controles são configurados e previnem o bloqueio malicioso de contas.",1 -V6,Autenticação,V6.1,Documentação de Autenticação,V6.1.2,"Verificar que uma lista de palavras específicas ao contexto está documentada para evitar seu uso em senhas. A lista pode incluir permutações de nomes de organização, nomes de produtos, identificadores de sistema, codinomes de projetos, nomes de departamentos ou cargos e similares.",2 -V6,Autenticação,V6.1,Documentação de Autenticação,V6.1.3,"Verificar que, se a aplicação inclui múltiplos caminhos de autenticação, todos estão documentados junto com os controles de segurança e a força de autenticação que deve ser aplicada de forma consistente em todos eles.",2 -V6,Autenticação,V6.2,Segurança de Senhas,V6.2.1,"Verificar que as senhas definidas pelos usuários têm pelo menos 8 caracteres, embora um mínimo de 15 caracteres seja fortemente recomendado.",1 -V6,Autenticação,V6.2,Segurança de Senhas,V6.2.2,Verificar que os usuários podem alterar sua senha.,1 -V6,Autenticação,V6.2,Segurança de Senhas,V6.2.3,Verificar que a funcionalidade de alteração de senha exige a senha atual e a nova senha do usuário.,1 -V6,Autenticação,V6.2,Segurança de Senhas,V6.2.4,"Verificar que as senhas enviadas durante o registro de conta ou alteração de senha são verificadas em relação a um conjunto disponível de, no mínimo, as 3.000 senhas mais comuns que correspondem à política de senha da aplicação — por exemplo, comprimento mínimo.",1 -V6,Autenticação,V6.2,Segurança de Senhas,V6.2.5,"Verificar que senhas de qualquer composição podem ser usadas, sem regras que limitem o tipo de caracteres permitidos. Não deve haver requisito de número mínimo de caracteres maiúsculos ou minúsculos, números ou caracteres especiais.",1 -V6,Autenticação,V6.2,Segurança de Senhas,V6.2.6,Verificar que os campos de entrada de senha usam type=password para mascarar a digitação. As aplicações podem permitir que o usuário visualize temporariamente toda a senha mascarada ou o último caractere digitado da senha.,1 -V6,Autenticação,V6.2,Segurança de Senhas,V6.2.7,"Verificar que a funcionalidade de 'colar', assistentes de senha do navegador e gerenciadores de senha externos são permitidos.",1 -V6,Autenticação,V6.2,Segurança de Senhas,V6.2.8,"Verificar que a aplicação verifica a senha do usuário exatamente como recebida, sem modificações como truncamento ou transformação de maiúsculas/minúsculas.",1 -V6,Autenticação,V6.2,Segurança de Senhas,V6.2.9,Verificar que senhas de pelo menos 64 caracteres são permitidas.,2 -V6,Autenticação,V6.2,Segurança de Senhas,V6.2.10,Verificar que a senha de um usuário permanece válida até que seja descoberta como comprometida ou o usuário a altere. A aplicação não deve exigir rotação periódica de credenciais.,2 -V6,Autenticação,V6.2,Segurança de Senhas,V6.2.11,Verificar que a lista documentada de palavras específicas ao contexto é usada para evitar a criação de senhas fáceis de adivinhar.,2 -V6,Autenticação,V6.2,Segurança de Senhas,V6.2.12,Verificar que as senhas enviadas durante o registro de conta ou alterações de senha são verificadas em relação a um conjunto de senhas comprometidas.,2 -V6,Autenticação,V6.3,Segurança Geral de Autenticação,V6.3.1,Verificar que controles para prevenir ataques como credential stuffing e força bruta de senha são implementados conforme a documentação de segurança da aplicação.,1 -V6,Autenticação,V6.3,Segurança Geral de Autenticação,V6.3.2,"Verificar que contas de usuário padrão (por exemplo, 'root', 'admin' ou 'sa') não estão presentes na aplicação ou estão desabilitadas.",1 -V6,Autenticação,V6.3,Segurança Geral de Autenticação,V6.3.3,"Verificar que um mecanismo de autenticação multifator ou uma combinação de mecanismos de autenticação de fator único deve ser usada para acessar a aplicação. Para L3, um dos fatores deve ser um mecanismo de autenticação baseado em hardware que forneça resistência a comprometimento e impersonificação contra ataques de phishing, verificando a intenção de autenticar ao exigir uma ação iniciada pelo usuário (como o pressionamento de um botão em uma chave de hardware FIDO ou um telefone celular). Flexibilizar qualquer uma das considerações deste requisito exige uma justificativa totalmente documentada e um conjunto abrangente de controles mitigadores.",2 -V6,Autenticação,V6.3,Segurança Geral de Autenticação,V6.3.4,"Verificar que, se a aplicação inclui múltiplos caminhos de autenticação, não há caminhos não documentados e que os controles de segurança e a força de autenticação são aplicados de forma consistente.",2 -V6,Autenticação,V6.3,Segurança Geral de Autenticação,V6.3.5,"Verificar que os usuários são notificados sobre tentativas de autenticação suspeitas (bem-sucedidas ou não). Isso pode incluir tentativas de autenticação de um local ou cliente incomum, autenticação parcialmente bem-sucedida (apenas um de múltiplos fatores), uma tentativa de autenticação após um longo período de inatividade ou uma autenticação bem-sucedida após várias tentativas fracassadas.",3 -V6,Autenticação,V6.3,Segurança Geral de Autenticação,V6.3.6,Verificar que o e-mail não é usado como mecanismo de autenticação de fator único ou multifator.,3 -V6,Autenticação,V6.3,Segurança Geral de Autenticação,V6.3.7,"Verificar que os usuários são notificados após atualizações nos detalhes de autenticação, como resets de credenciais ou modificação do nome de usuário ou endereço de e-mail.",3 -V6,Autenticação,V6.3,Segurança Geral de Autenticação,V6.3.8,"Verificar que usuários válidos não possam ser deduzidos a partir de desafios de autenticação falhos, como com base em mensagens de erro, códigos de resposta HTTP ou tempos de resposta diferentes. A funcionalidade de registro e recuperação de senha também deve ter essa proteção.",3 -V6,Autenticação,V6.4,Ciclo de Vida e Recuperação de Fatores de Autenticação,V6.4.1,"Verificar que senhas iniciais ou códigos de ativação gerados pelo sistema são gerados de forma aleatória e segura, seguem a política de senha existente e expiram após um curto período de tempo ou após o uso inicial. Esses segredos iniciais não devem ser permitidos a se tornarem a senha de longo prazo.",1 -V6,Autenticação,V6.4,Ciclo de Vida e Recuperação de Fatores de Autenticação,V6.4.2,Verificar que dicas de senha ou autenticação baseada em conhecimento (as chamadas 'perguntas secretas') não estão presentes.,1 -V6,Autenticação,V6.4,Ciclo de Vida e Recuperação de Fatores de Autenticação,V6.4.3,"Verificar que um processo seguro para redefinição de senha esquecida está implementado, que não ignora nenhum mecanismo de autenticação multifator habilitado.",2 -V6,Autenticação,V6.4,Ciclo de Vida e Recuperação de Fatores de Autenticação,V6.4.4,"Verificar que, se um fator de autenticação multifator for perdido, a comprovação de identidade é realizada no mesmo nível que durante o cadastro.",2 -V6,Autenticação,V6.4,Ciclo de Vida e Recuperação de Fatores de Autenticação,V6.4.5,"Verificar que as instruções de renovação para mecanismos de autenticação que expiram são enviadas com tempo suficiente para serem executadas antes que o mecanismo de autenticação antigo expire, configurando lembretes automatizados se necessário.",3 -V6,Autenticação,V6.4,Ciclo de Vida e Recuperação de Fatores de Autenticação,V6.4.6,"Verificar que os usuários administrativos podem iniciar o processo de redefinição de senha para o usuário, mas que isso não lhes permite alterar ou escolher a senha do usuário. Isso previne uma situação em que eles conhecem a senha do usuário.",3 -V6,Autenticação,V6.5,Requisitos Gerais de Autenticação Multifator,V6.5.1,"Verificar que segredos de consulta, requisições ou códigos de autenticação fora de banda e senhas de uso único baseadas em tempo (TOTPs) são usáveis com sucesso apenas uma vez.",2 -V6,Autenticação,V6.5,Requisitos Gerais de Autenticação Multifator,V6.5.2,"Verificar que, ao serem armazenados no backend da aplicação, segredos de consulta com menos de 112 bits de entropia (19 caracteres alfanuméricos aleatórios ou 34 dígitos aleatórios) são hasheados com um algoritmo de hash de armazenamento de senhas aprovado que incorpora um salt aleatório de 32 bits. Uma função de hash padrão pode ser usada se o segredo tiver 112 bits de entropia ou mais.",2 -V6,Autenticação,V6.5,Requisitos Gerais de Autenticação Multifator,V6.5.3,"Verificar que segredos de consulta, códigos de autenticação fora de banda e seeds de senha de uso único baseada em tempo são gerados usando um Gerador de Números Pseudoaleatórios Criptograficamente Seguro (CSPRNG) para evitar valores previsíveis.",2 -V6,Autenticação,V6.5,Requisitos Gerais de Autenticação Multifator,V6.5.4,Verificar que segredos de consulta e códigos de autenticação fora de banda têm um mínimo de 20 bits de entropia (tipicamente 4 caracteres alfanuméricos aleatórios ou 6 dígitos aleatórios são suficientes).,2 -V6,Autenticação,V6.5,Requisitos Gerais de Autenticação Multifator,V6.5.5,"Verificar que requisições, códigos ou tokens de autenticação fora de banda, bem como senhas de uso único baseadas em tempo (TOTPs), têm um tempo de vida definido. Requisições fora de banda devem ter um tempo de vida máximo de 10 minutos e, para TOTP, um tempo de vida máximo de 30 segundos.",2 -V6,Autenticação,V6.5,Requisitos Gerais de Autenticação Multifator,V6.5.6,Verificar que qualquer fator de autenticação (incluindo dispositivos físicos) pode ser revogado em caso de roubo ou outra perda.,3 -V6,Autenticação,V6.5,Requisitos Gerais de Autenticação Multifator,V6.5.7,Verificar que os mecanismos de autenticação biométrica são usados apenas como fatores secundários em conjunto com algo que você possui ou algo que você sabe.,3 -V6,Autenticação,V6.5,Requisitos Gerais de Autenticação Multifator,V6.5.8,Verificar que as senhas de uso único baseadas em tempo (TOTPs) são verificadas com base em uma fonte de tempo de um serviço confiável e não de um tempo não confiável ou fornecido pelo cliente.,3 -V6,Autenticação,V6.6,Mecanismos de Autenticação Fora de Banda,V6.6.1,"Verificar que os mecanismos de autenticação que usam a Rede Telefônica Pública Comutada (PSTN) para entregar Senhas de Uso Único (OTPs) via telefone ou SMS são oferecidos apenas quando o número de telefone foi previamente validado, métodos alternativos mais fortes (como Senhas de Uso Único Baseadas em Tempo) também são oferecidos, e o serviço fornece informações sobre seus riscos de segurança aos usuários. Para aplicações L3, telefone e SMS não devem estar disponíveis como opções.",2 -V6,Autenticação,V6.6,Mecanismos de Autenticação Fora de Banda,V6.6.2,"Verificar que requisições, códigos ou tokens de autenticação fora de banda estão vinculados à requisição de autenticação original para a qual foram gerados e não são utilizáveis para uma anterior ou subsequente.",2 -V6,Autenticação,V6.6,Mecanismos de Autenticação Fora de Banda,V6.6.3,Verificar que um mecanismo de autenticação fora de banda baseado em código é protegido contra ataques de força bruta por meio de limitação de taxa. Considere também usar um código com pelo menos 64 bits de entropia.,2 -V6,Autenticação,V6.6,Mecanismos de Autenticação Fora de Banda,V6.6.4,"Verificar que, onde notificações push são usadas para autenticação multifator, a limitação de taxa é usada para prevenir ataques de push bombing. O casamento de números também pode mitigar esse risco.",3 -V6,Autenticação,V6.7,Mecanismo de Autenticação Criptográfica,V6.7.1,Verificar que os certificados usados para verificar asserções de autenticação criptográfica são armazenados de uma forma que os protege de modificação.,3 -V6,Autenticação,V6.7,Mecanismo de Autenticação Criptográfica,V6.7.2,Verificar que o nonce de desafio tem pelo menos 64 bits de comprimento e é estatisticamente único ou único ao longo da vida útil do dispositivo criptográfico.,3 -V6,Autenticação,V6.8,Autenticação com Provedor de Identidade,V6.8.1,"Verificar que, se a aplicação suporta múltiplos provedores de identidade (IdPs), a identidade do usuário não pode ser falsificada por outro provedor de identidade suportado (por exemplo, usando o mesmo identificador de usuário). A mitigação padrão seria a aplicação registrar e identificar o usuário usando uma combinação do ID do IdP (servindo como namespace) e o ID do usuário no IdP.",2 -V6,Autenticação,V6.8,Autenticação com Provedor de Identidade,V6.8.2,"Verificar que a presença e a integridade de assinaturas digitais em asserções de autenticação (por exemplo, em JWTs ou asserções SAML) são sempre validadas, rejeitando quaisquer asserções não assinadas ou com assinaturas inválidas.",2 -V6,Autenticação,V6.8,Autenticação com Provedor de Identidade,V6.8.3,Verificar que as asserções SAML são processadas de forma única e usadas apenas uma vez dentro do período de validade para prevenir ataques de replay.,2 -V6,Autenticação,V6.8,Autenticação com Provedor de Identidade,V6.8.4,"Verificar que, se uma aplicação usa um Provedor de Identidade (IdP) separado e espera força de autenticação, métodos ou recenticidade específicos para funções específicas, a aplicação verifica isso usando as informações retornadas pelo IdP. Por exemplo, se OIDC é usado, isso pode ser alcançado validando claims do Token ID como 'acr', 'amr' e 'auth_time' (se presentes). Se o IdP não fornecer essas informações, a aplicação deve ter uma abordagem de fallback documentada que assume que o mecanismo de autenticação de força mínima foi usado (por exemplo, autenticação de fator único usando nome de usuário e senha).",2 -V7,Gerenciamento de Sessão,V7.1,Documentação de Gerenciamento de Sessão,V7.1.1,"Verificar que o tempo limite de inatividade da sessão do usuário e o tempo de vida máximo absoluto da sessão estão documentados, são apropriados em combinação com outros controles, e que a documentação inclui justificativa para quaisquer desvios dos requisitos de reautenticação da NIST SP 800-63B.",2 -V7,Gerenciamento de Sessão,V7.1,Documentação de Gerenciamento de Sessão,V7.1.2,"Verificar que a documentação define quantas sessões concorrentes (paralelas) são permitidas para uma conta, bem como os comportamentos e ações pretendidos quando o número máximo de sessões ativas for atingido.",2 -V7,Gerenciamento de Sessão,V7.1,Documentação de Gerenciamento de Sessão,V7.1.3,"Verificar que todos os sistemas que criam e gerenciam sessões de usuário como parte de um ecossistema de gerenciamento de identidade federada (como sistemas SSO) estão documentados junto com controles para coordenar o tempo de vida das sessões, encerramento e quaisquer outras condições que exijam reautenticação.",2 -V7,Gerenciamento de Sessão,V7.2,Segurança Fundamental do Gerenciamento de Sessão,V7.2.1,Verificar que a aplicação realiza toda a verificação de tokens de sessão usando um serviço de backend confiável.,1 -V7,Gerenciamento de Sessão,V7.2,Segurança Fundamental do Gerenciamento de Sessão,V7.2.2,"Verificar que a aplicação usa tokens autocontidos ou de referência gerados dinamicamente para gerenciamento de sessão — ou seja, não usa segredos e chaves de API estáticas.",1 -V7,Gerenciamento de Sessão,V7.2,Segurança Fundamental do Gerenciamento de Sessão,V7.2.3,"Verificar que, se tokens de referência são usados para representar sessões de usuário, eles são únicos e gerados usando um gerador de números pseudoaleatórios criptograficamente seguro (CSPRNG) e possuem pelo menos 128 bits de entropia.",1 -V7,Gerenciamento de Sessão,V7.2,Segurança Fundamental do Gerenciamento de Sessão,V7.2.4,"Verificar que a aplicação gera um novo token de sessão na autenticação do usuário, incluindo reautenticação, e encerra o token de sessão atual.",1 -V7,Gerenciamento de Sessão,V7.3,Tempo Limite de Sessão,V7.3.1,Verificar que há um tempo limite de inatividade que impõe a reautenticação conforme análise de risco e decisões de segurança documentadas.,2 -V7,Gerenciamento de Sessão,V7.3,Tempo Limite de Sessão,V7.3.2,Verificar que há um tempo de vida máximo absoluto de sessão que impõe a reautenticação conforme análise de risco e decisões de segurança documentadas.,2 -V7,Gerenciamento de Sessão,V7.4,Encerramento de Sessão,V7.4.1,"Verificar que, quando o encerramento da sessão é acionado (como logout ou expiração), a aplicação não permite mais nenhum uso da sessão. Para tokens de referência ou sessões stateful, isso significa invalidar os dados da sessão no backend da aplicação. Aplicações que usam tokens autocontidos precisarão de uma solução como manter uma lista de tokens encerrados, não permitir tokens produzidos antes de uma data e hora por usuário ou rotacionar uma chave de assinatura por usuário.",1 -V7,Gerenciamento de Sessão,V7.4,Encerramento de Sessão,V7.4.2,Verificar que a aplicação encerra todas as sessões ativas quando uma conta de usuário é desabilitada ou excluída (como um funcionário que deixa a empresa).,1 -V7,Gerenciamento de Sessão,V7.4,Encerramento de Sessão,V7.4.3,"Verificar que a aplicação dá a opção de encerrar todas as outras sessões ativas após uma mudança ou remoção bem-sucedida de qualquer fator de autenticação (incluindo alteração de senha via reset ou recuperação e, se presente, uma atualização das configurações de MFA).",2 -V7,Gerenciamento de Sessão,V7.4,Encerramento de Sessão,V7.4.4,Verificar que todas as páginas que exigem autenticação têm acesso fácil e visível à funcionalidade de logout.,2 -V7,Gerenciamento de Sessão,V7.4,Encerramento de Sessão,V7.4.5,Verificar que os administradores da aplicação são capazes de encerrar sessões ativas para um usuário individual ou para todos os usuários.,2 -V7,Gerenciamento de Sessão,V7.5,Defesas Contra Abuso de Sessão,V7.5.1,"Verificar que a aplicação exige reautenticação completa antes de permitir modificações em atributos sensíveis de conta que possam afetar a autenticação, como endereço de e-mail, número de telefone, configuração de MFA ou outras informações usadas na recuperação de conta.",2 -V7,Gerenciamento de Sessão,V7.5,Defesas Contra Abuso de Sessão,V7.5.2,Verificar que os usuários são capazes de visualizar e (tendo autenticado novamente com pelo menos um fator) encerrar qualquer uma ou todas as sessões ativas atualmente.,2 -V7,Gerenciamento de Sessão,V7.5,Defesas Contra Abuso de Sessão,V7.5.3,Verificar que a aplicação exige autenticação adicional com pelo menos um fator ou verificação secundária antes de realizar transações ou operações altamente sensíveis.,3 -V7,Gerenciamento de Sessão,V7.6,Reautenticação Federada,V7.6.1,"Verificar que o tempo de vida da sessão e o encerramento entre Partes Confiantes (RPs) e Provedores de Identidade (IdPs) se comportam conforme documentado, exigindo reautenticação quando necessário, como quando o tempo máximo entre eventos de autenticação no IdP é atingido.",2 -V7,Gerenciamento de Sessão,V7.6,Reautenticação Federada,V7.6.2,"Verificar que a criação de uma sessão exige o consentimento do usuário ou uma ação explícita, prevenindo a criação de novas sessões de aplicação sem interação do usuário.",2 -V8,Autorização,V8.1,Documentação de Autorização,V8.1.1,Verificar que a documentação de autorização define regras para restringir o acesso em nível de função e dados específicos com base nas permissões do consumidor e atributos do recurso.,1 -V8,Autorização,V8.1,Documentação de Autorização,V8.1.2,"Verificar que a documentação de autorização define regras para restrições de acesso em nível de campo (tanto leitura quanto escrita) com base nas permissões do consumidor e atributos do recurso. Observar que essas regras podem depender de outros valores de atributos do objeto de dados relevante, como estado ou status.",2 -V8,Autorização,V8.1,Documentação de Autorização,V8.1.3,"Verificar que a documentação da aplicação define os atributos ambientais e contextuais (incluindo, mas não se limitando a, hora do dia, localização do usuário, endereço IP ou dispositivo) que são usados na aplicação para tomar decisões de segurança, incluindo aquelas relacionadas à autenticação e autorização.",3 -V8,Autorização,V8.1,Documentação de Autorização,V8.1.4,"Verificar que a documentação de autenticação e autorização define como fatores ambientais e contextuais são usados na tomada de decisões, além da autorização em nível de função, dados específicos e nível de campo. Isso deve incluir os atributos avaliados, limiares de risco e ações tomadas (por exemplo, permitir, desafiar, negar, autenticação step-up).",3 -V8,Autorização,V8.2,Projeto Geral de Autorização,V8.2.1,Verificar que a aplicação garante que o acesso em nível de função é restrito a consumidores com permissões explícitas.,1 -V8,Autorização,V8.2,Projeto Geral de Autorização,V8.2.2,"Verificar que a aplicação garante que o acesso a dados específicos é restrito a consumidores com permissões explícitas para itens de dados específicos, para mitigar referência direta insegura a objetos (IDOR) e autorização quebrada em nível de objeto (BOLA).",1 -V8,Autorização,V8.2,Projeto Geral de Autorização,V8.2.3,"Verificar que a aplicação garante que o acesso em nível de campo é restrito a consumidores com permissões explícitas para campos específicos, para mitigar autorização quebrada em nível de propriedade de objeto (BOPLA).",2 -V8,Autorização,V8.2,Projeto Geral de Autorização,V8.2.4,"Verificar que controles de segurança adaptativa baseados nos atributos ambientais e contextuais de um consumidor (como hora do dia, localização, endereço IP ou dispositivo) são implementados para decisões de autenticação e autorização, conforme definido na documentação da aplicação. Esses controles devem ser aplicados quando o consumidor tenta iniciar uma nova sessão e também durante uma sessão existente.",3 -V8,Autorização,V8.3,Autorização em Nível de Operação,V8.3.1,"Verificar que a aplicação aplica regras de autorização em uma camada de serviço confiável e não depende de controles que um consumidor não confiável possa manipular, como JavaScript no lado do cliente.",1 -V8,Autorização,V8.3,Autorização em Nível de Operação,V8.3.2,"Verificar que as alterações nos valores sobre os quais as decisões de autorização são tomadas são aplicadas imediatamente. Onde alterações não podem ser aplicadas imediatamente (como quando se depende de dados em tokens autocontidos), devem existir controles mitigadores para alertar quando um consumidor realiza uma ação quando não está mais autorizado a fazê-lo e reverter a alteração. Observar que essa alternativa não mitigaria o vazamento de informações.",3 -V8,Autorização,V8.3,Autorização em Nível de Operação,V8.3.3,"Verificar que o acesso a um objeto é baseado nas permissões do sujeito originário (por exemplo, do consumidor), e não nas permissões de qualquer intermediário ou serviço que age em seu nome. Por exemplo, se um consumidor chama um serviço web usando um token autocontido para autenticação, e o serviço então solicita dados de um serviço diferente, o segundo serviço usará o token do consumidor, em vez de um token máquina-a-máquina do primeiro serviço, para tomar decisões de permissão.",3 -V8,Autorização,V8.4,Outras Considerações de Autorização,V8.4.1,Verificar que as aplicações multilocatárias usam controles entre locatários para garantir que as operações do consumidor nunca afetem locatários com os quais eles não têm permissão de interagir.,2 -V8,Autorização,V8.4,Outras Considerações de Autorização,V8.4.2,"Verificar que o acesso a interfaces administrativas incorpora múltiplas camadas de segurança, incluindo verificação contínua de identidade do consumidor, avaliação da postura de segurança do dispositivo e análise contextual de risco, garantindo que a localização na rede ou endpoints confiáveis não sejam os únicos fatores para autorização, mesmo que possam reduzir a probabilidade de acesso não autorizado.",3 -V9,Tokens Autocontidos,V9.1,Fonte e Integridade do Token,V9.1.1,Verificar que os tokens autocontidos são validados usando sua assinatura digital ou MAC para proteção contra adulteração antes de aceitar o conteúdo do token.,1 -V9,Tokens Autocontidos,V9.1,Fonte e Integridade do Token,V9.1.2,"Verificar que apenas algoritmos em uma lista de permissões podem ser usados para criar e verificar tokens autocontidos, para um dado contexto. A lista de permissões deve incluir os algoritmos permitidos, idealmente apenas algoritmos simétricos ou assimétricos, e não deve incluir o algoritmo 'None'. Se ambos simétricos e assimétricos precisarem ser suportados, serão necessários controles adicionais para prevenir confusão de chaves.",1 -V9,Tokens Autocontidos,V9.1,Fonte e Integridade do Token,V9.1.3,"Verificar que o material de chave usado para validar tokens autocontidos provém de fontes pré-configuradas confiáveis para o emissor do token, impedindo que atacantes especifiquem fontes e chaves não confiáveis. Para JWTs e outras estruturas JWS, cabeçalhos como 'jku', 'x5u' e 'jwk' devem ser validados em relação a uma lista de permissões de fontes confiáveis.",1 -V9,Tokens Autocontidos,V9.2,Conteúdo do Token,V9.2.1,"Verificar que, se um intervalo de validade de tempo estiver presente nos dados do token, o token e seu conteúdo são aceitos apenas se o tempo de verificação estiver dentro desse intervalo de validade. Por exemplo, para JWTs, os claims 'nbf' e 'exp' devem ser verificados.",1 -V9,Tokens Autocontidos,V9.2,Conteúdo do Token,V9.2.2,"Verificar que o serviço que recebe um token valida que o token é do tipo correto e se destina à finalidade pretendida antes de aceitar o conteúdo do token. Por exemplo, apenas tokens de acesso podem ser aceitos para decisões de autorização e apenas Tokens ID podem ser usados para comprovar a autenticação do usuário.",2 -V9,Tokens Autocontidos,V9.2,Conteúdo do Token,V9.2.3,"Verificar que o serviço aceita apenas tokens que se destinam ao uso com esse serviço (audiência). Para JWTs, isso pode ser alcançado validando o claim 'aud' em relação a uma lista de permissões definida no serviço.",2 -V9,Tokens Autocontidos,V9.2,Conteúdo do Token,V9.2.4,"Verificar que, se um emissor de token usa a mesma chave privada para emitir tokens para diferentes audiências, os tokens emitidos contêm uma restrição de audiência que identifica de forma única as audiências pretendidas. Isso evitará que um token seja reutilizado com uma audiência não pretendida. Se o identificador de audiência for provisionado dinamicamente, o emissor do token deve validar essas audiências para garantir que não resultem em impersonificação de audiência.",2 -V10,OAuth e OIDC,V10.1,Segurança Genérica de OAuth e OIDC,V10.1.1,"Verificar que os tokens são enviados apenas para componentes que estritamente precisam deles. Por exemplo, ao usar um padrão backend-for-frontend para aplicações JavaScript baseadas em navegador, tokens de acesso e de atualização devem ser acessíveis apenas para o backend.",2 -V10,OAuth e OIDC,V10.1,Segurança Genérica de OAuth e OIDC,V10.1.2,"Verificar que o cliente aceita valores do servidor de autorização (como o código de autorização ou Token ID) apenas se esses valores resultam de um fluxo de autorização iniciado pela mesma sessão do agente de usuário e transação. Isso requer que segredos gerados pelo cliente, como o 'code_verifier' da prova de chave para troca de código (PKCE), 'state' ou 'nonce' do OIDC, não sejam adivinháveis, sejam específicos à transação e estejam seguramente vinculados tanto ao cliente quanto à sessão do agente de usuário na qual a transação foi iniciada.",2 -V10,OAuth e OIDC,V10.2,Cliente OAuth,V10.2.1,"Verificar que, se o fluxo de código é usado, o cliente OAuth tem proteção contra ataques de falsificação de requisição baseados no navegador, comumente conhecidos como cross-site request forgery (CSRF), que acionam requisições de token, seja usando a funcionalidade de prova de chave para troca de código (PKCE) ou verificando o parâmetro 'state' que foi enviado na requisição de autorização.",2 -V10,OAuth e OIDC,V10.2,Cliente OAuth,V10.2.2,"Verificar que, se o cliente OAuth pode interagir com mais de um servidor de autorização, ele tem uma defesa contra ataques de mix-up. Por exemplo, poderia exigir que o servidor de autorização retorne o valor do parâmetro 'iss' e validá-lo na resposta de autorização e na resposta de token.",2 -V10,OAuth e OIDC,V10.2,Cliente OAuth,V10.2.3,Verificar que o cliente OAuth solicita apenas os escopos necessários (ou outros parâmetros de autorização) nas requisições ao servidor de autorização.,3 -V10,OAuth e OIDC,V10.3,Servidor de Recursos OAuth,V10.3.1,Verificar que o servidor de recursos aceita apenas tokens de acesso destinados ao uso com esse serviço (audiência). A audiência pode estar incluída em um token de acesso estruturado (como o claim 'aud' em JWT) ou pode ser verificada usando o endpoint de introspecção de token.,2 -V10,OAuth e OIDC,V10.3,Servidor de Recursos OAuth,V10.3.2,"Verificar que o servidor de recursos aplica decisões de autorização com base em claims do token de acesso que definem a autorização delegada. Se claims como 'sub', 'scope' e 'authorization_details' estiverem presentes, devem fazer parte da decisão.",2 -V10,OAuth e OIDC,V10.3,Servidor de Recursos OAuth,V10.3.3,"Verificar que, se uma decisão de controle de acesso requer a identificação de um usuário único a partir de um token de acesso (JWT ou resposta de introspecção de token relacionada), o servidor de recursos identifica o usuário a partir de claims que não podem ser reatribuídos a outros usuários. Tipicamente, isso significa usar uma combinação dos claims 'iss' e 'sub'.",2 -V10,OAuth e OIDC,V10.3,Servidor de Recursos OAuth,V10.3.4,"Verificar que, se o servidor de recursos requer força de autenticação, métodos ou recenticidade específicos, ele verifica se o token de acesso apresentado satisfaz essas restrições. Por exemplo, se presentes, usando os claims OIDC 'acr', 'amr' e 'auth_time' respectivamente.",2 -V10,OAuth e OIDC,V10.3,Servidor de Recursos OAuth,V10.3.5,"Verificar que o servidor de recursos previne o uso de tokens de acesso roubados ou replay de tokens de acesso (de partes não autorizadas) ao exigir tokens de acesso vinculados ao remetente, seja TLS Mútuo para OAuth 2 ou OAuth 2 Demonstration of Proof of Possession (DPoP).",3 -V10,OAuth e OIDC,V10.4,Servidor de Autorização OAuth,V10.4.1,Verificar que o servidor de autorização valida URIs de redirecionamento com base em uma lista de permissões específica do cliente com URIs pré-registrados usando comparação exata de strings.,1 -V10,OAuth e OIDC,V10.4,Servidor de Autorização OAuth,V10.4.2,"Verificar que, se o servidor de autorização retorna o código de autorização na resposta de autorização, ele só pode ser usado uma vez para uma requisição de token. Para a segunda requisição válida com um código de autorização que já foi usado para emitir um token de acesso, o servidor de autorização deve rejeitar a requisição de token e revogar todos os tokens emitidos relacionados ao código de autorização.",1 -V10,OAuth e OIDC,V10.4,Servidor de Autorização OAuth,V10.4.3,Verificar que o código de autorização tem vida curta. O tempo de vida máximo pode ser de até 10 minutos para aplicações L1 e L2 e de até 1 minuto para aplicações L3.,1 -V10,OAuth e OIDC,V10.4,Servidor de Autorização OAuth,V10.4.4,"Verificar que, para um determinado cliente, o servidor de autorização só permite o uso de concessões que esse cliente precisa usar. Observar que as concessões 'token' (fluxo Implícito) e 'password' (fluxo de Credenciais de Senha do Proprietário do Recurso) não devem mais ser usadas.",1 -V10,OAuth e OIDC,V10.4,Servidor de Autorização OAuth,V10.4.5,"Verificar que o servidor de autorização mitiga ataques de replay de token de atualização para clientes públicos, preferencialmente usando tokens de atualização vinculados ao remetente, ou seja, Demonstrating Proof of Possession (DPoP) ou Tokens de Acesso Vinculados a Certificado usando TLS mútuo (mTLS). Para aplicações L1 e L2, a rotação de token de atualização pode ser usada. Se a rotação de token de atualização for usada, o servidor de autorização deve invalidar o token de atualização após o uso e revogar todos os tokens de atualização para essa autorização se um token de atualização já usado e invalidado for fornecido.",1 -V10,OAuth e OIDC,V10.4,Servidor de Autorização OAuth,V10.4.6,"Verificar que, se o fluxo de código é usado, o servidor de autorização mitiga ataques de interceptação de código de autorização ao exigir prova de chave para troca de código (PKCE). Para requisições de autorização, o servidor de autorização deve exigir um valor 'code_challenge' válido e não deve aceitar um valor 'code_challenge_method' de 'plain'. Para uma requisição de token, deve exigir a validação do parâmetro 'code_verifier'.",2 -V10,OAuth e OIDC,V10.4,Servidor de Autorização OAuth,V10.4.7,"Verificar que, se o servidor de autorização suporta registro dinâmico de cliente não autenticado, ele mitiga o risco de aplicações cliente maliciosas. Deve validar metadados do cliente como quaisquer URIs registrados, garantir o consentimento do usuário e avisar o usuário antes de processar uma requisição de autorização com uma aplicação cliente não confiável.",2 -V10,OAuth e OIDC,V10.4,Servidor de Autorização OAuth,V10.4.8,"Verificar que os tokens de atualização têm uma expiração absoluta, incluindo se a expiração deslizante de token de atualização for aplicada.",2 -V10,OAuth e OIDC,V10.4,Servidor de Autorização OAuth,V10.4.9,"Verificar que tokens de atualização e tokens de acesso de referência podem ser revogados por um usuário autorizado usando a interface de usuário do servidor de autorização, para mitigar o risco de clientes maliciosos ou tokens roubados.",2 -V10,OAuth e OIDC,V10.4,Servidor de Autorização OAuth,V10.4.10,"Verificar que o cliente confidencial é autenticado para requisições de backchannel cliente-para-servidor autorizado, como requisições de token, requisições de autorização enviadas (PAR) e requisições de revogação de token.",2 -V10,OAuth e OIDC,V10.4,Servidor de Autorização OAuth,V10.4.11,Verificar que a configuração do servidor de autorização atribui apenas os escopos necessários ao cliente OAuth.,2 -V10,OAuth e OIDC,V10.4,Servidor de Autorização OAuth,V10.4.12,"Verificar que, para um determinado cliente, o servidor de autorização só permite o valor de 'response_mode' que esse cliente precisa usar. Por exemplo, fazendo com que o servidor de autorização valide esse valor em relação aos valores esperados ou usando requisição de autorização enviada (PAR) ou Requisição de Autorização Protegida com JWT (JAR).",3 -V10,OAuth e OIDC,V10.4,Servidor de Autorização OAuth,V10.4.13,Verificar que o tipo de concessão 'code' é sempre usado em conjunto com requisições de autorização enviadas (PAR).,3 -V10,OAuth e OIDC,V10.4,Servidor de Autorização OAuth,V10.4.14,"Verificar que o servidor de autorização emite apenas tokens de acesso vinculados ao remetente (Proof-of-Possession), seja com tokens de acesso vinculados a certificado usando TLS mútuo (mTLS) ou tokens de acesso vinculados ao DPoP (Demonstration of Proof of Possession).",3 -V10,OAuth e OIDC,V10.4,Servidor de Autorização OAuth,V10.4.15,"Verificar que, para um cliente do lado do servidor (que não é executado no dispositivo do usuário final), o servidor de autorização garante que o valor do parâmetro 'authorization_details' seja do backend do cliente e que o usuário não o tenha adulterado. Por exemplo, exigindo o uso de requisição de autorização enviada (PAR) ou Requisição de Autorização Protegida com JWT (JAR).",3 -V10,OAuth e OIDC,V10.4,Servidor de Autorização OAuth,V10.4.16,"Verificar que o cliente é confidencial e o servidor de autorização exige o uso de métodos fortes de autenticação de cliente (baseados em criptografia de chave pública e resistentes a ataques de replay), como TLS mútuo ('tls_client_auth', 'self_signed_tls_client_auth') ou JWT de chave privada ('private_key_jwt').",3 -V10,OAuth e OIDC,V10.5,Cliente OIDC,V10.5.1,"Verificar que o cliente (como parte confiante) mitiga ataques de replay de Token ID. Por exemplo, garantindo que o claim 'nonce' no Token ID corresponda ao valor 'nonce' enviado na requisição de autenticação ao Provedor OpenID (em OAuth2 referido como a requisição de autorização enviada ao servidor de autorização).",2 -V10,OAuth e OIDC,V10.5,Cliente OIDC,V10.5.2,"Verificar que o cliente identifica de forma única o usuário a partir dos claims do Token ID, geralmente o claim 'sub', que não pode ser reatribuído a outros usuários (para o escopo de um provedor de identidade).",2 -V10,OAuth e OIDC,V10.5,Cliente OIDC,V10.5.3,Verificar que o cliente rejeita tentativas de um servidor de autorização malicioso de se passar por outro servidor de autorização por meio de metadados do servidor de autorização. O cliente deve rejeitar metadados do servidor de autorização se a URL do emissor nos metadados do servidor de autorização não corresponder exatamente à URL do emissor pré-configurada esperada pelo cliente.,2 -V10,OAuth e OIDC,V10.5,Cliente OIDC,V10.5.4,Verificar que o cliente valida que o Token ID é destinado ao uso para esse cliente (audiência) verificando que o claim 'aud' do token é igual ao valor 'client_id' do cliente.,2 -V10,OAuth e OIDC,V10.5,Cliente OIDC,V10.5.5,"Verificar que, ao usar o logout de backchannel OIDC, a parte confiante mitiga a negação de serviço por logout forçado e confusão entre JWTs no fluxo de logout. O cliente deve verificar que o token de logout tem o tipo correto com um valor de 'logout+jwt', contém o claim 'event' com o nome de membro correto e não contém um claim 'nonce'. Observar que também é recomendado ter uma expiração curta (por exemplo, 2 minutos).",2 -V10,OAuth e OIDC,V10.6,Provedor OpenID,V10.6.1,"Verificar que o Provedor OpenID permite apenas os valores 'code', 'ciba', 'id_token' ou 'id_token code' para modo de resposta. Observar que 'code' é preferido em relação a 'id_token code' (o fluxo Híbrido OIDC) e 'token' (qualquer fluxo Implícito) não deve ser usado.",2 -V10,OAuth e OIDC,V10.6,Provedor OpenID,V10.6.2,"Verificar que o Provedor OpenID mitiga a negação de serviço por logout forçado. Obtendo confirmação explícita do usuário final ou, se presentes, validando os parâmetros na requisição de logout (iniciada pela parte confiante), como o 'id_token_hint'.",2 -V10,OAuth e OIDC,V10.7,Gerenciamento de Consentimento,V10.7.1,"Verificar que o servidor de autorização garante que o usuário consente a cada requisição de autorização. Se a identidade do cliente não puder ser assegurada, o servidor de autorização deve sempre solicitar explicitamente o consentimento do usuário.",2 -V10,OAuth e OIDC,V10.7,Gerenciamento de Consentimento,V10.7.2,"Verificar que, ao solicitar o consentimento do usuário, o servidor de autorização apresenta informações suficientes e claras sobre o que está sendo consentido. Quando aplicável, isso deve incluir a natureza das autorizações solicitadas (tipicamente com base no escopo, servidor de recursos, detalhes de autorização Rich Authorization Requests (RAR)), a identidade da aplicação autorizada e o tempo de vida dessas autorizações.",2 -V10,OAuth e OIDC,V10.7,Gerenciamento de Consentimento,V10.7.3,"Verificar que o usuário pode revisar, modificar e revogar consentimentos que ele concedeu por meio do servidor de autorização.",2 -V11,Criptografia,V11.1,Inventário e Documentação Criptográfica,V11.1.1,"Verificar que existe uma política documentada para gerenciamento de chaves criptográficas e um ciclo de vida de chaves criptográficas que segue um padrão de gerenciamento de chaves como o NIST SP 800-57. Isso deve incluir garantir que as chaves não sejam compartilhadas em excesso (por exemplo, com mais de duas entidades para segredos compartilhados e mais de uma entidade para chaves privadas).",2 -V11,Criptografia,V11.1,Inventário e Documentação Criptográfica,V11.1.2,"Verificar que um inventário criptográfico é realizado, mantido, regularmente atualizado e inclui todas as chaves criptográficas, algoritmos e certificados usados pela aplicação. Também deve documentar onde as chaves podem e não podem ser usadas no sistema e os tipos de dados que podem e não podem ser protegidos usando as chaves.",2 -V11,Criptografia,V11.1,Inventário e Documentação Criptográfica,V11.1.3,"Verificar que mecanismos de descoberta criptográfica são empregados para identificar todas as instâncias de criptografia no sistema, incluindo operações de criptografia, hash e assinatura.",3 -V11,Criptografia,V11.1,Inventário e Documentação Criptográfica,V11.1.4,"Verificar que um inventário criptográfico é mantido. Deve incluir um plano documentado que delineie o caminho de migração para novos padrões criptográficos, como criptografia pós-quântica, a fim de reagir a ameaças futuras.",3 -V11,Criptografia,V11.2,Implementação Segura de Criptografia,V11.2.1,Verificar que implementações validadas pela indústria (incluindo bibliotecas e implementações aceleradas por hardware) são usadas para operações criptográficas.,2 -V11,Criptografia,V11.2,Implementação Segura de Criptografia,V11.2.2,"Verificar que a aplicação é projetada com agilidade criptográfica, de modo que os algoritmos de número aleatório, criptografia autenticada, MAC ou hash, comprimentos de chave, rodadas, cifras e modos possam ser reconfigurados, atualizados ou substituídos a qualquer momento, para proteger contra rupturas criptográficas. Da mesma forma, também deve ser possível substituir chaves e senhas e recriptografar dados. Isso permitirá atualizações contínuas para criptografia pós-quântica (PQC), quando implementações de alta segurança de esquemas ou padrões PQC aprovados estiverem amplamente disponíveis.",2 -V11,Criptografia,V11.2,Implementação Segura de Criptografia,V11.2.3,"Verificar que todas as primitivas criptográficas utilizam um mínimo de 128 bits de segurança com base no algoritmo, tamanho de chave e configuração. Por exemplo, uma chave ECC de 256 bits fornece aproximadamente 128 bits de segurança, enquanto o RSA requer uma chave de 3072 bits para atingir 128 bits de segurança.",2 -V11,Criptografia,V11.2,Implementação Segura de Criptografia,V11.2.4,"Verificar que todas as operações criptográficas são de tempo constante, sem operações de 'curto-circuito' em comparações, cálculos ou retornos, para evitar o vazamento de informações.",3 -V11,Criptografia,V11.2,Implementação Segura de Criptografia,V11.2.5,"Verificar que todos os módulos criptográficos falham de forma segura e os erros são tratados de maneira que não habilite vulnerabilidades, como ataques de Padding Oracle.",3 -V11,Criptografia,V11.3,Algoritmos de Criptografia,V11.3.1,"Verificar que modos de bloco inseguros (por exemplo, ECB) e esquemas de padding fracos (por exemplo, PKCS#1 v1.5) não são usados.",1 -V11,Criptografia,V11.3,Algoritmos de Criptografia,V11.3.2,"Verificar que apenas cifras e modos aprovados, como AES com GCM, são usados.",1 -V11,Criptografia,V11.3,Algoritmos de Criptografia,V11.3.3,"Verificar que dados criptografados são protegidos contra modificação não autorizada, preferencialmente usando um método de criptografia autenticada aprovado ou combinando um método de criptografia aprovado com um algoritmo MAC aprovado.",2 -V11,Criptografia,V11.3,Algoritmos de Criptografia,V11.3.4,"Verificar que nonces, vetores de inicialização e outros números de uso único não são reutilizados para mais de um par de chave de criptografia e elemento de dado. O método de geração deve ser adequado para o algoritmo em uso.",3 -V11,Criptografia,V11.3,Algoritmos de Criptografia,V11.3.5,Verificar que qualquer combinação de um algoritmo de criptografia e um algoritmo MAC está operando no modo encrypt-then-MAC.,3 -V11,Criptografia,V11.4,Funções de Hash e Baseadas em Hash,V11.4.1,"Verificar que apenas funções de hash aprovadas são usadas para casos de uso criptográfico geral, incluindo assinaturas digitais, HMAC, KDF e geração de bits aleatórios. Funções de hash não permitidas, como MD5, não devem ser usadas para nenhuma finalidade criptográfica.",1 -V11,Criptografia,V11.4,Funções de Hash e Baseadas em Hash,V11.4.2,"Verificar que as senhas são armazenadas usando uma função de derivação de chave aprovada e computacionalmente intensiva (também conhecida como 'função de hash de senha'), com configurações de parâmetros configuradas com base na orientação atual. As configurações devem equilibrar segurança e desempenho para tornar os ataques de força bruta suficientemente desafiadores para o nível de segurança exigido.",2 -V11,Criptografia,V11.4,Funções de Hash e Baseadas em Hash,V11.4.3,"Verificar que as funções de hash usadas em assinaturas digitais, como parte de autenticação de dados ou integridade de dados, são resistentes a colisão e têm comprimentos de bits adequados. Se a resistência à colisão for necessária, o comprimento de saída deve ser de pelo menos 256 bits. Se apenas a resistência a ataques de segunda pré-imagem for necessária, o comprimento de saída deve ser de pelo menos 128 bits.",2 -V11,Criptografia,V11.4,Funções de Hash e Baseadas em Hash,V11.4.4,Verificar que a aplicação usa funções de derivação de chave aprovadas com parâmetros de key stretching ao derivar chaves secretas de senhas. Os parâmetros em uso devem equilibrar segurança e desempenho para prevenir ataques de força bruta de comprometer a chave criptográfica resultante.,2 -V11,Criptografia,V11.5,Valores Aleatórios,V11.5.1,Verificar que todos os números e strings aleatórios destinados a ser não adivinháveis devem ser gerados usando um gerador de números pseudoaleatórios criptograficamente seguro (CSPRNG) e ter pelo menos 128 bits de entropia. Observar que UUIDs não respeitam essa condição.,2 -V11,Criptografia,V11.5,Valores Aleatórios,V11.5.2,"Verificar que o mecanismo de geração de números aleatórios em uso é projetado para funcionar de forma segura, mesmo sob alta demanda.",3 -V11,Criptografia,V11.6,Criptografia de Chave Pública,V11.6.1,"Verificar que apenas algoritmos e modos de operação criptográficos aprovados são usados para geração e inicialização de chaves, e geração e verificação de assinatura digital. Os algoritmos de geração de chave não devem gerar chaves inseguras vulneráveis a ataques conhecidos, por exemplo, chaves RSA que são vulneráveis à fatoração de Fermat.",2 -V11,Criptografia,V11.6,Criptografia de Chave Pública,V11.6.2,Verificar que algoritmos criptográficos aprovados são usados para troca de chaves (como Diffie-Hellman) com foco em garantir que os mecanismos de troca de chaves usem parâmetros seguros. Isso prevenirá ataques no processo de estabelecimento de chave que possam levar a ataques adversário-no-meio ou rupturas criptográficas.,3 -V11,Criptografia,V11.7,Criptografia de Dados em Uso,V11.7.1,"Verificar que a criptografia completa de memória está em uso, protegendo dados sensíveis enquanto estão em uso, prevenindo acesso por usuários ou processos não autorizados.",3 -V11,Criptografia,V11.7,Criptografia de Dados em Uso,V11.7.2,"Verificar que a minimização de dados garante que a quantidade mínima de dados seja exposta durante o processamento, e garantir que os dados sejam criptografados imediatamente após o uso ou assim que possível.",3 -V12,Comunicação Segura,V12.1,Orientações Gerais de Segurança TLS,V12.1.1,"Verificar que apenas as versões mais recentes recomendadas do protocolo TLS estão habilitadas, como TLS 1.2 e TLS 1.3. A versão mais recente do protocolo TLS deve ser a opção preferida.",1 -V12,Comunicação Segura,V12.1,Orientações Gerais de Segurança TLS,V12.1.2,"Verificar que apenas suítes de cifra recomendadas estão habilitadas, com as suítes de cifra mais fortes definidas como preferidas. Aplicações L3 devem suportar apenas suítes de cifra que fornecem sigilo de encaminhamento.",2 -V12,Comunicação Segura,V12.1,Orientações Gerais de Segurança TLS,V12.1.3,Verificar que a aplicação valida que os certificados de cliente mTLS são confiáveis antes de usar a identidade do certificado para autenticação ou autorização.,2 -V12,Comunicação Segura,V12.1,Orientações Gerais de Segurança TLS,V12.1.4,"Verificar que a revogação adequada de certificação, como o OCSP Stapling (Online Certificate Status Protocol), está habilitada e configurada.",3 -V12,Comunicação Segura,V12.1,Orientações Gerais de Segurança TLS,V12.1.5,"Verificar que o Encrypted Client Hello (ECH) está habilitado nas configurações TLS da aplicação para prevenir a exposição de metadados sensíveis, como a Indicação de Nome do Servidor (SNI), durante os processos de handshake TLS.",3 -V12,Comunicação Segura,V12.2,Comunicação HTTPS com Serviços Externos,V12.2.1,"Verificar que TLS é usado para toda a conectividade entre um cliente e serviços HTTP externos, e que não há fallback para comunicações inseguras ou não criptografadas.",1 -V12,Comunicação Segura,V12.2,Comunicação HTTPS com Serviços Externos,V12.2.2,Verificar que os serviços externos usam certificados TLS publicamente confiáveis.,1 -V12,Comunicação Segura,V12.3,Segurança Geral de Comunicação entre Serviços,V12.3.1,"Verificar que um protocolo criptografado como TLS é usado para todas as conexões de entrada e saída de e para a aplicação, incluindo sistemas de monitoramento, ferramentas de gerenciamento, acesso remoto e SSH, middleware, bancos de dados, mainframes, sistemas parceiros ou APIs externas. O servidor não deve realizar fallback para protocolos inseguros ou não criptografados.",2 -V12,Comunicação Segura,V12.3,Segurança Geral de Comunicação entre Serviços,V12.3.2,Verificar que os clientes TLS validam os certificados recebidos antes de se comunicar com um servidor TLS.,2 -V12,Comunicação Segura,V12.3,Segurança Geral de Comunicação entre Serviços,V12.3.3,"Verificar que TLS ou outro mecanismo apropriado de criptografia de transporte é usado para toda a conectividade entre serviços HTTP internos na aplicação, e que não há fallback para comunicações inseguras ou não criptografadas.",2 -V12,Comunicação Segura,V12.3,Segurança Geral de Comunicação entre Serviços,V12.3.4,"Verificar que as conexões TLS entre serviços internos usam certificados confiáveis. Onde certificados gerados internamente ou autoassinados são usados, o serviço consumidor deve ser configurado para confiar apenas em CAs internas específicas e certificados autoassinados específicos.",2 -V12,Comunicação Segura,V12.3,Segurança Geral de Comunicação entre Serviços,V12.3.5,"Verificar que os serviços que se comunicam internamente em um sistema (comunicações intraserviço) usam autenticação forte para garantir que cada endpoint seja verificado. Métodos de autenticação fortes, como autenticação de cliente TLS, devem ser empregados para garantir a identidade, usando infraestrutura de chave pública e mecanismos resistentes a ataques de replay. Para arquiteturas de microsserviços, considere usar um service mesh para simplificar o gerenciamento de certificados e aprimorar a segurança.",3 -V13,Configuração,V13.1,Documentação de Configuração,V13.1.1,Verificar que todas as necessidades de comunicação da aplicação estão documentadas. Isso deve incluir serviços externos dos quais a aplicação depende e casos onde um usuário final pode fornecer um local externo ao qual a aplicação se conectará.,2 -V13,Configuração,V13.1,Documentação de Configuração,V13.1.2,"Verificar que, para cada serviço que a aplicação usa, a documentação define o número máximo de conexões simultâneas (por exemplo, limites de pool de conexões) e como a aplicação se comporta quando esse limite é atingido, incluindo quaisquer mecanismos de fallback ou recuperação, para prevenir condições de negação de serviço.",3 -V13,Configuração,V13.1,Documentação de Configuração,V13.1.3,"Verificar que a documentação da aplicação define estratégias de gerenciamento de recursos para cada sistema ou serviço externo que usa (por exemplo, bancos de dados, descritores de arquivo, threads, conexões HTTP). Isso deve incluir procedimentos de liberação de recursos, configurações de timeout, tratamento de falhas e, onde a lógica de retry é implementada, especificando limites de retry, atrasos e algoritmos de backoff. Para operações síncronas de requisição-resposta HTTP, deve exigir timeouts curtos e desabilitar ou limitar estritamente os retries para prevenir atrasos em cascata e esgotamento de recursos.",3 -V13,Configuração,V13.1,Documentação de Configuração,V13.1.4,"Verificar que a documentação da aplicação define os segredos críticos para a segurança da aplicação e um cronograma para rotacioná-los, com base no modelo de ameaças e requisitos de negócio da organização.",3 -V13,Configuração,V13.2,Configuração de Comunicação com Backend,V13.2.1,"Verificar que as comunicações entre componentes de aplicação backend que não suportam o mecanismo de sessão de usuário padrão da aplicação, incluindo APIs, middleware e camadas de dados, são autenticadas. A autenticação deve usar contas de serviço individuais, tokens de curto prazo ou autenticação baseada em certificado, e não credenciais imutáveis como senhas, chaves de API ou contas compartilhadas com acesso privilegiado.",2 -V13,Configuração,V13.2,Configuração de Comunicação com Backend,V13.2.2,"Verificar que as comunicações entre componentes de aplicação backend, incluindo serviços locais ou do sistema operacional, APIs, middleware e camadas de dados, são realizadas com contas atribuídas ao menor privilégio necessário.",2 -V13,Configuração,V13.2,Configuração de Comunicação com Backend,V13.2.3,"Verificar que, se uma credencial tiver de ser usada para autenticação de serviço, a credencial usada pelo consumidor não é uma credencial padrão (por exemplo, root/root ou admin/admin).",2 -V13,Configuração,V13.2,Configuração de Comunicação com Backend,V13.2.4,"Verificar que uma lista de permissões é usada para definir os recursos ou sistemas externos com os quais a aplicação tem permissão de se comunicar (por exemplo, para requisições de saída, cargas de dados ou acesso a arquivos). Essa lista de permissões pode ser implementada na camada de aplicação, servidor web, firewall ou uma combinação de diferentes camadas.",2 -V13,Configuração,V13.2,Configuração de Comunicação com Backend,V13.2.5,Verificar que o servidor web ou de aplicação está configurado com uma lista de permissões de recursos ou sistemas para os quais o servidor pode enviar requisições ou carregar dados ou arquivos.,2 -V13,Configuração,V13.2,Configuração de Comunicação com Backend,V13.2.6,"Verificar que, onde a aplicação se conecta a serviços separados, ela segue a configuração documentada para cada conexão, como número máximo de conexões paralelas, comportamento quando o número máximo de conexões permitidas é atingido, timeouts de conexão e estratégias de retry.",3 -V13,Configuração,V13.3,Gerenciamento de Segredos,V13.3.1,"Verificar que uma solução de gerenciamento de segredos, como um cofre de chaves, é usada para criar, armazenar, controlar o acesso e destruir segredos de backend de forma segura. Estes podem incluir senhas, material de chave, integrações com bancos de dados e sistemas de terceiros, chaves e seeds para tokens baseados em tempo, outros segredos internos e chaves de API. Os segredos não devem ser incluídos no código-fonte da aplicação ou em artefatos de build. Para uma aplicação L3, isso deve envolver uma solução respaldada por hardware como um HSM.",2 -V13,Configuração,V13.3,Gerenciamento de Segredos,V13.3.2,Verificar que o acesso a ativos de segredo adere ao princípio do menor privilégio.,2 -V13,Configuração,V13.3,Gerenciamento de Segredos,V13.3.3,Verificar que todas as operações criptográficas são realizadas usando um módulo de segurança isolado (como um cofre ou módulo de segurança de hardware) para gerenciar e proteger de forma segura o material de chave contra exposição fora do módulo de segurança.,3 -V13,Configuração,V13.3,Gerenciamento de Segredos,V13.3.4,Verificar que os segredos são configurados para expirar e ser rotacionados com base na documentação da aplicação.,3 -V13,Configuração,V13.4,Vazamento Não Intencional de Informações,V13.4.1,"Verificar que a aplicação é implantada sem nenhum metadado de controle de código-fonte, incluindo as pastas .git ou .svn, ou de uma forma que essas pastas sejam inacessíveis tanto externamente quanto pela própria aplicação.",1 -V13,Configuração,V13.4,Vazamento Não Intencional de Informações,V13.4.2,"Verificar que os modos de depuração estão desabilitados para todos os componentes nos ambientes de produção, para prevenir a exposição de recursos de depuração e vazamento de informações.",2 -V13,Configuração,V13.4,Vazamento Não Intencional de Informações,V13.4.3,"Verificar que os servidores web não expõem listagens de diretório aos clientes, a menos que seja explicitamente pretendido.",2 -V13,Configuração,V13.4,Vazamento Não Intencional de Informações,V13.4.4,"Verificar que o uso do método HTTP TRACE não é suportado em ambientes de produção, para evitar possível vazamento de informações.",2 -V13,Configuração,V13.4,Vazamento Não Intencional de Informações,V13.4.5,"Verificar que documentação (como para APIs internas) e endpoints de monitoramento não são expostos, a menos que seja explicitamente pretendido.",2 -V13,Configuração,V13.4,Vazamento Não Intencional de Informações,V13.4.6,Verificar que a aplicação não expõe informações detalhadas de versão dos componentes de backend.,3 -V13,Configuração,V13.4,Vazamento Não Intencional de Informações,V13.4.7,"Verificar que a camada web está configurada para servir apenas arquivos com extensões de arquivo específicas, para prevenir o vazamento não intencional de informações, configurações e código-fonte.",3 -V14,Proteção de Dados,V14.1,Documentação de Proteção de Dados,V14.1.1,"Verificar que todos os dados sensíveis criados e processados pela aplicação foram identificados e classificados em níveis de proteção. Isso inclui dados que são apenas codificados e, portanto, facilmente decodificados, como strings Base64 ou o payload em texto simples dentro de um JWT. Os níveis de proteção precisam levar em conta quaisquer regulamentos e padrões de proteção de dados e privacidade com os quais a aplicação deve estar em conformidade.",2 -V14,Proteção de Dados,V14.1,Documentação de Proteção de Dados,V14.1.2,"Verificar que todos os níveis de proteção de dados sensíveis têm um conjunto documentado de requisitos de proteção. Isso deve incluir (mas não se limitar a) requisitos relacionados à criptografia geral, verificação de integridade, retenção, como os dados devem ser registrados, controles de acesso em torno de dados sensíveis em logs, criptografia em nível de banco de dados, privacidade e tecnologias de aprimoramento de privacidade a serem usadas, e outros requisitos de confidencialidade.",2 -V14,Proteção de Dados,V14.2,Proteção Geral de Dados,V14.2.1,"Verificar que dados sensíveis são enviados ao servidor apenas no corpo da mensagem HTTP ou campos de cabeçalho, e que a URL e a string de consulta não contêm informações sensíveis, como uma chave de API ou token de sessão.",1 -V14,Proteção de Dados,V14.2,Proteção Geral de Dados,V14.2.2,"Verificar que a aplicação evita que dados sensíveis sejam armazenados em cache em componentes do servidor, como balanceadores de carga e caches de aplicação, ou garante que os dados sejam purgados de forma segura após o uso.",2 -V14,Proteção de Dados,V14.2,Proteção Geral de Dados,V14.2.3,"Verificar que dados sensíveis definidos não são enviados a partes não confiáveis (por exemplo, rastreadores de usuários) para evitar a coleta indesejada de dados fora do controle da aplicação.",2 -V14,Proteção de Dados,V14.2,Proteção Geral de Dados,V14.2.4,"Verificar que os controles em torno de dados sensíveis relacionados à criptografia, verificação de integridade, retenção, como os dados devem ser registrados, controles de acesso em torno de dados sensíveis em logs, privacidade e tecnologias de aprimoramento de privacidade são implementados conforme definido na documentação para o nível de proteção dos dados específicos.",2 -V14,Proteção de Dados,V14.2,Proteção Geral de Dados,V14.2.5,"Verificar que os mecanismos de cache são configurados para armazenar em cache apenas respostas que têm o tipo de conteúdo esperado para esse recurso e não contêm conteúdo dinâmico e sensível. O servidor web deve retornar uma resposta 404 ou 302 quando um arquivo inexistente é acessado, em vez de retornar um arquivo diferente e válido. Isso deve prevenir ataques de Web Cache Deception.",3 -V14,Proteção de Dados,V14.2,Proteção Geral de Dados,V14.2.6,"Verificar que a aplicação retorna apenas o mínimo de dados sensíveis necessários para a funcionalidade da aplicação. Por exemplo, retornar apenas alguns dígitos de um número de cartão de crédito e não o número completo. Se os dados completos forem necessários, devem ser mascarados na interface do usuário, a menos que o usuário os visualize especificamente.",3 -V14,Proteção de Dados,V14.2,Proteção Geral de Dados,V14.2.7,"Verificar que as informações sensíveis estão sujeitas à classificação de retenção de dados, garantindo que dados desatualizados ou desnecessários sejam excluídos automaticamente, em um cronograma definido ou conforme a situação exigir.",3 -V14,Proteção de Dados,V14.2,Proteção Geral de Dados,V14.2.8,"Verificar que informações sensíveis são removidas dos metadados de arquivos enviados pelo usuário, a menos que o armazenamento seja consentido pelo usuário.",3 -V14,Proteção de Dados,V14.3,Proteção de Dados no Lado do Cliente,V14.3.1,"Verificar que os dados autenticados são limpos do armazenamento do cliente, como o DOM do navegador, após o término do cliente ou da sessão. O campo de cabeçalho HTTP de resposta 'Clear-Site-Data' pode ajudar nisso, mas o lado do cliente também deve ser capaz de limpar se a conexão com o servidor não estiver disponível quando a sessão for encerrada.",1 -V14,Proteção de Dados,V14.3,Proteção de Dados no Lado do Cliente,V14.3.2,"Verificar que a aplicação define campos de cabeçalho HTTP de resposta anti-cache suficientes (ou seja, Cache-Control: no-store) para que dados sensíveis não sejam armazenados em cache nos navegadores.",2 -V14,Proteção de Dados,V14.3,Proteção de Dados no Lado do Cliente,V14.3.3,"Verificar que os dados armazenados no armazenamento do navegador (como localStorage, sessionStorage, IndexedDB ou cookies) não contêm dados sensíveis, com exceção de tokens de sessão.",2 -V15,Codificação e Arquitetura Segura,V15.1,Documentação de Codificação e Arquitetura Segura,V15.1.1,"Verificar que a documentação da aplicação define prazos de remediação baseados em risco para versões de componentes de terceiros com vulnerabilidades e para atualização de bibliotecas em geral, a fim de minimizar o risco proveniente desses componentes.",1 -V15,Codificação e Arquitetura Segura,V15.1,Documentação de Codificação e Arquitetura Segura,V15.1.2,"Verificar que um catálogo de inventário, como uma software bill of materials (SBOM), é mantido de todas as bibliotecas de terceiros em uso, incluindo a verificação de que os componentes vêm de repositórios predefinidos, confiáveis e continuamente mantidos.",2 -V15,Codificação e Arquitetura Segura,V15.1,Documentação de Codificação e Arquitetura Segura,V15.1.3,"Verificar que a documentação da aplicação identifica funcionalidades que são demoradas ou exigem muitos recursos. Isso deve incluir como prevenir uma perda de disponibilidade devido ao uso excessivo dessa funcionalidade e como evitar uma situação em que a construção de uma resposta demore mais do que o timeout do consumidor. As defesas potenciais podem incluir processamento assíncrono, uso de filas e limitação de processos paralelos por usuário e por aplicação.",2 -V15,Codificação e Arquitetura Segura,V15.1,Documentação de Codificação e Arquitetura Segura,V15.1.4,Verificar que a documentação da aplicação destaca bibliotecas de terceiros consideradas 'componentes de risco'.,3 -V15,Codificação e Arquitetura Segura,V15.1,Documentação de Codificação e Arquitetura Segura,V15.1.5,Verificar que a documentação da aplicação destaca partes da aplicação onde 'funcionalidade perigosa' está sendo usada.,3 -V15,Codificação e Arquitetura Segura,V15.2,Arquitetura de Segurança e Dependências,V15.2.1,Verificar que a aplicação contém apenas componentes que não excederam os prazos documentados de atualização e remediação.,1 -V15,Codificação e Arquitetura Segura,V15.2,Arquitetura de Segurança e Dependências,V15.2.2,"Verificar que a aplicação implementou defesas contra perda de disponibilidade devido a funcionalidades demoradas ou que exigem muitos recursos, com base nas decisões e estratégias de segurança documentadas para isso.",2 -V15,Codificação e Arquitetura Segura,V15.2,Arquitetura de Segurança e Dependências,V15.2.3,"Verificar que o ambiente de produção inclui apenas funcionalidades necessárias para o funcionamento da aplicação, e não expõe funcionalidades desnecessárias como código de teste, trechos de exemplo e funcionalidades de desenvolvimento.",2 -V15,Codificação e Arquitetura Segura,V15.2,Arquitetura de Segurança e Dependências,V15.2.4,"Verificar que componentes de terceiros e todas as suas dependências transitivas são incluídos do repositório esperado, seja de propriedade interna ou de uma fonte externa, e que não há risco de um ataque de dependency confusion.",3 -V15,Codificação e Arquitetura Segura,V15.2,Arquitetura de Segurança e Dependências,V15.2.5,"Verificar que a aplicação implementa proteções adicionais em torno das partes da aplicação documentadas como contendo 'funcionalidade perigosa' ou que usam bibliotecas de terceiros consideradas 'componentes de risco'. Isso pode incluir técnicas como sandboxing, encapsulamento, containerização ou isolamento em nível de rede para retardar e deter atacantes que comprometam uma parte de uma aplicação de se mover lateralmente para outras partes.",3 -V15,Codificação e Arquitetura Segura,V15.3,Codificação Defensiva,V15.3.1,"Verificar que a aplicação retorna apenas o subconjunto necessário de campos de um objeto de dados. Por exemplo, não deve retornar um objeto de dados inteiro, pois alguns campos individuais não devem ser acessíveis aos usuários.",1 -V15,Codificação e Arquitetura Segura,V15.3,Codificação Defensiva,V15.3.2,"Verificar que, onde o backend da aplicação faz chamadas para URLs externas, ele está configurado para não seguir redirecionamentos a menos que seja uma funcionalidade pretendida.",2 -V15,Codificação e Arquitetura Segura,V15.3,Codificação Defensiva,V15.3.3,"Verificar que a aplicação tem contramedidas para proteger contra ataques de mass assignment, limitando os campos permitidos por controlador e ação — por exemplo, não é possível inserir ou atualizar um valor de campo quando não era pretendido que fizesse parte dessa ação.",2 -V15,Codificação e Arquitetura Segura,V15.3,Codificação Defensiva,V15.3.4,"Verificar que todos os componentes de proxy e middleware transferem corretamente o endereço IP original do usuário usando campos de dados confiáveis que não podem ser manipulados pelo usuário final, e que a aplicação e o servidor web usam esse valor correto para registro e decisões de segurança como limitação de taxa, levando em conta que mesmo o endereço IP original pode não ser confiável devido a IPs dinâmicos, VPNs ou firewalls corporativos.",2 -V15,Codificação e Arquitetura Segura,V15.3,Codificação Defensiva,V15.3.5,Verificar que a aplicação garante explicitamente que as variáveis são do tipo correto e realiza operações de igualdade e comparação estritas. Isso serve para evitar vulnerabilidades de type juggling ou type confusion causadas pelo código da aplicação assumindo um tipo de variável.,2 -V15,Codificação e Arquitetura Segura,V15.3,Codificação Defensiva,V15.3.6,"Verificar que o código JavaScript é escrito de forma a prevenir poluição de prototype, por exemplo, usando Set() ou Map() em vez de literais de objeto.",2 -V15,Codificação e Arquitetura Segura,V15.3,Codificação Defensiva,V15.3.7,"Verificar que a aplicação tem defesas contra ataques de poluição de parâmetro HTTP, especialmente se o framework da aplicação não faz distinção entre a fonte dos parâmetros de requisição (string de consulta, parâmetros do corpo, cookies ou campos de cabeçalho).",2 -V15,Codificação e Arquitetura Segura,V15.4,Concorrência Segura,V15.4.1,"Verificar que objetos compartilhados em código multithread (como caches, arquivos ou objetos na memória acessados por múltiplas threads) são acessados de forma segura usando tipos thread-safe e mecanismos de sincronização como locks ou semáforos, para evitar condições de corrida e corrupção de dados.",3 -V15,Codificação e Arquitetura Segura,V15.4,Concorrência Segura,V15.4.2,"Verificar que verificações sobre o estado de um recurso, como sua existência ou permissões, e as ações que dependem delas são realizadas como uma única operação atômica para prevenir condições de corrida de time-of-check to time-of-use (TOCTOU). Por exemplo, verificar se um arquivo existe antes de abri-lo ou verificar o acesso de um usuário antes de concedê-lo.",3 -V15,Codificação e Arquitetura Segura,V15.4,Concorrência Segura,V15.4.3,"Verificar que os locks são usados de forma consistente para evitar que threads fiquem presos, seja esperando uns pelos outros ou tentando repetidamente, e que a lógica de locking permanece no código responsável por gerenciar o recurso para garantir que os locks não possam ser inadvertida ou maliciosamente modificados por classes ou código externos.",3 -V15,Codificação e Arquitetura Segura,V15.4,Concorrência Segura,V15.4.4,"Verificar que as políticas de alocação de recursos previnem a starvation de threads garantindo acesso justo aos recursos, como usando pools de threads, permitindo que threads de menor prioridade prossigam dentro de um prazo razoável.",3 -V16,Registro de Segurança e Tratamento de Erros,V16.1,Documentação de Registro de Segurança,V16.1.1,"Verificar que existe um inventário documentando o registro realizado em cada camada da pilha de tecnologia da aplicação, quais eventos são registrados, formatos de log, onde esse registro é armazenado, como é usado, como o acesso a ele é controlado e por quanto tempo os logs são mantidos.",2 -V16,Registro de Segurança e Tratamento de Erros,V16.2,Registro Geral,V16.2.1,"Verificar que cada entrada de log inclui os metadados necessários (como quando, onde, quem, o quê) que permitiriam uma investigação detalhada da linha do tempo quando um evento ocorrer.",2 -V16,Registro de Segurança e Tratamento de Erros,V16.2,Registro Geral,V16.2.2,Verificar que as fontes de tempo para todos os componentes de registro estão sincronizadas e que os timestamps nos metadados de eventos de segurança usam UTC ou incluem um deslocamento de fuso horário explícito. UTC é recomendado para garantir consistência em sistemas distribuídos e prevenir confusão durante transições de horário de verão.,2 -V16,Registro de Segurança e Tratamento de Erros,V16.2,Registro Geral,V16.2.3,Verificar que a aplicação armazena ou transmite logs apenas para os arquivos e serviços documentados no inventário de logs.,2 -V16,Registro de Segurança e Tratamento de Erros,V16.2,Registro Geral,V16.2.4,"Verificar que os logs podem ser lidos e correlacionados pelo processador de log em uso, preferencialmente usando um formato de registro comum.",2 -V16,Registro de Segurança e Tratamento de Erros,V16.2,Registro Geral,V16.2.5,"Verificar que, ao registrar dados sensíveis, a aplicação aplica o registro com base no nível de proteção dos dados. Por exemplo, pode não ser permitido registrar certos dados, como credenciais ou detalhes de pagamento. Outros dados, como tokens de sessão, podem ser registrados apenas por meio de hash ou mascaramento, seja total ou parcialmente.",2 -V16,Registro de Segurança e Tratamento de Erros,V16.3,Eventos de Segurança,V16.3.1,"Verificar que todas as operações de autenticação são registradas, incluindo tentativas bem-sucedidas e fracassadas. Metadados adicionais, como o tipo de autenticação ou fatores usados, também devem ser coletados.",2 -V16,Registro de Segurança e Tratamento de Erros,V16.3,Eventos de Segurança,V16.3.2,"Verificar que tentativas de autorização falhas são registradas. Para L3, isso deve incluir o registro de todas as decisões de autorização, incluindo o registro de quando dados sensíveis são acessados (sem registrar os próprios dados sensíveis).",2 -V16,Registro de Segurança e Tratamento de Erros,V16.3,Eventos de Segurança,V16.3.3,"Verificar que a aplicação registra os eventos de segurança definidos na documentação e também registra tentativas de contornar os controles de segurança, como validação de entrada, lógica de negócio e anti-automação.",2 -V16,Registro de Segurança e Tratamento de Erros,V16.3,Eventos de Segurança,V16.3.4,"Verificar que a aplicação registra erros inesperados e falhas de controle de segurança, como falhas de TLS no backend.",2 -V16,Registro de Segurança e Tratamento de Erros,V16.4,Proteção de Logs,V16.4.1,Verificar que todos os componentes de registro codificam adequadamente os dados para prevenir injeção de log.,2 -V16,Registro de Segurança e Tratamento de Erros,V16.4,Proteção de Logs,V16.4.2,Verificar que os logs são protegidos contra acesso não autorizado e não podem ser modificados.,2 -V16,Registro de Segurança e Tratamento de Erros,V16.4,Proteção de Logs,V16.4.3,"Verificar que os logs são transmitidos de forma segura para um sistema logicamente separado para análise, detecção, alerta e escalação. O objetivo é garantir que, se a aplicação for comprometida, os logs não sejam comprometidos.",2 -V16,Registro de Segurança e Tratamento de Erros,V16.5,Tratamento de Erros,V16.5.1,"Verificar que uma mensagem genérica é retornada ao consumidor quando ocorre um erro inesperado ou sensível à segurança, garantindo que não haja exposição de dados internos sensíveis do sistema, como rastreamentos de pilha, consultas, chaves secretas e tokens.",2 -V16,Registro de Segurança e Tratamento de Erros,V16.5,Tratamento de Erros,V16.5.2,"Verificar que a aplicação continua a operar de forma segura quando o acesso a recursos externos falha, por exemplo, usando padrões como circuit breakers ou degradação graciosa.",2 -V16,Registro de Segurança e Tratamento de Erros,V16.5,Tratamento de Erros,V16.5.3,"Verificar que a aplicação falha de forma graciosa e segura, incluindo quando ocorre uma exceção, prevenindo condições de fail-open como processar uma transação apesar de erros resultantes da lógica de validação.",2 -V16,Registro de Segurança e Tratamento de Erros,V16.5,Tratamento de Erros,V16.5.4,"Verificar que um handler de erro 'de último recurso' é definido para capturar todas as exceções não tratadas. Isso serve tanto para evitar perder detalhes de erro que devem ir para arquivos de log quanto para garantir que um erro não derrube todo o processo da aplicação, levando a uma perda de disponibilidade.",3 -V17,WebRTC,V17.1,Servidor TURN,V17.1.1,"Verificar que o serviço de Traversal Using Relays around NAT (TURN) permite apenas acesso a endereços IP que não são reservados para fins especiais (por exemplo, redes internas, broadcast, loopback). Observar que isso se aplica tanto a endereços IPv4 quanto IPv6.",2 -V17,WebRTC,V17.1,Servidor TURN,V17.1.2,Verificar que o serviço de Traversal Using Relays around NAT (TURN) não é suscetível ao esgotamento de recursos quando usuários legítimos tentam abrir um grande número de portas no servidor TURN.,3 -V17,WebRTC,V17.2,Mídia,V17.2.1,Verificar que a chave para o certificado Datagram Transport Layer Security (DTLS) é gerenciada e protegida com base na política documentada de gerenciamento de chaves criptográficas.,2 -V17,WebRTC,V17.2,Mídia,V17.2.2,Verificar que o servidor de mídia está configurado para usar e suportar suítes de cifra DTLS (Datagram Transport Layer Security) aprovadas e um perfil de proteção seguro para a Extensão DTLS para estabelecimento de chaves para o Secure Real-time Transport Protocol (DTLS-SRTP).,2 -V17,WebRTC,V17.2,Mídia,V17.2.3,Verificar que a autenticação do Secure Real-time Transport Protocol (SRTP) é verificada no servidor de mídia para evitar que ataques de injeção de Real-time Transport Protocol (RTP) levem a uma condição de Negação de Serviço ou inserção de áudio ou vídeo nos fluxos de mídia.,2 -V17,WebRTC,V17.2,Mídia,V17.2.4,Verificar que o servidor de mídia é capaz de continuar processando tráfego de mídia recebido ao encontrar pacotes SRTP (Secure Real-time Transport Protocol) malformados.,2 -V17,WebRTC,V17.2,Mídia,V17.2.5,Verificar que o servidor de mídia é capaz de continuar processando tráfego de mídia recebido durante uma inundação de pacotes SRTP (Secure Real-time Transport Protocol) de usuários legítimos.,3 -V17,WebRTC,V17.2,Mídia,V17.2.6,"Verificar que o servidor de mídia não é suscetível à vulnerabilidade de Condição de Corrida 'ClientHello' no Datagram Transport Layer Security (DTLS), verificando se o servidor de mídia é publicamente conhecido por ser vulnerável ou realizando o teste de condição de corrida.",3 -V17,WebRTC,V17.2,Mídia,V17.2.7,Verificar que qualquer mecanismo de gravação de áudio ou vídeo associado ao servidor de mídia é capaz de continuar processando tráfego de mídia recebido durante uma inundação de pacotes SRTP (Secure Real-time Transport Protocol) de usuários legítimos.,3 -V17,WebRTC,V17.2,Mídia,V17.2.8,"Verificar que o certificado DTLS (Datagram Transport Layer Security) é verificado em relação ao atributo de fingerprint do Session Description Protocol (SDP), encerrando o fluxo de mídia se a verificação falhar, para garantir a autenticidade do fluxo de mídia.",3 -V17,WebRTC,V17.3,Sinalização,V17.3.1,Verificar que o servidor de sinalização é capaz de continuar processando mensagens de sinalização legítimas durante um ataque de inundação. Isso deve ser alcançado implementando limitação de taxa no nível de sinalização.,2 -V17,WebRTC,V17.3,Sinalização,V17.3.2,"Verificar que o servidor de sinalização é capaz de continuar processando mensagens de sinalização legítimas ao encontrar mensagens de sinalização malformadas que possam causar uma condição de negação de serviço. Isso pode incluir a implementação de validação de entrada, tratamento seguro de estouros de inteiros, prevenção de estouros de buffer e emprego de outras técnicas robustas de tratamento de erros.",2 diff --git a/5.0/pt/0x00-Header.yaml b/5.0/pt/0x00-Header.yaml index 309d2b6f5d..4eb2393fa9 100644 --- a/5.0/pt/0x00-Header.yaml +++ b/5.0/pt/0x00-Header.yaml @@ -1,7 +1,7 @@ --- - title: "Application Security Verification Standard" - subtitle: "Version 5.0.0" - date: May 2025 + title: "Padrão de Verificação de Segurança de Aplicações" + subtitle: "Versão 5.0.0" + date: Maio de 2025 titlepage: true titlepage-rule-height: 0 titlepage-logo: "images/owasp_logo_1c_notext.png" diff --git a/5.0/pt/0x01-Frontispiece.md b/5.0/pt/0x01-Frontispiece.md index b6ad6346a2..2987045e47 100644 --- a/5.0/pt/0x01-Frontispiece.md +++ b/5.0/pt/0x01-Frontispiece.md @@ -1,46 +1,47 @@ -# Frontispiece +# Frontispício -## About the Standard +## Sobre o Padrão -The Application Security Verification Standard is a list of application security requirements that architects, developers, testers, security professionals, tool vendors, and consumers can use to define, build, test, and verify secure applications. +O Padrão de Verificação de Segurança de Aplicações (Application Security Verification Standard - ASVS) é uma lista de requisitos de segurança de aplicações que arquitetos, desenvolvedores, testadores, profissionais de segurança, fornecedores de ferramentas e consumidores podem usar para definir, construir, testar e verificar aplicações seguras. -## Copyright and License +## Direitos Autorais e Licença -Version 5.0.0, May 2025 +Versão 5.0.0, Maio de 2025 ![license](../images/license.png) Copyright © 2008-2025 The OWASP Foundation. -This document is released under the [Creative Commons Attribution-ShareAlike 4.0 International License](https://creativecommons.org/licenses/by-sa/4.0/). +Este documento foi lançado sob a [Licença Internacional Creative Commons Attribution-ShareAlike 4.0](https://creativecommons.org/licenses/by-sa/4.0/). -For any reuse or distribution, you must clearly communicate the license terms of this work to others. +Para qualquer reutilização ou distribuição, você deve comunicar claramente os termos de licença desta obra a terceiros. -## Project Leads +## Líderes do Projeto | | | |---------------------- |----------------- | | Elar Lang | Josh C Grossman | | Jim Manico | Daniel Cuthbert | -## Working Group +## Grupo de Trabalho | | | | | |---------------- |------------------ |------------------- |----------------- | | Tobias Ahnoff | Ralph Andalis | Ryan Armstrong | Gabriel Corona | | Meghan Jacquot | Shanni Prutchi | Iman Sharafaldin | Eden Yardeni | -## Other Major Contributors +## Outros Principais Contribuidores | | | |-------------------|-------------------| | Sjoerd Langkemper | Isaac Lewis | | Mark Carney | Sandro Gauci | -## Other Contributors and Reviewers +## Outros Contribuidores e Revisores -We have included a list of the other contributors in Appendix E. +Incluímos uma lista dos demais contribuidores no Apêndice E. -If a credit is missing from the 5.x credit list, please log a ticket at GitHub to be recognized in future 5.x updates. +Se algum crédito estiver faltando na lista de créditos da versão 5.x, por favor, abra um ticket no GitHub para ser reconhecido em futuras atualizações 5.x. -The Application Security Verification Standard builds on the work of those involved in ASVS 1.0 (2008) through 4.0 (2019). Much of the structure and many of the verification items that remain in ASVS today were originally written by Andrew van der Stock, Mike Boberski, Jeff Williams, and Dave Wichers, among numerous other contributors. Thank you to everyone who has contributed in the past. For a comprehensive list of earlier contributors, please consult each prior version. +O Padrão de Verificação de Segurança de Aplicações baseia-se no trabalho dos envolvidos no ASVS 1.0 (2008) até a 4.0 (2019). Grande parte da estrutura e muitos dos itens de verificação que permanecem no ASVS hoje foram originalmente escritos por Andrew van der Stock, Mike Boberski, Jeff Williams e Dave Wichers, entre vários outros contribuidores. Obrigado a todos que contribuíram no passado. Para uma lista abrangente de contribuidores anteriores, por favor, consulte cada versão anterior. +Preface.md diff --git a/5.0/pt/0x02-Preface.md b/5.0/pt/0x02-Preface.md index 4c0b8d3764..6e1d93d283 100644 --- a/5.0/pt/0x02-Preface.md +++ b/5.0/pt/0x02-Preface.md @@ -1,29 +1,29 @@ -# Preface +# Prefácio -Welcome to the Application Security Verification Standard (ASVS) Version 5.0. +Bem-vindo à Versão 5.0 do Padrão de Verificação de Segurança de Aplicações (ASVS). -## Introduction +## Introdução -Originally launched in 2008 through a global community collaboration, the ASVS defines a comprehensive set of security requirements for designing, developing, and testing modern web applications and services. +Lançado originalmente em 2008 por meio de uma colaboração da comunidade global, o ASVS define um conjunto abrangente de requisitos de segurança para projetar, desenvolver e testar aplicações e serviços web modernos. -Following the release of ASVS 4.0 in 2019 and its minor update (v4.0.3) in 2021, Version 5.0 represents a significant milestone—modernized to reflect the latest advances in software security. +Após o lançamento do ASVS 4.0 em 2019 e sua pequena atualização (v4.0.3) em 2021, a Versão 5.0 representa um marco significativo — modernizada para refletir os mais recentes avanços na segurança de software. -ASVS 5.0 is the result of extensive contributions from project leaders, working group members, and the wider OWASP community to update and improve this important standard. +O ASVS 5.0 é o resultado de extensas contribuições de líderes de projetos, membros do grupo de trabalho e da comunidade OWASP em geral para atualizar e melhorar este importante padrão. -## Principles behind version 5.0 +## Princípios por trás da versão 5.0 -This major revision has been developed with several key principles in mind: +Esta grande revisão foi desenvolvida com vários princípios-chave em mente: -* Refined Scope and Focus: This version of the standard has been designed to align more directly with the foundational pillars in its name: Application, Security, Verification, and Standard. Requirements have been rewritten to emphasize the prevention of security flaws rather than mandating specific technical implementations. Requirement texts are intended to be self-explanatory, explaining why they exist. +* Escopo e Foco Refinados: Esta versão do padrão foi projetada para se alinhar mais diretamente com os pilares fundamentais em seu nome: Aplicação (Application), Segurança (Security), Verificação (Verification) e Padrão (Standard). Os requisitos foram reescritos para enfatizar a prevenção de falhas de segurança, em vez de exigir implementações técnicas específicas. Os textos dos requisitos pretendem ser autoexplicativos, justificando o motivo de sua existência. -* Support for Documented Security Decisions: ASVS 5.0 introduces requirements for documenting key security decisions. This enhances traceability and supports context-sensitive implementations, allowing organizations to tailor their security posture to their specific needs and risks. +* Suporte para Decisões de Segurança Documentadas: O ASVS 5.0 introduz requisitos para documentar as principais decisões de segurança. Isso melhora a rastreabilidade e oferece suporte a implementações sensíveis ao contexto, permitindo que as organizações adaptem sua postura de segurança às suas necessidades e riscos específicos. -* Updated Levels: While ASVS retains its three-tier model, the level definitions have evolved to make the ASVS easier to adopt. Level 1 is designed as the initial step to adopting the ASVS, providing the first layer of defense. Level 2 represents a comprehensive view of standard security practices, and Level 3 addresses advanced, high-assurance requirements. +* Níveis Atualizados: Embora o ASVS mantenha seu modelo de três camadas, as definições de nível evoluíram para tornar o ASVS mais fácil de adotar. O Nível 1 é projetado como o passo inicial para a adoção do ASVS, fornecendo a primeira camada de defesa. O Nível 2 representa uma visão abrangente das práticas padrão de segurança, e o Nível 3 aborda requisitos avançados e de alta garantia. -* Restructured and Expanded Content: ASVS 5.0 includes approximately 350 requirements across 17 chapters. Chapters have been reorganized for clarity and usability. A two-way mapping between v4.0 and v5.0 is provided to facilitate migration. +* Conteúdo Reestruturado e Expandido: O ASVS 5.0 inclui aproximadamente 350 requisitos distribuídos em 17 capítulos. Os capítulos foram reorganizados para maior clareza e usabilidade. Um mapeamento bidirecional entre as versões 4.0 e 5.0 é fornecido para facilitar a migração. -## Looking ahead +## Olhando para o futuro -Just as securing an application is never truly finished, neither is the ASVS. Although Version 5.0 is a major release, development continues. This release allows the wider community to benefit from the improvements and additions which have been accumulated but also lays the groundwork for future enhancements. This could include community-driven efforts to create implementation and verification guidance built on top of the core requirement set. +Assim como a segurança de uma aplicação nunca está verdadeiramente terminada, o ASVS também não está. Embora a Versão 5.0 seja um lançamento importante, o desenvolvimento continua. Este lançamento permite que a comunidade em geral se beneficie das melhorias e adições que foram acumuladas, mas também estabelece as bases para aprimoramentos futuros. Isso pode incluir esforços impulsionados pela comunidade para criar guias de implementação e verificação construídos sobre o conjunto central de requisitos. -ASVS 5.0 is designed to serve as a reliable foundation for secure software development. The community is invited to adopt, contribute, and build upon this standard to collectively advance the state of application security. +O ASVS 5.0 foi projetado para servir como uma base confiável para o desenvolvimento seguro de software. A comunidade está convidada a adotar, contribuir e construir sobre este padrão para avançar coletivamente o estado da segurança de aplicações. \ No newline at end of file diff --git a/5.0/pt/0x03-What-is-the-ASVS.md b/5.0/pt/0x03-What-is-the-ASVS.md index 925ecb33b6..386c6cdb71 100644 --- a/5.0/pt/0x03-What-is-the-ASVS.md +++ b/5.0/pt/0x03-What-is-the-ASVS.md @@ -1,195 +1,196 @@ -# What is the ASVS? +# O que é o ASVS? -The Application Security Verification Standard (ASVS) defines security requirements for web applications and services, and it is a valuable resource for anyone aiming to design, develop, and maintain secure applications or evaluate their security. +O Padrão de Verificação de Segurança de Aplicações (Application Security Verification Standard - ASVS) define requisitos de segurança para aplicações e serviços web, e é um recurso valioso para qualquer pessoa que tenha como objetivo projetar, desenvolver e manter aplicações seguras ou avaliar sua segurança. -This chapter outlines the essential aspects of using the ASVS, including its scope, the structure of its priority-based levels, and the primary use cases for the standard. +Este capítulo descreve os aspectos essenciais do uso do ASVS, incluindo seu escopo, a estrutura de seus níveis baseados em prioridade e os principais casos de uso para o padrão. -## Scope of the ASVS +## Escopo do ASVS -The scope of the ASVS is defined by its name: Application, Security, Verification, and Standard. It establishes which requirements are included or excluded, with the overarching goal of identifying the security principles that must be achieved. The scope also considers documentation requirements, which serve as the foundation for implementation requirements. +O escopo do ASVS é definido pelo seu nome: Aplicação (Application), Segurança (Security), Verificação (Verification) e Padrão (Standard). Ele estabelece quais requisitos são incluídos ou excluídos, com o objetivo geral de identificar os princípios de segurança que devem ser alcançados. O escopo também considera os requisitos de documentação, que servem como base para os requisitos de implementação. -There is no such thing as scope for attackers. Therefore, ASVS requirements should be evaluated alongside guidance for other aspects of the application lifecycle, including CI/CD processes, hosting, and operational activities. +Não existe o conceito de escopo para atacantes. Portanto, os requisitos do ASVS devem ser avaliados em conjunto com as diretrizes para outros aspectos do ciclo de vida da aplicação, incluindo processos de CI/CD, hospedagem e atividades operacionais. -### Application +### Aplicação -ASVS defines an "application" as the software product being developed, into which security controls must be integrated. ASVS does not prescribe development lifecycle activities or dictate how the application should be built via a CI/CD pipeline; instead, it specifies the security outcomes that must be achieved within the product itself. +O ASVS define uma "aplicação" como o produto de software em desenvolvimento, no qual controles de segurança devem ser integrados. O ASVS não prescreve atividades do ciclo de vida de desenvolvimento ou dita como a aplicação deve ser construída através de um pipeline de CI/CD; em vez disso, ele especifica os resultados de segurança que devem ser alcançados dentro do próprio produto. -Components that serve, modify, or validate HTTP traffic, such as Web Application Firewalls (WAFs), load balancers, or proxies, may be considered part of the application for those specific purposes, as some security controls depend directly on them or can be implemented through them. These components should be considered for requirements related to cached responses, rate limiting, or restricting incoming and outgoing connections based on source and destination. +Componentes que servem, modificam ou validam tráfego HTTP, como Web Application Firewalls (WAFs), balanceadores de carga ou proxies, podem ser considerados parte da aplicação para esses propósitos específicos, pois alguns controles de segurança dependem diretamente deles ou podem ser implementados através deles. Estes componentes devem ser considerados para requisitos relacionados a respostas em cache, limitação de taxa (rate limiting) ou restrição de conexões de entrada e saída com base na origem e no destino. -Conversely, ASVS generally excludes requirements that are not directly relevant to the application or where configuration is outside the application's responsibility. For example, DNS issues are typically managed by a separate team or function. +Por outro lado, o ASVS geralmente exclui requisitos que não são diretamente relevantes para a aplicação ou onde a configuração está fora da responsabilidade da aplicação. Por exemplo, problemas de DNS são tipicamente gerenciados por uma equipe ou função separada. -Similarly, while the application is responsible for how it consumes input and produces output, if an external process interacts with the application or its data, it is considered out of scope for ASVS. For instance, backing up the application or its data is usually the responsibility of an external process and is not controlled by the application or its developers. +Da mesma forma, embora a aplicação seja responsável por como ela consome entradas e produz saídas, se um processo externo interage com a aplicação ou seus dados, ele é considerado fora do escopo do ASVS. Por exemplo, o backup da aplicação ou de seus dados geralmente é responsabilidade de um processo externo e não é controlado pela aplicação ou por seus desenvolvedores. -### Security +### Segurança -Every requirement must have a demonstrable impact on security. The absence of a requirement must result in a less secure application, and implementing the requirement must reduce either the likelihood or the impact of a security risk. +Todo requisito deve ter um impacto demonstrável na segurança. A ausência de um requisito deve resultar em uma aplicação menos segura, e a implementação do requisito deve reduzir a probabilidade ou o impacto de um risco de segurança. -All other considerations, such as functional aspects, code style, or policy requirements, are out of scope. +Todas as outras considerações, como aspectos funcionais, estilo de código ou requisitos de política, estão fora do escopo. -### Verification +### Verificação -The requirement must be verifiable, and the verification must result in a "fail" or "pass" decision. +O requisito deve ser verificável, e a verificação deve resultar em uma decisão de "falha" (fail) ou "aprovação" (pass). -### Standard +### Padrão -The ASVS is designed to be a collection of security requirements to be implemented to comply with the standard. This means that requirements are limited to defining the security goal to achieve that. Other related information can be built on top of ASVS or linked via mappings. +O ASVS foi projetado para ser uma coleção de requisitos de segurança a serem implementados para estar em conformidade com o padrão. Isso significa que os requisitos se limitam a definir a meta de segurança para alcançar isso. Outras informações relacionadas podem ser construídas sobre o ASVS ou vinculadas por meio de mapeamentos. -Specifically, OWASP has many projects, and the ASVS deliberately avoids overlapping with the content in other projects. For example, developers may have a question, "how do I implement a particular requirement in my particular technology or environment," and this should be covered by the Cheat Sheet Series project. Verifiers may have a question "how do I test this requirement in this environment," and this should be covered by the Web Security Testing Guide project. +Especificamente, a OWASP tem muitos projetos, e o ASVS evita deliberadamente a sobreposição com o conteúdo de outros projetos. Por exemplo, desenvolvedores podem ter a dúvida: "como implemento um requisito específico na minha tecnologia ou ambiente particular?", e isso deve ser coberto pelo projeto Cheat Sheet Series. Verificadores podem ter a dúvida: "como testo este requisito neste ambiente?", e isso deve ser coberto pelo projeto Web Security Testing Guide (WSTG). -Whilst the ASVS is not just intended for security experts to use, it does expect the reader to have technical knowledge to understand the content or the ability to research particular concepts. +Embora o ASVS não seja destinado apenas ao uso por especialistas em segurança, espera-se que o leitor tenha conhecimento técnico para entender o conteúdo ou a capacidade de pesquisar conceitos específicos. -### Requirement +### Requisito -The word requirement is used specifically in the ASVS as it describes what must be achieved to satisfy it. The ASVS only contains requirements (must) and does not contain recommendations (should) as the main condition. +A palavra requisito é usada especificamente no ASVS pois descreve o que deve ser alcançado para satisfazê-lo. O ASVS contém apenas requisitos (deve / must) e não contém recomendações (deveria / should) como condição principal. -In other words, recommendations, whether they are just one of many possible options to solve a problem or code style considerations, do not satisfy the definition to be a requirement. +Em outras palavras, recomendações, sejam elas apenas uma das muitas opções possíveis para resolver um problema ou considerações de estilo de código, não satisfazem a definição para serem um requisito. -ASVS requirements are intended to address specific security principles without being too implementation or technology-specific, at the same time, being self-explanatory as to why they exist. This also means that requirements are not built around a particular verification method or implementation. +Os requisitos do ASVS pretendem abordar princípios específicos de segurança sem serem muito específicos a implementações ou tecnologias, e ao mesmo tempo, sendo autoexplicativos quanto ao motivo de existirem. Isso também significa que os requisitos não são construídos em torno de um método de verificação ou implementação particular. -### Documented security decisions +### Decisões de segurança documentadas -In software security, planning security design and the mechanisms to be used early on will lead to a more consistent and reliable implementation in the finished product or feature. +Na segurança de software, planejar o design de segurança e os mecanismos a serem usados logo no início levará a uma implementação mais consistente e confiável no produto ou funcionalidade final. -Additionally, for certain requirements, implementation will be complicated and very specific to an application's needs. Common examples include permissions, input validation, and protective controls around different levels of sensitive data. +Além disso, para certos requisitos, a implementação será complicada e muito específica às necessidades de uma aplicação. Exemplos comuns incluem permissões, validação de entrada e controles de proteção em torno de diferentes níveis de dados sensíveis. -To account for this, rather than sweeping statements like "all data must be encrypted" or trying to cover every possible use case in a requirement, documentation requirements were included which mandate that the application developer's approach and configuration to these sorts of controls must be documented. This can then be reviewed for appropriateness and then the actual implementation can be compared to the documentation to assess whether the implementation matches expectations. +Para levar isso em conta, em vez de afirmações generalistas como "todos os dados devem ser criptografados" ou tentar cobrir todos os casos de uso possíveis em um requisito, foram incluídos requisitos de documentação que exigem que a abordagem e a configuração do desenvolvedor da aplicação para esses tipos de controles sejam documentadas. Isso pode então ser revisado quanto à adequação, e a implementação real pode ser comparada à documentação para avaliar se a implementação corresponde às expectativas. -These requirements are intended to document the decisions which the organization developing the application has taken regarding how to implement certain security requirements. +Estes requisitos têm o objetivo de documentar as decisões que a organização que desenvolve a aplicação tomou em relação a como implementar determinados requisitos de segurança. -Documentation requirements are always in the first section of a chapter (although not every chapter has them) and always have a related implementation requirement where the decisions that are documented should actually be put into place. The point here is that verifying that the documentation is in place and that the actual implementation are two separate activities. +Os requisitos de documentação estão sempre na primeira seção de um capítulo (embora nem todo capítulo os tenha) e sempre têm um requisito de implementação relacionado onde as decisões documentadas devem realmente ser colocadas em prática. O ponto aqui é que verificar se a documentação está em vigor e se a implementação real ocorreu são duas atividades separadas. -There are two key drivers for including these requirements. The first driver is that a security requirement will often involve enforcing rules e.g., what kind of file types are allowed to be uploaded, what business controls should be enforced, what are the allowed characters for a particular field. These rules will differ for every application, and therefore, the ASVS cannot prescriptively define what they should be, nor will a cheat sheet or more detailed response help in this case. Similarly, without these decisions being documented, it will not be possible to perform verification of the requirements that implement these decisions. +Existem dois motivadores principais para incluir esses requisitos. O primeiro motivador é que um requisito de segurança muitas vezes envolverá a aplicação de regras, por exemplo, que tipo de arquivos são permitidos para upload, quais controles de negócios devem ser aplicados, quais são os caracteres permitidos para um campo específico. Essas regras serão diferentes para cada aplicação e, portanto, o ASVS não pode definir prescritivamente quais devem ser, nem um cheat sheet ou uma resposta mais detalhada ajudará neste caso. Da mesma forma, sem que essas decisões sejam documentadas, não será possível realizar a verificação dos requisitos que implementam essas decisões. -The second driver is that for certain requirements, it is important to provide an application development with flexibility regarding how to address particular security challenges. For example, in previous ASVS versions, session timeout rules were very prescriptive. Practically speaking, many applications, especially those that are consumer-facing, have much more relaxed rules and prefer to implement other mitigation controls instead. Documentation requirements, therefore, explicitly allow for flexibility around this. +O segundo motivador é que, para certos requisitos, é importante fornecer ao desenvolvimento da aplicação flexibilidade sobre como abordar desafios de segurança particulares. Por exemplo, em versões anteriores do ASVS, as regras de timeout de sessão eram muito prescritivas. Na prática, muitas aplicações, especialmente aquelas voltadas para o consumidor, têm regras muito mais flexíveis e preferem implementar outros controles de mitigação em seu lugar. Os requisitos de documentação, portanto, permitem explicitamente flexibilidade em torno disso. -Clearly, it is not expected that individual developers will be making and documenting these decisions but rather the organization as a whole will be taking those decisions and making sure that they are communicated to developers who then make sure to follow them. +Claramente, não se espera que desenvolvedores individuais tomem e documentem essas decisões, mas sim que a organização como um todo tome essas decisões e garanta que sejam comunicadas aos desenvolvedores, que então se certificam de segui-las. -Providing developers with specifications and designs for new features and functionality is a standard part of software development. Similarly, developers are expected to use common components and user interface mechanisms rather than just making their own decisions each time. As such, extending this to security should not be seen as surprising or controversial. +Fornecer aos desenvolvedores especificações e designs para novos recursos e funcionalidades é uma parte padrão do desenvolvimento de software. Da mesma forma, espera-se que os desenvolvedores usem componentes comuns e mecanismos de interface de usuário em vez de apenas tomar suas próprias decisões a cada vez. Sendo assim, estender isso para a segurança não deve ser visto como algo surpreendente ou controverso. -There is also flexibility around how to achieve this. Security decisions might be documented in a literal document, which developers are expected to refer to. Alternatively, security decisions could be documented and implemented in a common code library that all developers are mandated to use. In both cases, the desired result is achieved. +Também há flexibilidade sobre como alcançar isso. Decisões de segurança podem ser documentadas em um documento literal, ao qual se espera que os desenvolvedores consultem. Alternativamente, as decisões de segurança podem ser documentadas e implementadas em uma biblioteca de código comum que todos os desenvolvedores são obrigados a usar. Em ambos os casos, o resultado desejado é alcançado. -## Application Security Verification Levels +## Níveis de Verificação de Segurança de Aplicações -The ASVS defines three security verification levels, with each level increasing in depth and complexity. The general aim is for organizations to start with the first level to address the most critical security concerns, and then move up to the higher levels according to the organization and application needs. Levels may be presented as L1, L2, and L3 in the document and in requirement texts. +O ASVS define três níveis de verificação de segurança, com cada nível aumentando em profundidade e complexidade. O objetivo geral é que as organizações comecem pelo primeiro nível para lidar com as preocupações de segurança mais críticas e, em seguida, avancem para os níveis mais altos de acordo com as necessidades da organização e da aplicação. Os níveis podem ser apresentados como L1, L2 e L3 no documento e nos textos dos requisitos. -Each ASVS level indicates the security requirements that are required to achieve from that level, with the higher remaining level requirements as recommendations. +Cada nível do ASVS indica os requisitos de segurança que são obrigatórios para atingir aquele nível, com os requisitos restantes dos níveis superiores servindo como recomendações. -In order to avoid duplicate requirements or requirements that are no longer relevant at higher levels, some requirements apply to a particular level but have more stringent conditions for higher levels. +A fim de evitar requisitos duplicados ou requisitos que não são mais relevantes em níveis mais altos, alguns requisitos se aplicam a um nível específico, mas têm condições mais rigorosas para níveis superiores. -### Level evaluation +### Avaliação de Nível -Levels are defined by priority-based evaluation of each requirement based on experience implementing and testing security requirements. The main focus is on comparing risk reduction with the effort to implement the requirement. Another key factor is to keep a low barrier to entry. +Os níveis são definidos por uma avaliação baseada em prioridade de cada requisito, fundamentada na experiência de implementação e teste de requisitos de segurança. O foco principal é comparar a redução de risco com o esforço para implementar o requisito. Outro fator-chave é manter uma barreira de entrada baixa. -Risk reduction considers the extent to which the requirement reduces the level of security risk within the application, taking into account the classic Confidentiality, Integrity, and Availability impact factors as well as considering whether this is a primary layer of defense or whether it would be considered defense in depth. +A redução de risco considera até que ponto o requisito reduz o nível de risco de segurança dentro da aplicação, levando em conta os clássicos fatores de impacto de Confidencialidade, Integridade e Disponibilidade (CIA), bem como considerando se esta é uma camada primária de defesa ou se seria considerada defesa em profundidade (defense in depth). -The rigorous discussions around both the criteria and the leveling decisions have resulted in an allocation which should hold true for the vast majority of cases, whilst accepting that it may not be a 100% fit for every situation. This means that in certain cases, organizations may wish to prioritize requirements from a higher level earlier on based on their own specific risk considerations. +As discussões rigorosas em torno dos critérios e das decisões de nivelamento resultaram em uma alocação que deve ser verdadeira para a grande maioria dos casos, embora se aceite que pode não ser 100% adequada para todas as situações. Isso significa que, em certos casos, as organizações podem desejar priorizar requisitos de um nível mais alto mais cedo, com base em suas próprias considerações de risco específicas. -The types of requirements in each level could be characterized as follows. +Os tipos de requisitos em cada nível podem ser caracterizados da seguinte forma. -### Level 1 +### Nível 1 -This level contains the minimum requirements to consider when securing an application and represents a critical starting point. This level contains around 20% of the ASVS requirements. The goal for this level is to have as few requirements as possible, to decrease the barrier to entry. +Este nível contém os requisitos mínimos a serem considerados ao proteger uma aplicação e representa um ponto de partida crítico. Este nível contém cerca de 20% dos requisitos do ASVS. O objetivo para este nível é ter o menor número possível de requisitos, para diminuir a barreira de entrada. -These requirements are generally critical or basic, first-layer of defense requirements for preventing common attacks that do not require other vulnerabilities or preconditions to be exploitable. +Esses requisitos geralmente são críticos ou básicos, requisitos de primeira camada de defesa para prevenir ataques comuns que não requerem outras vulnerabilidades ou pré-condições para serem exploráveis. -In addition to the first layer of defense requirements, some requirements have less of an impact at higher levels, such as requirements related to passwords. Those are more important for Level 1, as from higher levels, the multi-factor authentication requirements become relevant. +Além dos requisitos de primeira camada de defesa, alguns requisitos têm um impacto menor em níveis mais altos, como os requisitos relacionados a senhas. Eles são mais importantes para o Nível 1, pois a partir de níveis mais altos, os requisitos de autenticação multifator (MFA) tornam-se relevantes. -Level 1 is not necessarily penetration testable by an external tester without internal access to documentation or code (such as "black box" testing), although the lower number of requirements should make it easier to verify. +O Nível 1 não é necessariamente testável por intrusão (penetration test) por um testador externo sem acesso interno a documentação ou código (como em testes do tipo "caixa preta" ou "black box"), embora o menor número de requisitos deva torná-lo mais fácil de verificar. -### Level 2 +### Nível 2 -Most applications should be striving to achieve this level of security. Around 50% of the requirements in the ASVS are L2 meaning that an application needs to implement around 70% of the requirements in the ASVS (all of the L1 and L2 requirements) in order to comply with L2. +A maioria das aplicações deveria se esforçar para atingir este nível de segurança. Cerca de 50% dos requisitos no ASVS são L2, o que significa que uma aplicação precisa implementar cerca de 70% dos requisitos no ASVS (todos os requisitos L1 e L2) a fim de estar em conformidade com o L2. -These requirements generally relate to either less common attacks or more complicated protections against common attacks. They may still be a first layer of defense, or they may require certain preconditions for the attack to be successful. +Esses requisitos geralmente se relacionam com ataques menos comuns ou proteções mais complicadas contra ataques comuns. Eles ainda podem ser uma primeira camada de defesa ou podem exigir certas pré-condições para que o ataque seja bem-sucedido. -### Level 3 +### Nível 3 -This level should be the goal for applications looking to demonstrate the highest levels of security and provides the final ~30% of requirements to comply with. +Este nível deve ser a meta para aplicações que buscam demonstrar os mais altos níveis de segurança e fornece os cerca de 30% finais dos requisitos a serem cumpridos. -Requirements in this section are generally either defense-in-depth mechanisms or other useful but hard-to-implement controls. +Os requisitos nesta seção geralmente são mecanismos de defesa em profundidade ou outros controles úteis, mas difíceis de implementar. -### Which level to achieve +### Qual nível alcançar -The priority-based levels are intended to provide a reflection of the application security maturity of the organization and the application. Rather than the ASVS prescriptively stating what level an application should be at, an organization should analyze its risks and decide what level it believes it should be at, depending on the sensitivity of the application and of course, the expectations of the application's users. +Os níveis baseados em prioridade destinam-se a fornecer um reflexo da maturidade de segurança de aplicações da organização e da aplicação. Em vez de o ASVS afirmar de forma prescritiva em qual nível uma aplicação deve estar, uma organização deve analisar seus riscos e decidir em qual nível acredita que deve estar, dependendo da sensibilidade da aplicação e, claro, das expectativas dos usuários da aplicação. -For example, an early-stage startup that is only collecting limited sensitive data may decide to focus on Level 1 for its initial security goals, but a bank may have difficulty justifying anything less than Level 3 to its customers for its online banking application. +Por exemplo, uma startup em estágio inicial que coleta apenas dados sensíveis limitados pode decidir se concentrar no Nível 1 para seus objetivos de segurança iniciais, mas um banco pode ter dificuldade em justificar qualquer coisa inferior ao Nível 3 aos seus clientes para sua aplicação de internet banking. -## How to use the ASVS +## Como usar o ASVS -### The structure of the ASVS +### A estrutura do ASVS -The ASVS is made up of a total of around 350 requirements which are divided into 17 chapters, each of which is further divided into sections. +O ASVS é composto por um total de cerca de 350 requisitos, que são divididos em 17 capítulos, cada um dos quais é subdividido em seções. -The aim of the chapter and section division is to simplify choosing or filtering out chapters and sections based on the what is relevant for the application. For example, for a machine-to-machine API, the requirements in chapter V3 related to web frontends will not be relevant. If there is no use of OAuth or WebRTC, then those chapters can be ignored as well. +O objetivo da divisão de capítulos e seções é simplificar a escolha ou filtragem de capítulos e seções com base no que é relevante para a aplicação. Por exemplo, para uma API máquina a máquina (machine-to-machine), os requisitos do capítulo V3 relacionados a frontends web não serão relevantes. Se não houver uso de OAuth ou WebRTC, esses capítulos também podem ser ignorados. -### Release strategy +### Estratégia de Lançamento -ASVS releases follow the pattern "Major.Minor.Patch" and the numbers provide information on what has changed within the release. In a major release, the first number will change, in a minor release, the second number will change, and in a patch release, the third number will change. +Os lançamentos do ASVS seguem o padrão "Major.Minor.Patch" (Maior.Menor.Correção) e os números fornecem informações sobre o que mudou na versão. Em uma versão principal (major), o primeiro número mudará; em uma versão menor (minor), o segundo número mudará; e em uma versão de correção (patch), o terceiro número mudará. -* Major release - Full reorganization, almost everything may have changed, including requirement numbers. Reevaluation for compliance will be necessary (for example, 4.0.3 -> 5.0.0). -* Minor release - Requirements may be added or removed, but overall numbering will stay the same. Reevaluation for compliance will be necessary, but should be easier (for example, 5.0.0 -> 5.1.0). -* Patch release - Requirements may be removed (for example, if they are duplicates or outdated) or made less stringent, but an application that complied with the previous release will comply with the patch release as well (for example, 5.0.0 -> 5.0.1). +* Major release (Lançamento Maior) - Reorganização completa, quase tudo pode ter mudado, incluindo os números dos requisitos. A reavaliação de conformidade será necessária (por exemplo, 4.0.3 -> 5.0.0). +* Minor release (Lançamento Menor) - Requisitos podem ser adicionados ou removidos, mas a numeração geral permanecerá a mesma. A reavaliação de conformidade será necessária, mas deve ser mais fácil (por exemplo, 5.0.0 -> 5.1.0). +* Patch release (Lançamento de Correção) - Requisitos podem ser removidos (por exemplo, se forem duplicados ou desatualizados) ou tornados menos rigorosos, mas uma aplicação que estava em conformidade com o lançamento anterior também estará em conformidade com a versão de correção (por exemplo, 5.0.0 -> 5.0.1). -The above specifically relates to the requirements in the ASVS. Changes to surrounding text and other content such as the appendices will not be considered to be a breaking change. +O acima relaciona-se especificamente aos requisitos do ASVS. Mudanças no texto ao redor e em outros conteúdos, como os apêndices, não serão consideradas uma mudança com quebra de compatibilidade (breaking change). -### Flexibility with the ASVS +### Flexibilidade com o ASVS -Several of the points described above, such as documentation requirements and the levels mechanism, provide the ability to use the ASVS in a more flexible and organization-specific way. +Vários dos pontos descritos acima, como requisitos de documentação e o mecanismo de níveis, fornecem a capacidade de usar o ASVS de forma mais flexível e específica da organização. -Additionally, organizations are strongly encouraged to create an organization- or domain-specific fork that adjusts requirements based on the specific characteristics and risk levels of their applications. However, it is important to maintain traceability so that passing requirement 4.1.1 means the same across all versions. +Além disso, as organizações são fortemente encorajadas a criar um fork (ramificação) específico da organização ou do domínio que ajuste os requisitos com base nas características e níveis de risco específicos de suas aplicações. No entanto, é importante manter a rastreabilidade para que ser aprovado no requisito 4.1.1 signifique o mesmo em todas as versões. -Ideally, each organization should create its own tailored ASVS, omitting irrelevant sections (e.g., GraphQL, WebSockets, SOAP, if unused). An organization-specific ASVS version or supplement is also a good place to provide organization-specific implementation guidance, detailing libraries or resources to use when complying with requirements. +O ideal é que cada organização crie seu próprio ASVS personalizado, omitindo seções irrelevantes (por exemplo, GraphQL, WebSockets, SOAP, se não forem usados). Uma versão ou suplemento do ASVS específico da organização também é um bom lugar para fornecer orientações de implementação específicas da organização, detalhando bibliotecas ou recursos a serem usados ao cumprir os requisitos. -### How to Reference ASVS Requirements +### Como Referenciar os Requisitos do ASVS -Each requirement has an identifier in the format `.
.`, where each element is a number. For example, `1.11.3`. +Cada requisito tem um identificador no formato `..`, onde cada elemento é um número. Por exemplo, `1.11.3`. -* The `` value corresponds to the chapter from which the requirement comes; for example, all `1.#.#` requirements are from the 'Encoding and Sanitization' chapter. -* The `
` value corresponds to the section within that chapter where the requirement appears, for example: all `1.2.#` requirements are in the 'Injection Prevention' section of the 'Encoding and Sanitization' chapter. -* The `` value identifies the specific requirement within the chapter and section, for example, `1.2.5` which as of version 5.0.0 of this standard is: +* O valor `` corresponde ao capítulo do qual o requisito se origina; por exemplo, todos os requisitos `1.#.#` são do capítulo 'Codificação e Sanitização' (Encoding and Sanitization). +* O valor `` corresponde à seção dentro daquele capítulo onde o requisito aparece, por exemplo: todos os requisitos `1.2.#` estão na seção 'Prevenção de Injeção' (Injection Prevention) do capítulo 'Codificação e Sanitização'. +* O valor `` identifica o requisito específico dentro do capítulo e seção, por exemplo, `1.2.5` que a partir da versão 5.0.0 deste padrão é: > Verify that the application protects against OS command injection and that operating system calls use parameterized OS queries or use contextual command line output encoding. +*(Verifique se a aplicação protege contra injeção de comando no sistema operacional (OS) e se as chamadas de sistema operacional usam consultas de OS parametrizadas ou usam codificação de saída de linha de comando contextual).* -Since the identifiers may change between versions of the standard, it is preferable for other documents, reports, or tools to use the following format: `v-.
.`, where: 'version' is the ASVS version tag. For example: `v5.0.0-1.2.5` would be understood to mean specifically the 5th requirement in the 'Injection Prevention' section of the 'Encoding and Sanitization' chapter from version 5.0.0. (This could be summarized as `v-`.) +Como os identificadores podem mudar entre versões do padrão, é preferível que outros documentos, relatórios ou ferramentas usem o seguinte formato: `v-..`, onde: 'versão' é a tag da versão do ASVS. Por exemplo: `v5.0.0-1.2.5` seria entendido como especificamente o 5º requisito na seção 'Prevenção de Injeção' do capítulo 'Codificação e Sanitização' da versão 5.0.0. (Isso poderia ser resumido como `v-`.) -Note: The `v` preceding the version number in the format should always be lowercase. +Nota: A letra `v` que precede o número da versão no formato deve sempre ser minúscula. -If identifiers are used without including the `v` element then they should be assumed to refer to the latest Application Security Verification Standard content. As the standard grows and changes this becomes problematic, which is why writers or developers should include the version element. +Se os identificadores forem usados sem incluir o elemento `v`, deve-se presumir que eles se referem ao conteúdo mais recente do Application Security Verification Standard. À medida que o padrão cresce e muda, isso se torna problemático, e é por isso que escritores ou desenvolvedores devem incluir o elemento de versão. -ASVS requirement lists are made available in CSV, JSON, and other formats which may be useful for reference or programmatic use. +As listas de requisitos do ASVS são disponibilizadas em formatos CSV, JSON e outros que podem ser úteis para referência ou uso programático. -### Forking the ASVS +### Fazendo Fork do ASVS -Organizations can benefit from adopting ASVS by choosing one of the three levels or by creating a domain-specific fork that adjusts requirements per application risk level. This type of fork is encouraged, provided that it maintains traceability so that passing requirement 4.1.1 means the same across all versions. +As organizações podem se beneficiar da adoção do ASVS escolhendo um dos três níveis ou criando um fork específico do domínio que ajusta os requisitos de acordo com o nível de risco da aplicação. Esse tipo de fork é encorajado, desde que mantenha a rastreabilidade para que a aprovação no requisito 4.1.1 signifique o mesmo em todas as versões. -Ideally, each organization should create its own tailored ASVS, omitting irrelevant sections (e.g., GraphQL, Websockets, SOAP, if unused). Forking should start with ASVS Level 1 as a baseline, advancing to Levels 2 or 3 based on the application’s risk. +Idealmente, cada organização deve criar seu próprio ASVS adaptado, omitindo seções irrelevantes (por exemplo, GraphQL, WebSockets, SOAP, se não forem usados). O forking deve começar com o Nível 1 do ASVS como base, avançando para os Níveis 2 ou 3 com base no risco da aplicação. -## Use cases for the ASVS +## Casos de uso para o ASVS -The ASVS can be used to assess the security of an application and this is explored in more depth in the next chapter. However, several other potential uses for the ASVS (or a forked version) have been identified. +O ASVS pode ser usado para avaliar a segurança de uma aplicação, e isso é explorado mais a fundo no próximo capítulo. No entanto, vários outros usos potenciais para o ASVS (ou uma versão em fork) foram identificados. -### As Detailed Security Architecture Guidance +### Como Guia Detalhado de Arquitetura de Segurança -One of the more common uses for the Application Security Verification Standard is as a resource for security architects. There are limited resources available for how to build a secure application archiecture, especially with modern applications. ASVS can be used to fill in those gaps by allowing security architects to choose better controls for common problems, such as data protection patterns and input validation strategies. The architecture and documentation requirements will be particularly useful for this. +Um dos usos mais comuns do Application Security Verification Standard é como um recurso para arquitetos de segurança. Existem recursos limitados disponíveis sobre como construir uma arquitetura de aplicação segura, especialmente para aplicações modernas. O ASVS pode ser usado para preencher essas lacunas, permitindo que os arquitetos de segurança escolham melhores controles para problemas comuns, como padrões de proteção de dados e estratégias de validação de entrada. Os requisitos de arquitetura e documentação serão particularmente úteis para isso. -### As a Specialized Secure Coding Reference +### Como Referência Especializada de Codificação Segura -The ASVS can be used as a basis for preparing a secure coding reference during application development, helping developers to make sure that they keep security in mind when they build software. Whilst the ASVS can be the base, prganizations should prepare their own specific guidance which is clear and unified and ideally be prepared based on guidance from security engineers or security architects. As an extension to this, organizations are encouraged wherever possible to prepare approved security mechanisms and libraries that can be referenced in the guidance and used by developers. +O ASVS pode ser usado como base para preparar uma referência de codificação segura durante o desenvolvimento de aplicações, ajudando os desenvolvedores a garantirem que mantenham a segurança em mente ao construir software. Embora o ASVS possa ser a base, as organizações devem preparar suas próprias diretrizes específicas, que sejam claras e unificadas, e idealmente preparadas com base na orientação de engenheiros de segurança ou arquitetos de segurança. Como extensão a isso, as organizações são encorajadas, sempre que possível, a preparar mecanismos de segurança e bibliotecas aprovadas que possam ser referenciadas nas diretrizes e usadas pelos desenvolvedores. -### As a Guide for Automated Unit and Integration Tests +### Como Guia para Testes Automatizados de Unidade e Integração -The ASVS is designed to be highly testable. Some verifications will be technical where as other requirements (such as the architectural and documentation requirements) may require documentation or architecture review. By building unit and integration tests that test and fuzz for specific and relevant abuse cases related to the requirements that are verifiable by technical means, it should be easier to check that these controls are operating correctly on each build. For example, additional tests can be crafted for the test suite for a login controller, testing the username parameter for common default usernames, account enumeration, brute forcing, LDAP and SQL injection, and XSS. Similarly, a test on the password parameter should include common passwords, password length, null byte injection, removing the parameter, XSS, and more. +O ASVS foi projetado para ser altamente testável. Algumas verificações serão técnicas, enquanto outros requisitos (como os requisitos arquitetônicos e de documentação) podem exigir revisão de documentação ou de arquitetura. Ao construir testes de unidade e de integração que testem e façam fuzzing para casos de abuso específicos e relevantes relacionados aos requisitos que são verificáveis por meios técnicos, deve ser mais fácil verificar se esses controles estão operando corretamente em cada build. Por exemplo, testes adicionais podem ser elaborados para a suíte de testes de um controlador de login, testando o parâmetro de nome de usuário para nomes de usuário padrão comuns, enumeração de contas, força bruta, injeção de LDAP e SQL e XSS. Da mesma forma, um teste no parâmetro de senha deve incluir senhas comuns, comprimento de senha, injeção de byte nulo, remoção do parâmetro, XSS e muito mais. -### For Secure Development Training +### Para Treinamento de Desenvolvimento Seguro -ASVS can also be used to define the characteristics of secure software. Many “secure coding” courses are simply ethical hacking courses with a light smear of coding tips. This may not necessarily help developers to write more secure code. Instead, secure development courses can use the ASVS with a strong focus on the positive mechanisms found in the ASVS, rather than the Top 10 negative things not to do. The ASVS structure also provides a logical structure for walking through the different topics when securing an application. +O ASVS também pode ser usado para definir as características de um software seguro. Muitos cursos de “codificação segura” são simplesmente cursos de hacking ético com uma leve camada de dicas de codificação. Isso pode não necessariamente ajudar os desenvolvedores a escreverem códigos mais seguros. Em vez disso, cursos de desenvolvimento seguro podem usar o ASVS com um forte foco nos mecanismos positivos encontrados no ASVS, em vez das 10 principais coisas negativas que não se deve fazer (Top 10). A estrutura do ASVS também fornece uma estrutura lógica para percorrer os diferentes tópicos ao proteger uma aplicação. -### As a Framework for Guiding the Procurement of Secure Software +### Como Framework para Guiar a Aquisição de Software Seguro -The ASVS is a great framework to help with secure software procurement or procurement of custom development services. The buyer can simply set a requirement that the software they wish to procure must be developed at ASVS level X, and request that the seller proves that the software satisfies ASVS level X. +O ASVS é um excelente framework para ajudar na aquisição de software seguro ou na aquisição de serviços de desenvolvimento sob medida. O comprador pode simplesmente estabelecer um requisito de que o software que deseja adquirir deve ser desenvolvido no nível X do ASVS e solicitar que o vendedor comprove que o software satisfaz o nível X do ASVS. -## Applying ASVS in Practice +## Aplicando o ASVS na Prática -Different threats have different motivations. Some industries have unique information and technology assets and domain-specific regulatory compliance requirements. +Ameaças diferentes têm motivações diferentes. Algumas indústrias possuem ativos de informação e tecnologia únicos, bem como requisitos de conformidade regulatória específicos de domínio. -Organizations are strongly encouraged to look deeply at their unique risk characteristics based on the nature of their business, and based upon that risk and business requirements determine the appropriate ASVS level. +As organizações são fortemente encorajadas a analisar profundamente suas características únicas de risco com base na natureza de seus negócios e, com base nesse risco e nos requisitos de negócios, determinar o nível apropriado do ASVS. \ No newline at end of file diff --git a/5.0/pt/0x04-Assessment_and_Certification.md b/5.0/pt/0x04-Assessment_and_Certification.md index da84e85661..27f7ddb42a 100644 --- a/5.0/pt/0x04-Assessment_and_Certification.md +++ b/5.0/pt/0x04-Assessment_and_Certification.md @@ -1,47 +1,47 @@ -# Assessment and Certification +# Avaliação e Certificação -## OWASP's Stance on ASVS Certifications and Trust Marks +## A Postura da OWASP sobre Certificações e Selos de Confiança do ASVS -OWASP, as a vendor-neutral nonprofit, does not certify any vendors, verifiers, or software. Any assurance, trust mark, or certification claiming ASVS compliance is not officially endorsed by OWASP, so organizations should be cautious of third-party claims of ASVS certification. +A OWASP, sendo uma organização sem fins lucrativos e neutra em relação a fornecedores, não certifica nenhum fornecedor, verificador ou software. Qualquer garantia, selo de confiança ou certificação que alegue conformidade com o ASVS não é oficialmente endossado pela OWASP, portanto, as organizações devem ser cautelosas com alegações de certificação do ASVS feitas por terceiros. -Organizations may offer assurance services, provided they do not claim official OWASP certification. +As organizações podem oferecer serviços de garantia (assurance services), desde que não aleguem certificação oficial da OWASP. -## How to Verify ASVS Compliance +## Como Verificar a Conformidade com o ASVS -The ASVS is deliberately not presciptive about exactly how to verify compliance at the level of a testing guide. However, it is important to highlight some key points. +O ASVS deliberadamente não é prescritivo sobre exatamente como verificar a conformidade no nível de um guia de testes. No entanto, é importante destacar alguns pontos-chave. -### Verification reporting +### Relatório de Verificação -Traditional penetration testing reports issues “by exception,” only listing failures. However, an ASVS certification report should include scope, a summary of all requirements checked, the requirements where execptions were noted, and guidance on resolving issues. Some requirements may be non-applicable (e.g., session management in stateless APIs), and this must be noted in the report. +Os relatórios tradicionais de testes de intrusão (penetration testing) relatam problemas "por exceção", listando apenas as falhas. No entanto, um relatório de certificação do ASVS deve incluir o escopo, um resumo de todos os requisitos verificados, os requisitos onde foram observadas exceções e orientações sobre como resolver os problemas. Alguns requisitos podem não ser aplicáveis (por exemplo, gerenciamento de sessão em APIs sem estado/stateless), e isso deve ser observado no relatório. -### Scope of Verification +### Escopo da Verificação -An organization developing an application will generally not implement all requirements, as some may be irrelevant or less significant based on the functionality of the application. The verifier should make the scope of the verification clear including which Level the organization is attempting to achieve and which requirements were included. This should be from the perspective of what was included rather than what was not included. They should also provide an opinion on the rationale of excluding the requirements which haven't been implemented. +Uma organização que desenvolve uma aplicação geralmente não implementará todos os requisitos, pois alguns podem ser irrelevantes ou menos significativos com base na funcionalidade da aplicação. O verificador deve deixar o escopo da verificação claro, incluindo qual Nível a organização está tentando alcançar e quais requisitos foram incluídos. Isso deve ser feito sob a perspectiva do que foi incluído, em vez do que não foi incluído. Eles também devem fornecer uma opinião sobre a justificativa para a exclusão dos requisitos que não foram implementados. -This should allow the consumer of a verification report to understand the context of the verification and make an informed decision about the level of trust they can place in the application. +Isso deve permitir que o consumidor de um relatório de verificação entenda o contexto da verificação e tome uma decisão informada sobre o nível de confiança que pode depositar na aplicação. -Certifying organizations can choose their testing methods but should disclose them in the report and this should ideally be repeatable. Different methods, like manual penetration tests or source code analysis, may be used to verify aspects such as input validation, depending on the application and requirements. +As organizações certificadoras podem escolher seus métodos de teste, mas devem divulgá-los no relatório, e idealmente, isso deve ser repetível. Diferentes métodos, como testes manuais de intrusão ou análise de código-fonte, podem ser usados para verificar aspectos como validação de entrada, dependendo da aplicação e dos requisitos. -### Verification Mechanisms +### Mecanismos de Verificação -There are a number of different techniques which may be needed to verify specific ASVS requirements. Aside from penetration testing (using valid credentials to get full application coverage), verifying ASVS requirements may require access to documentation, source code, configuration, and the people involved in the development process. Especially for verifying L2 and L3 requirements. It is standard practice to provide robust evidence of findings with detailed documentation, which may include work papers, screenshots, scripts, and testing logs. Merely running an automated tool without thorough testing is insufficient for certification, as each requirement must be verifiably tested. +Existem diversas técnicas diferentes que podem ser necessárias para verificar requisitos específicos do ASVS. Além dos testes de intrusão (usando credenciais válidas para obter cobertura total da aplicação), a verificação dos requisitos do ASVS pode exigir acesso à documentação, ao código-fonte, às configurações e às pessoas envolvidas no processo de desenvolvimento. Especialmente para verificar os requisitos L2 e L3. É prática padrão fornecer evidências robustas das descobertas com documentação detalhada, que pode incluir documentos de trabalho, capturas de tela (screenshots), scripts e logs de testes. Apenas executar uma ferramenta automatizada sem testes minuciosos é insuficiente para a certificação, pois cada requisito deve ser comprovadamente testado. -The use of automation to verify ASVS requirements is a topic that is constantly of interest. It is therefore important to clarify some points related to automated and black box testing. +O uso de automação para verificar requisitos do ASVS é um tópico de constante interesse. Portanto, é importante esclarecer alguns pontos relacionados a testes automatizados e testes de caixa preta (black box). -#### The Role of Automated Security Testing Tools +#### O Papel das Ferramentas de Teste de Segurança Automatizado -When automated security testing tools such as Dynamic and Static Application Security Testing tools (DAST and SAST) are correctly implemented in the build pipeline, they may be able to identify some security issues that should never exist. However, without careful configuration and tuning they will not provide the required coverage and the level of noise will prevent real security issues from being identified and mitigated. +Quando ferramentas automatizadas de teste de segurança, como as ferramentas DAST (Dynamic Application Security Testing) e SAST (Static Application Security Testing), são implementadas corretamente no pipeline de construção (build), elas podem ser capazes de identificar alguns problemas de segurança que nunca deveriam existir. No entanto, sem configuração e ajuste cuidadosos, elas não fornecerão a cobertura exigida, e o nível de ruído impedirá que problemas reais de segurança sejam identificados e mitigados. -Whilst this may provide coverage of some of the more basic and straightforward technical requirements such as those relating to output encoding or sanitiation, it is critical to note that these tools will be unable entirely to verify many of the more complicated ASVS requirements or those that relate to business logic and access control. +Embora isso possa fornecer cobertura para alguns dos requisitos técnicos mais básicos e diretos, como os relacionados à codificação ou sanitização de saída, é fundamental notar que essas ferramentas serão incapazes de verificar inteiramente muitos dos requisitos mais complicados do ASVS ou aqueles que se relacionam à lógica de negócios e ao controle de acesso. -For less straightforward requirements, it is likely that automation can still be utilized but application specific verifications will need to be written to achieve this. These may be similar to unit and integration tests that the organization may already be using. It may therefore be possible to use this existing test automation infrastructure to write these ASVS specific tests. Whilst doing this will require short term investment, the long term benefits being able to continually verify these ASVS requirements will be significant. +Para requisitos menos diretos, é provável que a automação ainda possa ser utilizada, mas verificações específicas da aplicação precisarão ser escritas para alcançar isso. Estas podem ser semelhantes aos testes de unidade e de integração que a organização já pode estar usando. Portanto, pode ser possível usar essa infraestrutura de automação de testes existente para escrever esses testes específicos do ASVS. Embora fazer isso exija investimento de curto prazo, os benefícios de longo prazo de ser capaz de verificar continuamente esses requisitos do ASVS serão significativos. -In summary, testable using automation != running an off the shelf tool. +Em resumo, testável usando automação != executar uma ferramenta pronta para uso (off the shelf). -#### The Role of Penetration Testing +#### O Papel do Teste de Intrusão -Whilst L1 in version 4.0 was optimized for "black box" (no documentation and no source) testing to occur, even then the standard was clear that it is not an effective assurance activity and should be actively discouraged. +Enquanto o L1 na versão 4.0 foi otimizado para a ocorrência de testes "caixa preta" (sem documentação e sem código-fonte), mesmo na época o padrão era claro de que esta não é uma atividade de garantia eficaz e deve ser ativamente desencorajada. -Testing without access to necessary additional information is an inefficient and ineffective mechanism for security verification, as it misses out on the possibility of reviewing the source, identifying threats and missing controls, and performing a far more thorough test in a shorter timeframe. +Testar sem acesso a informações adicionais necessárias é um mecanismo ineficiente e ineficaz para verificação de segurança, pois perde a possibilidade de revisar o código-fonte, identificar ameaças e controles ausentes, e realizar um teste muito mais completo em um prazo mais curto. -It is strongly encouraged to perform documentation or source code-led (hybrid) penetration testing, which have full access to the application developers and the application's documentation, rather than traditional penetration tests. This will certainly be necessary in order to verify many of the ASVS requirements. +É fortemente encorajado realizar testes de intrusão guiados por documentação ou código-fonte (híbridos), que tenham acesso total aos desenvolvedores da aplicação e à documentação da aplicação, em vez de testes de intrusão tradicionais. Isso certamente será necessário para verificar muitos dos requisitos do ASVS. \ No newline at end of file diff --git a/5.0/pt/0x05-For-Users-Of-4.0.md b/5.0/pt/0x05-For-Users-Of-4.0.md index 281d61a775..6dbe89045c 100644 --- a/5.0/pt/0x05-For-Users-Of-4.0.md +++ b/5.0/pt/0x05-For-Users-Of-4.0.md @@ -1,90 +1,90 @@ -# Changes Compared to v4.x +# Alterações em Relação à Versão 4.x -## Introduction +## Introdução -Users familiar with version 4.x of the standard may find it helpful to review the key changes introduced in version 5.0, including updates in content, scope, and underlying philosophy. +Os usuários familiarizados com a versão 4.x do padrão podem achar útil revisar as principais alterações introduzidas na versão 5.0, incluindo atualizações de conteúdo, escopo e filosofia subjacente. -Of the 286 requirements in version 4.0.3, only 11 remain unchanged, while 15 have undergone minor grammatical adjustments without altering their meaning. In total 109 requirements (38%) are no longer separate requirements in version 5.0 with 50 simply being deleted, 28 removed as duplicates and 31 merged into other requirements. The rest have been revised in some way. Even requirements that were not substantively modified have different identifiers due to reordering or restructuring. +Dos 286 requisitos da versão 4.0.3, apenas 11 permanecem inalterados, enquanto 15 passaram por pequenos ajustes gramaticais sem alterar seu significado. No total, 109 requisitos (38%) não são mais requisitos separados na versão 5.0, com 50 simplesmente sendo excluídos, 28 removidos como duplicados e 31 mesclados em outros requisitos. O restante foi revisado de alguma forma. Mesmo os requisitos que não foram substancialmente modificados têm identificadores diferentes devido à reordenação ou reestruturação. -To facilitate adoption of version 5.0, mapping documents are provided to help users trace how requirements from version 4.x correspond to those in version 5.0. These mappings are not tied to release versioning and may be updated or clarified as needed. +Para facilitar a adoção da versão 5.0, documentos de mapeamento são fornecidos para ajudar os usuários a rastrear como os requisitos da versão 4.x correspondem aos da versão 5.0. Estes mapeamentos não estão vinculados ao versionamento de lançamentos e podem ser atualizados ou esclarecidos conforme necessário. -## Requirement Philosophy +## Filosofia dos Requisitos -### Scope and Focus +### Escopo e Foco -Version 4.x included requirements that did not align with the intended scope of the standard; these have been removed. Requirements that did not meet the scope criteria for 5.0 or were not verifiable have also been excluded. +A versão 4.x incluía requisitos que não se alinhavam com o escopo pretendido do padrão; estes foram removidos. Requisitos que não atendiam aos critérios de escopo para a versão 5.0 ou não eram verificáveis também foram excluídos. -### Emphasis on Security Goals Over Mechanisms +### Ênfase nos Objetivos de Segurança Sobre os Mecanismos -In version 4.x, many requirements focused on specific mechanisms rather than the underlying security objectives. In version 5.0, requirements are centered on security goals, referencing particular mechanisms only when they are the sole practical solution, or providing them as examples or supplementary guidance. +Na versão 4.x, muitos requisitos se concentravam em mecanismos específicos, em vez dos objetivos de segurança subjacentes. Na versão 5.0, os requisitos estão centrados nas metas de segurança, fazendo referência a mecanismos particulares apenas quando são a única solução prática, ou fornecendo-os como exemplos ou orientação complementar. -This approach recognizes that multiple methods may exist to achieve a given security objective, and avoids unnecessary prescriptiveness that could limit organizational flexibility. +Essa abordagem reconhece que podem existir vários métodos para atingir um determinado objetivo de segurança e evita uma prescritividade desnecessária que poderia limitar a flexibilidade organizacional. -Additionally, requirements addressing the same security concern have been consolidated where appropriate. +Além disso, requisitos que abordam a mesma preocupação de segurança foram consolidados quando apropriado. -### Documented Security Decisions +### Decisões de Segurança Documentadas -While the concept of documented security decisions may appear new in version 5.0, it is an evolution of earlier requirements related to policy application and threat modeling in version 4.0. Previously, some requirements implicitly demanded analysis to inform the implementation of security controls, such as determining permitted network connections. +Embora o conceito de decisões de segurança documentadas possa parecer novo na versão 5.0, ele é uma evolução de requisitos anteriores relacionados à aplicação de políticas e modelagem de ameaças na versão 4.0. Anteriormente, alguns requisitos exigiam implicitamente análises para informar a implementação de controles de segurança, como a determinação de conexões de rede permitidas. -To ensure that necessary information is available for implementation and verification, these expectations are now explicitly defined as documentation requirements, making them clear, actionable, and verifiable. +Para garantir que as informações necessárias estejam disponíveis para implementação e verificação, essas expectativas agora são explicitamente definidas como requisitos de documentação, tornando-os claros, acionáveis e verificáveis. -## Structural Changes and New Chapters +## Mudanças Estruturais e Novos Capítulos -Several chapters in version 5.0 introduce entirely new content: +Vários capítulos na versão 5.0 introduzem conteúdo totalmente novo: -* OAuth and OIDC – Given the widespread adoption of these protocols for access delegation and single sign-on, dedicated requirements have been added to address the diverse scenarios developers may encounter. This area may eventually evolve into a standalone standard, similar to the treatment of Mobile and IoT requirements in previous versions. -* WebRTC – As this technology gains popularity, its unique security considerations and challenges are now addressed in a dedicated section. +* OAuth e OIDC – Dada a ampla adoção desses protocolos para delegação de acesso e logon único (single sign-on), requisitos dedicados foram adicionados para abordar os diversos cenários que os desenvolvedores podem encontrar. Essa área pode eventualmente evoluir para um padrão autônomo, semelhante ao tratamento dos requisitos de Mobile e IoT em versões anteriores. +* WebRTC – À medida que essa tecnologia ganha popularidade, suas considerações e desafios de segurança exclusivos agora são abordados em uma seção dedicada. -Efforts have also been made to ensure that chapters and sections are organized around coherent sets of related requirements. +Esforços também foram feitos para garantir que capítulos e seções sejam organizados em torno de conjuntos coerentes de requisitos relacionados. -This restructuring has led to the creation of additional chapters: +Esta reestruturação levou à criação de capítulos adicionais: -* Self-contained Tokens – Formerly grouped under session management, self-contained tokens are now recognized as a distinct mechanism and a foundational element for stateless communication (such as in OAuth and OIDC). Due to their unique security implications, they are addressed in a dedicated chapter, with some new requirements introduced in version 5.x. -* Web Frontend Security – With the increasing complexity of browser-based applications and the rise of API-only architectures, frontend security requirements have been separated into their own chapter. -* Secure Coding and Architecture – New requirements addressing general security practices that did not fit within existing chapters have been grouped here. +* Tokens Autocontidos (Self-contained Tokens) – Anteriormente agrupados no gerenciamento de sessão, os tokens autocontidos agora são reconhecidos como um mecanismo distinto e um elemento fundamental para comunicação sem estado (como no OAuth e OIDC). Devido às suas implicações de segurança exclusivas, eles são abordados em um capítulo dedicado, com alguns novos requisitos introduzidos na versão 5.x. +* Segurança de Frontend Web – Com a crescente complexidade das aplicações baseadas em navegador e a ascensão de arquiteturas exclusivas de API (API-only), os requisitos de segurança de frontend foram separados em seu próprio capítulo. +* Codificação e Arquitetura Seguras – Novos requisitos que abordam práticas gerais de segurança que não se encaixavam nos capítulos existentes foram agrupados aqui. -Other organizational changes in version 5.0 were made to clarify intent. For example, input validation requirements were moved alongside business logic, reflecting their role in enforcing business rules, rather than being grouped with sanitization and encoding. +Outras mudanças organizacionais na versão 5.0 foram feitas para esclarecer a intenção. Por exemplo, os requisitos de validação de entrada foram movidos para o lado da lógica de negócios, refletindo seu papel na aplicação de regras de negócios, em vez de serem agrupados com sanitização e codificação. -The former V1 Architecture chapter has been removed. Its initial section contained requirements that were out of scope, while subsequent sections have been redistributed to relevant chapters, with requirements deduplicated and clarified as necessary. +O antigo capítulo de Arquitetura (V1) foi removido. Sua seção inicial continha requisitos que estavam fora do escopo, enquanto as seções subsequentes foram redistribuídas para capítulos relevantes, com requisitos desduplicados e esclarecidos conforme necessário. -## Removal of Direct Mappings to Other Standards +## Remoção de Mapeamentos Diretos para Outros Padrões -Direct mappings to other standards have been removed from the main body of the standard. The aim is to prepare a mapping with the OWASP Common Requirement Enumeration (CRE) project, which in turn will link ASVS to a range of OWASP projects and external standards. +Mapeamentos diretos para outros padrões foram removidos do corpo principal do padrão. O objetivo é preparar um mapeamento com o projeto OWASP Common Requirement Enumeration (CRE), que, por sua vez, vinculará o ASVS a uma série de projetos da OWASP e padrões externos. -Direct mappings to CWE and NIST are no longer maintained, as explained below. +Mapeamentos diretos para CWE e NIST não são mais mantidos, conforme explicado abaixo. -### Reduced Coupling with NIST Digital Identity Guidelines +### Redução do Acoplamento com as Diretrizes de Identidade Digital do NIST -The NIST [Digital Identity Guidelines (SP 800-63)](https://pages.nist.gov/800-63-3/) have long served as a reference for authentication and authorization controls. In version 4.x, certain chapters were closely aligned with NIST's structure and terminology. +As [Diretrizes de Identidade Digital do NIST (SP 800-63)](https://pages.nist.gov/800-63-3/) servem há muito tempo como referência para controles de autenticação e autorização. Na versão 4.x, certos capítulos estavam intimamente alinhados com a estrutura e terminologia do NIST. -While these guidelines remain an important reference, strict alignment introduced challenges, including less widely recognized terminology, duplication of similar requirements, and incomplete mappings. Version 5.0 moves away from this approach to improve clarity and relevance. +Embora estas diretrizes continuem sendo uma referência importante, o alinhamento estrito introduziu desafios, incluindo terminologia menos amplamente reconhecida, duplicação de requisitos semelhantes e mapeamentos incompletos. A versão 5.0 se afasta dessa abordagem para melhorar a clareza e a relevância. -### Moving Away from Common Weakness Enumeration (CWE) +### Afastamento da Common Weakness Enumeration (CWE) -The [Common Weakness Enumeration (CWE)](https://cwe.mitre.org/) provides a useful taxonomy of software security weaknesses. However, challenges such as category-only CWEs, difficulties in mapping requirements to a single CWE, and the presence of imprecise mappings in version 4.x have led to the decision to discontinue direct CWE mappings in version 5.0. +A [Common Weakness Enumeration (CWE)](https://cwe.mitre.org/) fornece uma taxonomia útil de fraquezas na segurança de software. No entanto, desafios como CWEs exclusivas de categoria, dificuldades em mapear requisitos para uma única CWE e a presença de mapeamentos imprecisos na versão 4.x levaram à decisão de descontinuar os mapeamentos diretos de CWE na versão 5.0. -## Rethinking Level Definitions +## Repensando as Definições de Nível -Version 4.x described the levels as L1 ("Minimum"), L2 ("Standard"), and L3 ("Advanced"), with the implication that all applications handling sensitive data should meet at least L2. +A versão 4.x descrevia os níveis como L1 ("Mínimo"), L2 ("Padrão") e L3 ("Avançado"), com a implicação de que todas as aplicações que lidam com dados sensíveis deveriam atender pelo menos ao L2. -Version 5.0 addresses several issues with this approach which are described in the following paragraphs. +A versão 5.0 aborda vários problemas com essa abordagem, que são descritos nos parágrafos a seguir. -As a practical matter, whereas version 4.x used tick marks for level indicators, 5.x uses a simple number on all formats of the standard including markdown, PDF, DOCX, CSV, JSON and XML. For backwards compatibility, legacy versions of the CSV, JSON and XML outputs which still use tick marks are also generated. +Como uma questão prática, enquanto a versão 4.x usava marcas de seleção (tick marks) para indicadores de nível, a 5.x usa um número simples em todos os formatos do padrão, incluindo markdown, PDF, DOCX, CSV, JSON e XML. Para compatibilidade com versões anteriores, versões legadas das saídas CSV, JSON e XML que ainda usam marcas de seleção também são geradas. -### Easier Entry Level +### Nível de Entrada Mais Fácil -Feedback indicated that the large number of Level 1 requirements (~120), combined with its designation as the "minimum" level that is not good enough for most applications, discouraged adoption. Version 5.0 aims to lower this barrier by defining Level 1 primarily around first-layer defense requirements, resulting in clearer and fewer requirements at that level. To demonstrate this numerically, in v4.0.3 there were 128 L1 requirements out of a total of 278 requirements, representing 46%. In 5.0.0 there are 70 L1 requirements out of a total of 345 requirements, representing 20%. +O feedback indicou que o grande número de requisitos do Nível 1 (~120), combinado com a sua designação como o nível "mínimo" que não é bom o suficiente para a maioria das aplicações, desencorajava a adoção. A versão 5.0 visa diminuir essa barreira definindo o Nível 1 principalmente em torno de requisitos de primeira camada de defesa, resultando em requisitos mais claros e em menor número nesse nível. Para demonstrar isso numericamente, na versão 4.0.3 havia 128 requisitos L1 em um total de 278 requisitos, representando 46%. Na 5.0.0, existem 70 requisitos L1 de um total de 345 requisitos, representando 20%. -### The Fallacy of Testability +### A Falácia da Testabilidade -A key factor in selecting controls for Level 1 in version 4.x was their suitability for assessment through "black box" external penetration testing. However, this approach was not fully aligned with the intent of Level 1 as the minimum set of security controls. Some users argued that Level 1 was insufficient for securing applications, while others found it too difficult to test. +Um fator-chave na seleção de controles para o Nível 1 na versão 4.x era a sua adequação para avaliação através de testes de intrusão externos tipo "caixa preta" (black box). No entanto, esta abordagem não estava totalmente alinhada com a intenção do Nível 1 como o conjunto mínimo de controles de segurança. Alguns usuários argumentaram que o Nível 1 era insuficiente para proteger as aplicações, enquanto outros o consideravam muito difícil de testar. -Relying on testability as a criterion is both relative and, at times, misleading. The fact that a requirement is testable does not guarantee that it can be tested in an automated or straightforward manner. Moreover, the most easily testable requirements are not always those with the greatest security impact or the simplest to implement. +Confiar na testabilidade como um critério é algo relativo e, por vezes, enganoso. O fato de um requisito ser testável não garante que ele possa ser testado de maneira automatizada ou direta. Além disso, os requisitos mais facilmente testáveis nem sempre são aqueles com o maior impacto de segurança ou os mais simples de implementar. -As such, in version 5.0, the level decisions were made primarily based on risk reduction and also keeping in mind the effort to implement. +Sendo assim, na versão 5.0, as decisões de nível foram tomadas principalmente com base na redução de risco e também mantendo em mente o esforço para implementar. -### Not Just About Risk +### Não se Trata Apenas de Risco -The use of prescriptive, risk-based levels that mandate a specific level for certain applications has proven to be overly rigid. In practice, the prioritization and implementation of security controls depend on multiple factors, including both risk reduction and the effort required for implementation. +O uso de níveis prescritivos e baseados em risco que exigem um nível específico para certas aplicações provou ser excessivamente rígido. Na prática, a priorização e a implementação de controles de segurança dependem de vários fatores, incluindo a redução de risco e o esforço necessário para a implementação. -Therefore, organizations are encouraged to achieve the level that they feel like they should be achieving based on their maturity and the message they want to send to their users. +Portanto, as organizações são encorajadas a alcançar o nível que acreditam que deveriam alcançar com base em sua maturidade e na mensagem que desejam transmitir aos seus usuários. \ No newline at end of file diff --git a/5.0/pt/0x10-V1-Encoding-and-Sanitization.md b/5.0/pt/0x10-V1-Encoding-and-Sanitization.md index 2a85c33148..c5d95f7e94 100644 --- a/5.0/pt/0x10-V1-Encoding-and-Sanitization.md +++ b/5.0/pt/0x10-V1-Encoding-and-Sanitization.md @@ -1,91 +1,91 @@ -# V1 Encoding and Sanitization +# V1 Codificação e Sanitização -## Control Objective +## Objetivo de Controle -This chapter addresses the most common web application security weaknesses related to the unsafe processing of untrusted data. Such weaknesses can result in various technical vulnerabilities, where untrusted data is interpreted according to the syntax rules of the relevant interpreter. +Este capítulo aborda as fraquezas de segurança de aplicações web mais comuns relacionadas ao processamento inseguro de dados não confiáveis. Tais fraquezas podem resultar em várias vulnerabilidades técnicas, onde dados não confiáveis são interpretados de acordo com as regras de sintaxe do interpretador relevante. -For modern web applications, it is always best to use safer APIs, such as parameterized queries, auto-escaping, or templating frameworks. Otherwise, carefully performed output encoding, escaping, or sanitization becomes critical to the application's security. +Para aplicações web modernas, é sempre melhor usar APIs mais seguras, como consultas parametrizadas, auto-escaping ou frameworks de template. Caso contrário, a codificação de saída, o escaping ou a sanitização realizados de forma cuidadosa tornam-se críticos para a segurança da aplicação. -Input validation serves as a defense-in-depth mechanism to protect against unexpected or dangerous content. However, since its primary purpose is to ensure that incoming content matches functional and business expectations, requirements related to this can be found in the "Validation and Business Logic" chapter. +A validação de entrada serve como um mecanismo de defesa em profundidade para proteger contra conteúdo inesperado ou perigoso. No entanto, como seu objetivo principal é garantir que o conteúdo recebido corresponda às expectativas funcionais e de negócios, os requisitos relacionados a isso podem ser encontrados no capítulo "Validação e Lógica de Negócios" (Validation and Business Logic). -## V1.1 Encoding and Sanitization Architecture +## V1.1 Arquitetura de Codificação e Sanitização -In the sections below, syntax-specific or interpreter-specific requirements for safely processing unsafe content to avoid security vulnerabilities are provided. The requirements in this section cover the order in which this processing should occur and where it should take place. They also aim to ensure that whenever data is stored, it remains in its original state and is not stored in an encoded or escaped form (e.g., HTML encoding), to prevent double encoding issues. +Nas seções abaixo, são fornecidos requisitos específicos de sintaxe ou específicos de interpretador para o processamento seguro de conteúdo inseguro, a fim de evitar vulnerabilidades de segurança. Os requisitos nesta seção cobrem a ordem em que esse processamento deve ocorrer e onde ele deve ser realizado. Eles também visam garantir que, sempre que os dados forem armazenados, eles permaneçam em seu estado original e não sejam armazenados em formato codificado ou com escape (por exemplo, codificação HTML), para evitar problemas de codificação dupla (double encoding). -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **1.1.1** | Verify that input is decoded or unescaped into a canonical form only once, it is only decoded when encoded data in that form is expected, and that this is done before processing the input further, for example it is not performed after input validation or sanitization. | 2 | -| **1.1.2** | Verify that the application performs output encoding and escaping either as a final step before being used by the interpreter for which it is intended or by the interpreter itself. | 2 | +| **1.1.1** | Verifique se a entrada é decodificada ou desescapada (unescaped) para uma forma canônica apenas uma vez, se é decodificada apenas quando os dados codificados nessa forma são esperados, e se isso é feito antes de processar a entrada posteriormente (por exemplo, não é realizado após a validação ou sanitização da entrada). | 2 | +| **1.1.2** | Verifique se a aplicação realiza a codificação e o escaping de saída como uma etapa final antes de ser usada pelo interpretador ao qual se destina, ou pelo próprio interpretador. | 2 | -## V1.2 Injection Prevention +## V1.2 Prevenção de Injeção -Output encoding or escaping, performed close to or adjacent to a potentially dangerous context, is critical to the security of any application. Typically, output encoding and escaping are not persisted, but are instead used to render output safe for immediate use in the appropriate interpreter. Attempting to perform this too early may result in malformed content or render the encoding or escaping ineffective. +A codificação ou escaping de saída, realizada próxima ou adjacente a um contexto potencialmente perigoso, é crítica para a segurança de qualquer aplicação. Normalmente, a codificação e o escaping de saída não são persistidos, mas são usados para tornar a saída segura para uso imediato no interpretador apropriado. Tentar realizar isso muito cedo pode resultar em conteúdo malformado ou tornar a codificação ou o escaping ineficazes. -In many cases, software libraries include safe or safer functions that perform this automatically, although it is necessary to ensure that they are correct for the current context. +Em muitos casos, as bibliotecas de software incluem funções seguras ou mais seguras que realizam isso automaticamente, embora seja necessário garantir que elas estejam corretas para o contexto atual. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **1.2.1** | Verify that output encoding for an HTTP response, HTML document, or XML document is relevant for the context required, such as encoding the relevant characters for HTML elements, HTML attributes, HTML comments, CSS, or HTTP header fields, to avoid changing the message or document structure. | 1 | -| **1.2.2** | Verify that when dynamically building URLs, untrusted data is encoded according to its context (e.g., URL encoding or base64url encoding for query or path parameters). Ensure that only safe URL protocols are permitted (e.g., disallow javascript: or data:). | 1 | -| **1.2.3** | Verify that output encoding or escaping is used when dynamically building JavaScript content (including JSON), to avoid changing the message or document structure (to avoid JavaScript and JSON injection). | 1 | -| **1.2.4** | Verify that data selection or database queries (e.g., SQL, HQL, NoSQL, Cypher) use parameterized queries, ORMs, entity frameworks, or are otherwise protected from SQL Injection and other database injection attacks. This is also relevant when writing stored procedures. | 1 | -| **1.2.5** | Verify that the application protects against OS command injection and that operating system calls use parameterized OS queries or use contextual command line output encoding. | 1 | -| **1.2.6** | Verify that the application protects against LDAP injection vulnerabilities, or that specific security controls to prevent LDAP injection have been implemented. | 2 | -| **1.2.7** | Verify that the application is protected against XPath injection attacks by using query parameterization or precompiled queries. | 2 | -| **1.2.8** | Verify that LaTeX processors are configured securely (such as not using the "--shell-escape" flag) and an allowlist of commands is used to prevent LaTeX injection attacks. | 2 | -| **1.2.9** | Verify that the application escapes special characters in regular expressions (typically using a backslash) to prevent them from being misinterpreted as metacharacters. | 2 | -| **1.2.10** | Verify that the application is protected against CSV and Formula Injection. The application must follow the escaping rules defined in RFC 4180 sections 2.6 and 2.7 when exporting CSV content. Additionally, when exporting to CSV or other spreadsheet formats (such as XLS, XLSX, or ODF), special characters (including '=', '+', '-', '@', '\t' (tab), and '\0' (null character)) must be escaped with a single quote if they appear as the first character in a field value. | 3 | +| **1.2.1** | Verifique se a codificação de saída para uma resposta HTTP, documento HTML ou documento XML é relevante para o contexto exigido, como codificar os caracteres relevantes para elementos HTML, atributos HTML, comentários HTML, CSS ou campos de cabeçalho HTTP, para evitar alterar a mensagem ou a estrutura do documento. | 1 | +| **1.2.2** | Verifique se, ao construir URLs dinamicamente, os dados não confiáveis são codificados de acordo com seu contexto (por exemplo, codificação de URL ou codificação base64url para parâmetros de consulta ou de caminho). Garanta que apenas protocolos de URL seguros sejam permitidos (por exemplo, proibir javascript: ou data:). | 1 | +| **1.2.3** | Verifique se a codificação ou escaping de saída é usado ao construir conteúdo JavaScript dinamicamente (incluindo JSON), para evitar a alteração da mensagem ou da estrutura do documento (para evitar a injeção de JavaScript e JSON). | 1 | +| **1.2.4** | Verifique se a seleção de dados ou consultas a bancos de dados (por exemplo, SQL, HQL, NoSQL, Cypher) usam consultas parametrizadas, ORMs, entity frameworks ou são de outra forma protegidas contra injeção de SQL e outros ataques de injeção de banco de dados. Isso também é relevante ao escrever procedimentos armazenados (stored procedures). | 1 | +| **1.2.5** | Verifique se a aplicação protege contra injeção de comando no sistema operacional (OS) e se as chamadas de sistema operacional usam consultas de OS parametrizadas ou usam codificação de saída de linha de comando contextual. | 1 | +| **1.2.6** | Verifique se a aplicação protege contra vulnerabilidades de injeção de LDAP, ou se controles de segurança específicos para prevenir a injeção de LDAP foram implementados. | 2 | +| **1.2.7** | Verifique se a aplicação é protegida contra ataques de injeção de XPath através do uso de parametrização de consultas ou consultas pré-compiladas. | 2 | +| **1.2.8** | Verifique se os processadores LaTeX estão configurados com segurança (como não usar a flag "--shell-escape") e se uma lista de permissões (allowlist) de comandos é usada para evitar ataques de injeção LaTeX. | 2 | +| **1.2.9** | Verifique se a aplicação escapa caracteres especiais em expressões regulares (geralmente usando uma barra invertida) para evitar que sejam mal interpretados como metacaracteres. | 2 | +| **1.2.10** | Verifique se a aplicação está protegida contra injeção de CSV e Fórmulas. A aplicação deve seguir as regras de escaping definidas na RFC 4180 seções 2.6 e 2.7 ao exportar conteúdo CSV. Adicionalmente, ao exportar para CSV ou outros formatos de planilha (como XLS, XLSX ou ODF), caracteres especiais (incluindo '=', '+', '-', '@', '\t' (tab) e '\0' (caractere nulo)) devem ser escapados com uma aspa simples se aparecerem como o primeiro caractere em um valor de campo. | 3 | -Note: Using parameterized queries or escaping SQL is not always sufficient. Query parts such as table and column names (including "ORDER BY" column names) cannot be escaped. Including escaped user-supplied data in these fields results in failed queries or SQL injection. +Nota: O uso de consultas parametrizadas ou o escape de SQL nem sempre é suficiente. Partes da consulta, como nomes de tabelas e colunas (incluindo nomes de colunas "ORDER BY"), não podem ser escapadas. A inclusão de dados escapados fornecidos pelo usuário nesses campos resulta em falhas nas consultas ou injeção de SQL. -## V1.3 Sanitization +## V1.3 Sanitização -The ideal protection against using untrusted content in an unsafe context is to use context-specific encoding or escaping, which maintains the same semantic meaning of the unsafe content but renders it safe for use in that particular context, as discussed in more detail in the previous section. +A proteção ideal contra o uso de conteúdo não confiável em um contexto inseguro é usar codificação ou escaping específicos do contexto, o que mantém o mesmo significado semântico do conteúdo inseguro, mas o torna seguro para uso naquele contexto específico, conforme discutido com mais detalhes na seção anterior. -Where this is not possible, sanitization becomes necessary, removing potentially dangerous characters or content. In some cases, this may change the semantic meaning of the input, but for security reasons, there may be no alternative. +Onde isso não for possível, a sanitização se torna necessária, removendo caracteres ou conteúdos potencialmente perigosos. Em alguns casos, isso pode alterar o significado semântico da entrada, mas, por razões de segurança, pode não haver alternativa. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **1.3.1** | Verify that all untrusted HTML input from WYSIWYG editors or similar is sanitized using a well-known and secure HTML sanitization library or framework feature. | 1 | -| **1.3.2** | Verify that the application avoids the use of eval() or other dynamic code execution features such as Spring Expression Language (SpEL). Where there is no alternative, any user input being included must be sanitized before being executed. | 1 | -| **1.3.3** | Verify that data being passed to a potentially dangerous context is sanitized beforehand to enforce safety measures, such as only allowing characters which are safe for this context and trimming input which is too long. | 2 | -| **1.3.4** | Verify that user-supplied Scalable Vector Graphics (SVG) scriptable content is validated or sanitized to contain only tags and attributes (such as draw graphics) that are safe for the application, e.g., do not contain scripts and foreignObject. | 2 | -| **1.3.5** | Verify that the application sanitizes or disables user-supplied scriptable or expression template language content, such as Markdown, CSS or XSL stylesheets, BBCode, or similar. | 2 | -| **1.3.6** | Verify that the application protects against Server-side Request Forgery (SSRF) attacks, by validating untrusted data against an allowlist of protocols, domains, paths and ports and sanitizing potentially dangerous characters before using the data to call another service. | 2 | -| **1.3.7** | Verify that the application protects against template injection attacks by not allowing templates to be built based on untrusted input. Where there is no alternative, any untrusted input being included dynamically during template creation must be sanitized or strictly validated. | 2 | -| **1.3.8** | Verify that the application appropriately sanitizes untrusted input before use in Java Naming and Directory Interface (JNDI) queries and that JNDI is configured securely to prevent JNDI injection attacks. | 2 | -| **1.3.9** | Verify that the application sanitizes content before it is sent to memcache to prevent injection attacks. | 2 | -| **1.3.10** | Verify that format strings which might resolve in an unexpected or malicious way when used are sanitized before being processed. | 2 | -| **1.3.11** | Verify that the application sanitizes user input before passing to mail systems to protect against SMTP or IMAP injection. | 2 | -| **1.3.12** | Verify that regular expressions are free from elements causing exponential backtracking, and ensure untrusted input is sanitized to mitigate ReDoS or Runaway Regex attacks. | 3 | - -## V1.4 Memory, String, and Unmanaged Code - -The following requirements address risks associated with unsafe memory use, which generally apply when the application uses a systems language or unmanaged code. - -In some cases, it may be possible to achieve this by setting compiler flags that enable buffer overflow protections and warnings, including stack randomization and data execution prevention, and that break the build if unsafe pointer, memory, format string, integer, or string operations are found. - -| # | Description | Level | +| **1.3.1** | Verifique se todas as entradas HTML não confiáveis provenientes de editores WYSIWYG ou similares são sanitizadas usando uma biblioteca de sanitização HTML conhecida e segura ou um recurso de framework. | 1 | +| **1.3.2** | Verifique se a aplicação evita o uso de eval() ou de outros recursos de execução dinâmica de código, como a Spring Expression Language (SpEL). Onde não houver alternativa, qualquer entrada do usuário a ser incluída deve ser sanitizada antes de ser executada. | 1 | +| **1.3.3** | Verifique se os dados que estão sendo passados para um contexto potencialmente perigoso são sanitizados previamente para aplicar medidas de segurança, como permitir apenas caracteres seguros para esse contexto e cortar entradas muito longas (trimming). | 2 | +| **1.3.4** | Verifique se o conteúdo de script Scalable Vector Graphics (SVG) fornecido pelo usuário é validado ou sanitizado para conter apenas tags e atributos (como gráficos de desenho) que são seguros para a aplicação, por exemplo, não conter scripts e foreignObject. | 2 | +| **1.3.5** | Verifique se a aplicação sanitiza ou desabilita o conteúdo fornecido pelo usuário para linguagens de template com suporte a scripts ou expressões, como Markdown, folhas de estilo CSS ou XSL, BBCode ou similares. | 2 | +| **1.3.6** | Verifique se a aplicação protege contra ataques de Falsificação de Solicitação do Lado do Servidor (Server-side Request Forgery - SSRF), validando dados não confiáveis em relação a uma lista de permissões (allowlist) de protocolos, domínios, caminhos e portas, e sanitizando caracteres potencialmente perigosos antes de usar os dados para chamar outro serviço. | 2 | +| **1.3.7** | Verifique se a aplicação protege contra ataques de injeção de template não permitindo que templates sejam criados com base em entradas não confiáveis. Onde não houver alternativa, qualquer entrada não confiável sendo incluída dinamicamente durante a criação do template deve ser sanitizada ou estritamente validada. | 2 | +| **1.3.8** | Verifique se a aplicação sanitiza apropriadamente as entradas não confiáveis antes de usá-las em consultas do Java Naming and Directory Interface (JNDI) e se o JNDI está configurado com segurança para evitar ataques de injeção JNDI. | 2 | +| **1.3.9** | Verifique se a aplicação sanitiza o conteúdo antes de ser enviado ao memcache para prevenir ataques de injeção. | 2 | +| **1.3.10** | Verifique se as format strings (strings de formatação), que podem ser resolvidas de maneira inesperada ou maliciosa quando usadas, são sanitizadas antes de serem processadas. | 2 | +| **1.3.11** | Verifique se a aplicação sanitiza a entrada do usuário antes de passá-la aos sistemas de e-mail para proteger contra injeção SMTP ou IMAP. | 2 | +| **1.3.12** | Verifique se as expressões regulares estão livres de elementos que causam retrocesso exponencial (exponential backtracking) e certifique-se de que a entrada não confiável seja sanitizada para mitigar ataques de ReDoS ou Runaway Regex. | 3 | + +## V1.4 Memória, String e Código Não Gerenciado (Unmanaged Code) + +Os requisitos a seguir abordam os riscos associados ao uso inseguro de memória, que geralmente se aplicam quando a aplicação usa uma linguagem de sistemas ou código não gerenciado (unmanaged code). + +Em alguns casos, é possível conseguir isso definindo flags do compilador que habilitam proteções e avisos contra estouro de buffer (buffer overflow), incluindo randomização de pilha e prevenção de execução de dados, e que quebram a build se operações inseguras de ponteiro, memória, format string, inteiros ou strings forem encontradas. + +| # | Descrição | Nível | | :---: | :--- | :---: | -| **1.4.1** | Verify that the application uses memory-safe string, safer memory copy and pointer arithmetic to detect or prevent stack, buffer, or heap overflows. | 2 | -| **1.4.2** | Verify that sign, range, and input validation techniques are used to prevent integer overflows. | 2 | -| **1.4.3** | Verify that dynamically allocated memory and resources are released, and that references or pointers to freed memory are removed or set to null to prevent dangling pointers and use-after-free vulnerabilities. | 2 | +| **1.4.1** | Verifique se a aplicação usa aritmética de ponteiros, cópia de memória mais segura e strings com segurança de memória para detectar ou prevenir estouros de pilha (stack), buffer ou heap. | 2 | +| **1.4.2** | Verifique se técnicas de validação de sinal, intervalo e entrada são usadas para evitar estouros de inteiros (integer overflows). | 2 | +| **1.4.3** | Verifique se a memória e os recursos alocados dinamicamente são liberados e se as referências ou ponteiros para a memória liberada são removidos ou definidos como nulos (null) para evitar ponteiros pendentes (dangling pointers) e vulnerabilidades de uso após a liberação (use-after-free). | 2 | -## V1.5 Safe Deserialization +## V1.5 Desserialização Segura -The conversion of data from a stored or transmitted representation into actual application objects (deserialization) has historically been the cause of various code injection vulnerabilities. It is important to perform this process carefully and safely to avoid these types of issues. +A conversão de dados de uma representação armazenada ou transmitida em objetos reais da aplicação (desserialização) tem sido historicamente a causa de várias vulnerabilidades de injeção de código. É importante executar esse processo com cuidado e segurança para evitar esses tipos de problemas. -In particular, certain methods of deserialization have been identified by programming language or framework documentation as insecure and cannot be made safe with untrusted data. For each mechanism in use, careful due diligence should be performed. +Em particular, certos métodos de desserialização foram identificados pela documentação da linguagem de programação ou do framework como inseguros e não podem se tornar seguros com dados não confiáveis. Para cada mecanismo em uso, deve-se realizar uma diligência cuidadosa. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **1.5.1** | Verify that the application configures XML parsers to use a restrictive configuration and that unsafe features such as resolving external entities are disabled to prevent XML eXternal Entity (XXE) attacks. | 1 | -| **1.5.2** | Verify that deserialization of untrusted data enforces safe input handling, such as using an allowlist of object types or restricting client-defined object types, to prevent deserialization attacks. Deserialization mechanisms that are explicitly defined as insecure must not be used with untrusted input. | 2 | -| **1.5.3** | Verify that different parsers used in the application for the same data type (e.g., JSON parsers, XML parsers, URL parsers), perform parsing in a consistent way and use the same character encoding mechanism to avoid issues such as JSON Interoperability vulnerabilities or different URI or file parsing behavior being exploited in Remote File Inclusion (RFI) or Server-side Request Forgery (SSRF) attacks. | 3 | +| **1.5.1** | Verifique se a aplicação configura parsers XML para usar uma configuração restritiva e se recursos inseguros, como a resolução de entidades externas, estão desabilitados para prevenir ataques de Entidade Externa XML (XML eXternal Entity - XXE). | 1 | +| **1.5.2** | Verifique se a desserialização de dados não confiáveis impõe tratamento seguro de entrada, como o uso de uma lista de permissões (allowlist) de tipos de objetos ou a restrição de tipos de objetos definidos pelo cliente, para evitar ataques de desserialização. Mecanismos de desserialização explicitamente definidos como inseguros não devem ser usados com entradas não confiáveis. | 2 | +| **1.5.3** | Verifique se diferentes parsers usados na aplicação para o mesmo tipo de dado (por exemplo, parsers JSON, parsers XML, parsers de URL), realizam o parsing de forma consistente e usam o mesmo mecanismo de codificação de caracteres para evitar problemas como vulnerabilidades de Interoperabilidade JSON ou comportamento diferente na análise de URI ou arquivos sendo explorados em ataques de Inclusão Remota de Arquivo (RFI) ou Falsificação de Solicitação do Lado do Servidor (SSRF). | 3 | -## References +## Referências -For more information, see also: +Para mais informações, veja também: * [OWASP LDAP Injection Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/LDAP_Injection_Prevention_Cheat_Sheet.html) * [OWASP Cross Site Scripting Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html) @@ -96,8 +96,8 @@ For more information, see also: * [DOMPurify - Client-side HTML Sanitization Library](https://github.com/cure53/DOMPurify) * [RFC4180 - Common Format and MIME Type for Comma-Separated Values (CSV) Files](https://datatracker.ietf.org/doc/html/rfc4180#section-2) -For more information, specifically on deserialization or parsing issues, please see: +Para obter mais informações, especificamente sobre problemas de desserialização ou parsing, consulte: * [OWASP Deserialization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html) * [An Exploration of JSON Interoperability Vulnerabilities](https://bishopfox.com/blog/json-interoperability-vulnerabilities) -* [Orange Tsai - A New Era of SSRF Exploiting URL Parser In Trending Programming Languages](https://www.blackhat.com/docs/us-17/thursday/us-17-Tsai-A-New-Era-Of-SSRF-Exploiting-URL-Parser-In-Trending-Programming-Languages.pdf) +* [Orange Tsai - A New Era of SSRF Exploiting URL Parser In Trending Programming Languages](https://www.blackhat.com/docs/us-17/thursday/us-17-Tsai-A-New-Era-Of-SSRF-Exploiting-URL-Parser-In-Trending-Programming-Languages.pdf) \ No newline at end of file diff --git a/5.0/pt/0x11-V2-Validation-and-Business-Logic.md b/5.0/pt/0x11-V2-Validation-and-Business-Logic.md index 2b8bf8a6f0..5476afc20f 100644 --- a/5.0/pt/0x11-V2-Validation-and-Business-Logic.md +++ b/5.0/pt/0x11-V2-Validation-and-Business-Logic.md @@ -1,73 +1,73 @@ -# V2 Validation and Business Logic +# V2 Validação e Lógica de Negócios -## Control Objective +## Objetivo de Controle -This chapter aims to ensure that a verified application meets the following high-level goals: +Este capítulo tem como objetivo garantir que uma aplicação verificada atenda aos seguintes objetivos de alto nível: -* Input received by the application matches business or functional expectations. -* The business logic flow is sequential, processed in order, and cannot be bypassed. -* Business logic includes limits and controls to detect and prevent automated attacks, such as continuous small funds transfers or adding a million friends one at a time. -* High-value business logic flows have considered abuse cases and malicious actors, and have protections against spoofing, tampering, information disclosure, and elevation of privilege attacks. +* A entrada recebida pela aplicação corresponde às expectativas de negócios ou funcionais. +* O fluxo da lógica de negócios é sequencial, processado em ordem e não pode ser burlado (bypassed). +* A lógica de negócios inclui limites e controles para detectar e prevenir ataques automatizados, como transferências contínuas de pequenos fundos ou a adição de um milhão de amigos, um de cada vez. +* Fluxos de lógica de negócios de alto valor consideraram casos de abuso e atores mal-intencionados, e possuem proteções contra ataques de falsificação (spoofing), adulteração (tampering), divulgação de informações e elevação de privilégios. -## V2.1 Validation and Business Logic Documentation +## V2.1 Documentação de Validação e Lógica de Negócios -Validation and business logic documentation should clearly define business logic limits, validation rules, and contextual consistency of combined data items, so it is clear what needs to be implemented in the application. +A documentação da lógica de negócios e da validação deve definir claramente os limites da lógica de negócios, regras de validação e consistência contextual de itens de dados combinados, para que fique claro o que precisa ser implementado na aplicação. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **2.1.1** | Verify that the application's documentation defines input validation rules for how to check the validity of data items against an expected structure. This could be common data formats such as credit card numbers, email addresses, telephone numbers, or it could be an internal data format. | 1 | -| **2.1.2** | Verify that the application's documentation defines how to validate the logical and contextual consistency of combined data items, such as checking that suburb and ZIP code match. | 2 | -| **2.1.3** | Verify that expectations for business logic limits and validations are documented, including both per-user and globally across the application. | 2 | +| **2.1.1** | Verifique se a documentação da aplicação define regras de validação de entrada para saber como verificar a validade de itens de dados em relação a uma estrutura esperada. Pode ser formatos de dados comuns, como números de cartão de crédito, endereços de e-mail, números de telefone, ou pode ser um formato de dados interno. | 1 | +| **2.1.2** | Verifique se a documentação da aplicação define como validar a consistência lógica e contextual de itens de dados combinados, como verificar se o bairro e o CEP (ZIP code) correspondem. | 2 | +| **2.1.3** | Verifique se as expectativas em relação aos limites da lógica de negócios e às validações estão documentadas, incluindo tanto as restrições por usuário quanto as aplicadas globalmente em toda a aplicação. | 2 | -## V2.2 Input Validation +## V2.2 Validação de Entrada -Effective input validation controls enforce business or functional expectations around the type of data the application expects to receive. This ensures good data quality and reduces the attack surface. However, it does not remove or replace the need to use correct encoding, parameterization, or sanitization when using the data in another component or for presenting it for output. +Controles eficazes de validação de entrada aplicam expectativas de negócios ou funcionais em torno do tipo de dado que a aplicação espera receber. Isso garante boa qualidade de dados e reduz a superfície de ataque. No entanto, isso não remove ou substitui a necessidade de usar codificação, parametrização ou sanitização corretas ao usar os dados em outro componente ou ao apresentá-los na saída. -In this context, "input" could come from a wide variety of sources, including HTML form fields, REST requests, URL parameters, HTTP header fields, cookies, files on disk, databases, and external APIs. +Neste contexto, "entrada" pode vir de uma ampla variedade de fontes, incluindo campos de formulário HTML, requisições REST, parâmetros de URL, campos de cabeçalho HTTP, cookies, arquivos no disco, bancos de dados e APIs externas. -A business logic control might check that a particular input is a number less than 100. A functional expectation might check that a number is below a certain threshold, as that number controls how many times a particular loop will take place, and a high number could lead to excessive processing and a potential denial of service condition. +Um controle da lógica de negócios pode verificar se uma entrada específica é um número menor que 100. Uma expectativa funcional pode verificar se um número está abaixo de um determinado limite, já que esse número controla quantas vezes um determinado loop ocorrerá, e um número alto pode levar a processamento excessivo e uma possível condição de negação de serviço (Denial of Service). -While schema validation is not explicitly mandated, it may be the most effective mechanism for full validation coverage of HTTP APIs or other interfaces that use JSON or XML. +Embora a validação de esquema não seja explicitamente obrigatória, ela pode ser o mecanismo mais eficaz para cobertura total de validação de APIs HTTP ou outras interfaces que usam JSON ou XML. -Please note the following points on Schema Validation: +Por favor, observe os seguintes pontos sobre Validação de Esquema (Schema Validation): -* The "published version" of the JSON Schema validation specification is considered production-ready, but not strictly speaking "stable." When using JSON Schema validation, ensure there are no gaps with the guidance in the requirements below. -* Any JSON Schema validation libraries in use should also be monitored and updated if necessary once the standard is formalized. -* DTD validation should not be used, and framework DTD evaluation should be disabled, to avoid issues with XXE attacks against DTDs. +* A "versão publicada" da especificação de validação do JSON Schema é considerada pronta para produção, mas não é estritamente falando "estável". Ao usar a validação do JSON Schema, garanta que não haja lacunas com a orientação nos requisitos abaixo. +* Quaisquer bibliotecas de validação JSON Schema em uso também devem ser monitoradas e atualizadas se necessário assim que o padrão for formalizado. +* A validação de DTD não deve ser usada, e a avaliação de DTD no framework deve ser desativada, para evitar problemas com ataques XXE contra DTDs. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **2.2.1** | Verify that input is validated to enforce business or functional expectations for that input. This should either use positive validation against an allow list of values, patterns, and ranges, or be based on comparing the input to an expected structure and logical limits according to predefined rules. For L1, this can focus on input which is used to make specific business or security decisions. For L2 and up, this should apply to all input. | 1 | -| **2.2.2** | Verify that the application is designed to enforce input validation at a trusted service layer. While client-side validation improves usability and should be encouraged, it must not be relied upon as a security control. | 1 | -| **2.2.3** | Verify that the application ensures that combinations of related data items are reasonable according to the pre-defined rules. | 2 | +| **2.2.1** | Verifique se a entrada é validada para impor expectativas funcionais ou de negócios para aquela entrada. Isso deve usar validação positiva em relação a uma lista de permissões (allowlist) de valores, padrões e intervalos, ou ser baseado na comparação da entrada com uma estrutura esperada e limites lógicos de acordo com regras predefinidas. Para L1, o foco pode ser na entrada que é usada para tomar decisões específicas de negócios ou segurança. Para L2 e superior, isso deve se aplicar a todas as entradas. | 1 | +| **2.2.2** | Verifique se a aplicação é projetada para aplicar a validação de entrada em uma camada de serviço confiável. Embora a validação no lado do cliente (client-side validation) melhore a usabilidade e deva ser incentivada, não se deve confiar nela como um controle de segurança. | 1 | +| **2.2.3** | Verifique se a aplicação garante que combinações de itens de dados relacionados sejam razoáveis de acordo com as regras predefinidas. | 2 | -## V2.3 Business Logic Security +## V2.3 Segurança da Lógica de Negócios -This section considers key requirements to ensure that the application enforces business logic processes in the correct way and is not vulnerable to attacks that exploit the logic and flow of the application. +Esta seção considera os principais requisitos para garantir que a aplicação imponha os processos de lógica de negócios da maneira correta e não seja vulnerável a ataques que explorem a lógica e o fluxo da aplicação. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **2.3.1** | Verify that the application will only process business logic flows for the same user in the expected sequential step order and without skipping steps. | 1 | -| **2.3.2** | Verify that business logic limits are implemented per the application's documentation to avoid business logic flaws being exploited. | 2 | -| **2.3.3** | Verify that transactions are being used at the business logic level such that either a business logic operation succeeds in its entirety or it is rolled back to the previous correct state. | 2 | -| **2.3.4** | Verify that business logic level locking mechanisms are used to ensure that limited quantity resources (such as theater seats or delivery slots) cannot be double-booked by manipulating the application's logic. | 2 | -| **2.3.5** | Verify that high-value business logic flows require multi-user approval to prevent unauthorized or accidental actions. This could include but is not limited to large monetary transfers, contract approvals, access to classified information, or safety overrides in manufacturing. | 3 | +| **2.3.1** | Verifique se a aplicação processará fluxos da lógica de negócios para o mesmo usuário apenas na ordem sequencial de etapas esperada e sem pular etapas. | 1 | +| **2.3.2** | Verifique se os limites da lógica de negócios são implementados conforme a documentação da aplicação para evitar que falhas da lógica de negócios sejam exploradas. | 2 | +| **2.3.3** | Verifique se as transações estão sendo usadas no nível da lógica de negócios, de tal forma que uma operação da lógica de negócios tenha sucesso na sua totalidade ou seja revertida (rolled back) para o estado correto anterior. | 2 | +| **2.3.4** | Verifique se mecanismos de bloqueio (locking) no nível da lógica de negócios são usados para garantir que recursos de quantidade limitada (como assentos de teatro ou horários de entrega) não possam ser reservados duplamente pela manipulação da lógica da aplicação. | 2 | +| **2.3.5** | Verifique se fluxos de lógica de negócios de alto valor exigem aprovação multiusuário para evitar ações não autorizadas ou acidentais. Isso pode incluir, mas não se limita a, grandes transferências financeiras, aprovações de contratos, acesso a informações confidenciais ou anulações de segurança (safety overrides) na manufatura. | 3 | -## V2.4 Anti-automation +## V2.4 Antiautomação -This section includes anti-automation controls to ensure that human-like interactions are required and excessive automated requests are prevented. +Esta seção inclui controles de antiautomação para garantir que interações semelhantes a ações humanas sejam necessárias e que solicitações automatizadas excessivas sejam evitadas. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **2.4.1** | Verify that anti-automation controls are in place to protect against excessive calls to application functions that could lead to data exfiltration, garbage-data creation, quota exhaustion, rate-limit breaches, denial-of-service, or overuse of costly resources. | 2 | -| **2.4.2** | Verify that business logic flows require realistic human timing, preventing excessively rapid transaction submissions. | 3 | +| **2.4.1** | Verifique se há controles de antiautomação em vigor para proteger contra chamadas excessivas a funções da aplicação que podem levar a exfiltração de dados, criação de dados lixo (garbage-data), esgotamento de cotas, violações de limite de taxa (rate-limit), negação de serviço ou uso excessivo de recursos caros. | 2 | +| **2.4.2** | Verifique se os fluxos da lógica de negócios requerem temporização humana realista, evitando envios de transações excessivamente rápidos. | 3 | -## References +## Referências -For more information, see also: +Para mais informações, veja também: * [OWASP Web Security Testing Guide: Input Validation Testing](https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/07-Input_Validation_Testing/README.html) * [OWASP Web Security Testing Guide: Business Logic Testing](https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/10-Business_Logic_Testing/README) * Anti-automation can be achieved in many ways, including the use of the [OWASP Automated Threats to Web Applications](https://owasp.org/www-project-automated-threats-to-web-applications/) * [OWASP Input Validation Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html) -* [JSON Schema](https://json-schema.org/specification.html) +* [JSON Schema](https://json-schema.org/specification.html) \ No newline at end of file diff --git a/5.0/pt/0x12-V3-Web-Frontend-Security.md b/5.0/pt/0x12-V3-Web-Frontend-Security.md index 3d94e02905..5aea837add 100644 --- a/5.0/pt/0x12-V3-Web-Frontend-Security.md +++ b/5.0/pt/0x12-V3-Web-Frontend-Security.md @@ -1,100 +1,100 @@ -# V3 Web Frontend Security +# V3 Segurança de Frontend Web -## Control Objective +## Objetivo de Controle -This category focuses on requirements designed to protect against attacks executed via a web frontend. These requirements do not apply to machine-to-machine solutions. +Esta categoria concentra-se em requisitos projetados para proteger contra ataques executados via um frontend web. Estes requisitos não se aplicam a soluções máquina a máquina (machine-to-machine). -## V3.1 Web Frontend Security Documentation +## V3.1 Documentação de Segurança de Frontend Web -This section outlines the browser security features that should be specified in the application's documentation. +Esta seção descreve os recursos de segurança do navegador que devem ser especificados na documentação da aplicação. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **3.1.1** | Verify that application documentation states the expected security features that browsers using the application must support (such as HTTPS, HTTP Strict Transport Security (HSTS), Content Security Policy (CSP), and other relevant HTTP security mechanisms). It must also define how the application must behave when some of these features are not available (such as warning the user or blocking access). | 3 | +| **3.1.1** | Verifique se a documentação da aplicação declara os recursos de segurança esperados que os navegadores que usam a aplicação devem suportar (como HTTPS, HTTP Strict Transport Security (HSTS), Content Security Policy (CSP) e outros mecanismos de segurança HTTP relevantes). Deve também definir como a aplicação deve se comportar quando alguns desses recursos não estiverem disponíveis (como avisar o usuário ou bloquear o acesso). | 3 | -## V3.2 Unintended Content Interpretation +## V3.2 Interpretação Não Intencional de Conteúdo -Rendering content or functionality in an incorrect context can result in malicious content being executed or displayed. +Renderizar conteúdo ou funcionalidade em um contexto incorreto pode resultar na execução ou exibição de conteúdo malicioso. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **3.2.1** | Verify that security controls are in place to prevent browsers from rendering content or functionality in HTTP responses in an incorrect context (e.g., when an API, a user-uploaded file or other resource is requested directly). Possible controls could include: not serving the content unless HTTP request header fields (such as Sec-Fetch-\*) indicate it is the correct context, using the sandbox directive of the Content-Security-Policy header field or using the attachment disposition type in the Content-Disposition header field. | 1 | -| **3.2.2** | Verify that content intended to be displayed as text, rather than rendered as HTML, is handled using safe rendering functions (such as createTextNode or textContent) to prevent unintended execution of content such as HTML or JavaScript. | 1 | -| **3.2.3** | Verify that the application avoids DOM clobbering when using client-side JavaScript by employing explicit variable declarations, performing strict type checking, avoiding storing global variables on the document object, and implementing namespace isolation. | 3 | +| **3.2.1** | Verifique se há controles de segurança em vigor para evitar que navegadores renderizem conteúdo ou funcionalidades de respostas HTTP em um contexto incorreto (por exemplo, quando uma API, um arquivo enviado pelo usuário ou outro recurso é solicitado diretamente). Possíveis controles poderiam incluir: não servir o conteúdo a menos que campos de cabeçalho da requisição HTTP (como Sec-Fetch-\*) indiquem que é o contexto correto, usar a diretiva sandbox do campo de cabeçalho Content-Security-Policy ou usar o tipo de disposição attachment no campo de cabeçalho Content-Disposition. | 1 | +| **3.2.2** | Verifique se o conteúdo que deve ser exibido como texto, e não renderizado como HTML, é processado usando funções de renderização seguras (como createTextNode ou textContent) para evitar a execução não intencional de conteúdo como HTML ou JavaScript. | 1 | +| **3.2.3** | Verifique se a aplicação evita a sobrescrita do DOM (DOM clobbering) ao usar JavaScript no lado do cliente (client-side), empregando declarações explícitas de variáveis, realizando verificação estrita de tipo, evitando armazenar variáveis globais no objeto document e implementando isolamento de namespace. | 3 | -## V3.3 Cookie Setup +## V3.3 Configuração de Cookies -This section outlines requirements for securely configuring sensitive cookies to provide a higher level of assurance that they were created by the application itself and to prevent their contents from leaking or being inappropriately modified. +Esta seção descreve os requisitos para configurar cookies sensíveis com segurança, a fim de fornecer um maior nível de garantia de que foram criados pela própria aplicação e para evitar que seus conteúdos vazem ou sejam modificados inadequadamente. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **3.3.1** | Verify that cookies have the 'Secure' attribute set, and if the '\__Host-' prefix is not used for the cookie name, the '__Secure-' prefix must be used for the cookie name. | 1 | -| **3.3.2** | Verify that each cookie's 'SameSite' attribute value is set according to the purpose of the cookie, to limit exposure to user interface redress attacks and browser-based request forgery attacks, commonly known as cross-site request forgery (CSRF). | 2 | -| **3.3.3** | Verify that cookies have the '__Host-' prefix for the cookie name unless they are explicitly designed to be shared with other hosts. | 2 | -| **3.3.4** | Verify that if the value of a cookie is not meant to be accessible to client-side scripts (such as a session token), the cookie must have the 'HttpOnly' attribute set and the same value (e. g. session token) must only be transferred to the client via the 'Set-Cookie' header field. | 2 | -| **3.3.5** | Verify that when the application writes a cookie, the cookie name and value length combined are not over 4096 bytes. Overly large cookies will not be stored by the browser and therefore not sent with requests, preventing the user from using application functionality which relies on that cookie. | 3 | +| **3.3.1** | Verifique se os cookies possuem o atributo 'Secure' definido, e caso o prefixo '\__Host-' não seja usado no nome do cookie, o prefixo '__Secure-' deve ser usado para o nome do cookie. | 1 | +| **3.3.2** | Verifique se o valor do atributo 'SameSite' de cada cookie é configurado de acordo com o propósito do cookie, para limitar a exposição a ataques de distorção de interface de usuário (user interface redress) e ataques de falsificação de requisição baseados em navegador, comumente conhecidos como falsificação de requisição entre sites (Cross-Site Request Forgery - CSRF). | 2 | +| **3.3.3** | Verifique se os cookies possuem o prefixo '__Host-' para o nome do cookie, a menos que sejam explicitamente projetados para serem compartilhados com outros hosts. | 2 | +| **3.3.4** | Verifique se o valor de um cookie não deve ser acessível a scripts do lado do cliente (como um token de sessão), o cookie deve ter o atributo 'HttpOnly' definido e o mesmo valor (ex. token de sessão) deve ser transferido ao cliente apenas através do campo de cabeçalho 'Set-Cookie'. | 2 | +| **3.3.5** | Verifique se quando a aplicação grava um cookie, o comprimento combinado do nome e do valor do cookie não ultrapassa 4096 bytes. Cookies excessivamente grandes não serão armazenados pelo navegador e, portanto, não serão enviados com requisições, impedindo o usuário de utilizar as funcionalidades da aplicação que dependem desse cookie. | 3 | -## V3.4 Browser Security Mechanism Headers +## V3.4 Cabeçalhos de Mecanismos de Segurança do Navegador -This section describes which security headers should be set on HTTP responses to enable browser security features and restrictions when handling responses from the application. +Esta seção descreve quais cabeçalhos de segurança devem ser definidos nas respostas HTTP para habilitar os recursos e as restrições de segurança do navegador ao processar as respostas da aplicação. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **3.4.1** | Verify that a Strict-Transport-Security header field is included on all responses to enforce an HTTP Strict Transport Security (HSTS) policy. A maximum age of at least 1 year must be defined, and for L2 and up, the policy must apply to all subdomains as well. | 1 | -| **3.4.2** | Verify that the Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin header field is a fixed value by the application, or if the Origin HTTP request header field value is used, it is validated against an allowlist of trusted origins. When 'Access-Control-Allow-Origin: *' needs to be used, verify that the response does not include any sensitive information. | 1 | -| **3.4.3** | Verify that HTTP responses include a Content-Security-Policy response header field which defines directives to ensure the browser only loads and executes trusted content or resources, in order to limit execution of malicious JavaScript. As a minimum, a global policy must be used which includes the directives object-src 'none' and base-uri 'none' and defines either an allowlist or uses nonces or hashes. For an L3 application, a per-response policy with nonces or hashes must be defined. | 2 | -| **3.4.4** | Verify that all HTTP responses contain an 'X-Content-Type-Options: nosniff' header field. This instructs browsers not to use content sniffing and MIME type guessing for the given response, and to require the response's Content-Type header field value to match the destination resource. For example, the response to a request for a style is only accepted if the response's Content-Type is 'text/css'. This also enables the use of the Cross-Origin Read Blocking (CORB) functionality by the browser. | 2 | -| **3.4.5** | Verify that the application sets a referrer policy to prevent leakage of technically sensitive data to third-party services via the 'Referer' HTTP request header field. This can be done using the Referrer-Policy HTTP response header field or via HTML element attributes. Sensitive data could include path and query data in the URL, and for internal non-public applications also the hostname. | 2 | -| **3.4.6** | Verify that the web application uses the frame-ancestors directive of the Content-Security-Policy header field for every HTTP response to ensure that it cannot be embedded by default and that embedding of specific resources is allowed only when necessary. Note that the X-Frame-Options header field, although supported by browsers, is obsolete and may not be relied upon. | 2 | -| **3.4.7** | Verify that the Content-Security-Policy header field specifies a location to report violations. | 3 | -| **3.4.8** | Verify that all HTTP responses that initiate a document rendering (such as responses with Content-Type text/html), include the Cross‑Origin‑Opener‑Policy header field with the same-origin directive or the same-origin-allow-popups directive as required. This prevents attacks that abuse shared access to Window objects, such as tabnabbing and frame counting. | 3 | +| **3.4.1** | Verifique se o campo de cabeçalho Strict-Transport-Security está incluído em todas as respostas para forçar uma política HTTP Strict Transport Security (HSTS). A validade máxima (maximum age) de pelo menos 1 ano deve ser definida e, para L2 e superior, a política também deve se aplicar a todos os subdomínios. | 1 | +| **3.4.2** | Verifique se o campo de cabeçalho Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin possui um valor fixo atribuído pela aplicação ou, se o valor do campo de cabeçalho Origin da requisição HTTP for usado, ele é validado com base em uma lista de permissões (allowlist) de origens confiáveis. Quando 'Access-Control-Allow-Origin: *' precisar ser usado, verifique se a resposta não inclui informações sensíveis. | 1 | +| **3.4.3** | Verifique se as respostas HTTP incluem um campo de cabeçalho de resposta Content-Security-Policy que define diretivas para garantir que o navegador apenas carregue e execute conteúdos ou recursos confiáveis, a fim de limitar a execução de JavaScript malicioso. Como mínimo, uma política global deve ser usada, a qual inclui as diretivas object-src 'none' e base-uri 'none', e define uma lista de permissões ou usa nonces ou hashes. Para uma aplicação L3, deve ser definida uma política por resposta com nonces ou hashes. | 2 | +| **3.4.4** | Verifique se todas as respostas HTTP contêm um campo de cabeçalho 'X-Content-Type-Options: nosniff'. Isso instrui os navegadores a não utilizarem a adivinhação do tipo MIME (content sniffing) para a resposta dada, e exige que o valor do campo de cabeçalho Content-Type da resposta corresponda ao recurso de destino. Por exemplo, a resposta para a requisição de um estilo só é aceita se o Content-Type da resposta for 'text/css'. Isso também permite o uso da funcionalidade Cross-Origin Read Blocking (CORB) pelo navegador. | 2 | +| **3.4.5** | Verifique se a aplicação define uma política de referência (referrer policy) para evitar o vazamento de dados tecnicamente sensíveis para serviços de terceiros através do campo de cabeçalho HTTP da requisição 'Referer'. Isso pode ser feito usando o campo de cabeçalho de resposta HTTP Referrer-Policy ou por meio de atributos de elemento HTML. Dados sensíveis podem incluir caminho e dados de consulta na URL e, para aplicações internas não públicas, o nome do host (hostname) também. | 2 | +| **3.4.6** | Verifique se a aplicação web usa a diretiva frame-ancestors do campo de cabeçalho Content-Security-Policy para toda resposta HTTP para garantir que ela não possa ser incorporada (embedded) por padrão, e que a incorporação de recursos específicos seja permitida apenas quando necessário. Note que o campo de cabeçalho X-Frame-Options, embora suportado por navegadores, está obsoleto e não deve ser confiado. | 2 | +| **3.4.7** | Verifique se o campo de cabeçalho Content-Security-Policy especifica um local para relatar violações. | 3 | +| **3.4.8** | Verifique se todas as respostas HTTP que iniciam a renderização de um documento (como respostas com Content-Type text/html) incluem o campo de cabeçalho Cross‑Origin‑Opener‑Policy com a diretiva same-origin ou a diretiva same-origin-allow-popups, conforme exigido. Isso evita ataques que abusam do acesso compartilhado a objetos Window, como tabnabbing e contagem de frames (frame counting). | 3 | -## V3.5 Browser Origin Separation +## V3.5 Separação de Origem no Navegador -When accepting a request to sensitive functionality on the server side, the application needs to ensure the request is initiated by the application itself or by a trusted party and has not been forged by an attacker. +Ao aceitar uma solicitação de funcionalidade sensível no lado do servidor, a aplicação precisa garantir que a solicitação seja iniciada pela própria aplicação ou por uma parte confiável e não tenha sido forjada por um atacante. -Sensitive functionality in this context could include accepting form posts for authenticated and non-authenticated users (such as an authentication request), state-changing operations, or resource-demanding functionality (such as data export). +Funcionalidades sensíveis neste contexto podem incluir o recebimento de posts de formulários para usuários autenticados e não autenticados (como uma solicitação de autenticação), operações que mudam o estado (state-changing) ou funcionalidades que demandam recursos (como exportação de dados). -The key protections here are browser security policies like Same Origin Policy for JavaScript and also SameSite logic for cookies. Another common protection is the CORS preflight mechanism. This mechanism will be critical for endpoints designed to be called from a different origin, but it can also be a useful request forgery prevention mechanism for endpoints which are not designed to be called from a different origin. +As principais proteções aqui são as políticas de segurança do navegador, como a Same Origin Policy (Política de Mesma Origem) para JavaScript e também a lógica do SameSite para cookies. Outra proteção comum é o mecanismo de CORS preflight. Esse mecanismo será fundamental para os endpoints projetados para serem chamados de uma origem diferente, mas também pode ser um mecanismo útil de prevenção contra falsificação de solicitações para endpoints que não foram projetados para serem chamados de uma origem diferente. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **3.5.1** | Verify that, if the application does not rely on the CORS preflight mechanism to prevent disallowed cross-origin requests to use sensitive functionality, these requests are validated to ensure they originate from the application itself. This may be done by using and validating anti-forgery tokens or requiring extra HTTP header fields that are not CORS-safelisted request-header fields. This is to defend against browser-based request forgery attacks, commonly known as cross-site request forgery (CSRF). | 1 | -| **3.5.2** | Verify that, if the application relies on the CORS preflight mechanism to prevent disallowed cross-origin use of sensitive functionality, it is not possible to call the functionality with a request which does not trigger a CORS-preflight request. This may require checking the values of the 'Origin' and 'Content-Type' request header fields or using an extra header field that is not a CORS-safelisted header-field. | 1 | -| **3.5.3** | Verify that HTTP requests to sensitive functionality use appropriate HTTP methods such as POST, PUT, PATCH, or DELETE, and not methods defined by the HTTP specification as "safe" such as HEAD, OPTIONS, or GET. Alternatively, strict validation of the Sec-Fetch-* request header fields can be used to ensure that the request did not originate from an inappropriate cross-origin call, a navigation request, or a resource load (such as an image source) where this is not expected. | 1 | -| **3.5.4** | Verify that separate applications are hosted on different hostnames to leverage the restrictions provided by same-origin policy, including how documents or scripts loaded by one origin can interact with resources from another origin and hostname-based restrictions on cookies. | 2 | -| **3.5.5** | Verify that messages received by the postMessage interface are discarded if the origin of the message is not trusted, or if the syntax of the message is invalid. | 2 | -| **3.5.6** | Verify that JSONP functionality is not enabled anywhere across the application to avoid Cross-Site Script Inclusion (XSSI) attacks. | 3 | -| **3.5.7** | Verify that data requiring authorization is not included in script resource responses, like JavaScript files, to prevent Cross-Site Script Inclusion (XSSI) attacks. | 3 | -| **3.5.8** | Verify that authenticated resources (such as images, videos, scripts, and other documents) can be loaded or embedded on behalf of the user only when intended. This can be accomplished by strict validation of the Sec-Fetch-* HTTP request header fields to ensure that the request did not originate from an inappropriate cross-origin call, or by setting a restrictive Cross-Origin-Resource-Policy HTTP response header field to instruct the browser to block returned content. | 3 | +| **3.5.1** | Verifique se, caso a aplicação não dependa do mecanismo de CORS preflight para impedir que requisições cross-origin não permitidas usem funcionalidades sensíveis, essas requisições sejam validadas para garantir que sejam originadas na própria aplicação. Isso pode ser feito usando e validando tokens antifalsificação ou exigindo campos de cabeçalho HTTP adicionais que não sejam campos de cabeçalho listados como seguros (CORS-safelisted). O objetivo é defender contra ataques de falsificação de solicitações baseadas no navegador, conhecidos como falsificação de solicitação entre sites (Cross-Site Request Forgery - CSRF). | 1 | +| **3.5.2** | Verifique se, caso a aplicação dependa do mecanismo de CORS preflight para evitar o uso cross-origin não permitido de funcionalidades sensíveis, não seja possível chamar a funcionalidade com uma solicitação que não acione uma requisição de CORS-preflight. Isso pode exigir a verificação dos valores dos campos de cabeçalho de requisição 'Origin' e 'Content-Type' ou o uso de um campo de cabeçalho extra que não seja CORS-safelisted. | 1 | +| **3.5.3** | Verifique se as solicitações HTTP a funcionalidades sensíveis usam métodos HTTP apropriados como POST, PUT, PATCH ou DELETE, e não métodos definidos pela especificação HTTP como "seguros" (safe), como HEAD, OPTIONS ou GET. Alternativamente, uma validação estrita dos campos de cabeçalho de requisição Sec-Fetch-* pode ser usada para garantir que a solicitação não tenha se originado de uma chamada cross-origin inadequada, de uma solicitação de navegação ou do carregamento de um recurso (como fonte de imagem) onde isso não é esperado. | 1 | +| **3.5.4** | Verifique se as aplicações distintas estão hospedadas em hostnames diferentes para aproveitar as restrições fornecidas pela política de mesma origem (same-origin policy), incluindo a forma como os documentos ou scripts carregados por uma origem podem interagir com os recursos de outra origem e as restrições baseadas no hostname dos cookies. | 2 | +| **3.5.5** | Verifique se as mensagens recebidas pela interface postMessage são descartadas caso a origem da mensagem não seja confiável, ou se a sintaxe da mensagem for inválida. | 2 | +| **3.5.6** | Verifique se a funcionalidade JSONP não está habilitada em nenhuma parte da aplicação para evitar ataques de Inclusão de Script Entre Sites (Cross-Site Script Inclusion - XSSI). | 3 | +| **3.5.7** | Verifique se os dados que requerem autorização não estão incluídos em respostas de recursos de script, como arquivos JavaScript, para evitar ataques de Inclusão de Script Entre Sites (Cross-Site Script Inclusion - XSSI). | 3 | +| **3.5.8** | Verifique se os recursos autenticados (como imagens, vídeos, scripts e outros documentos) podem ser carregados ou incorporados (embedded) em nome do usuário apenas quando pretendido. Isso pode ser alcançado através da validação estrita dos campos de cabeçalho de requisição HTTP Sec-Fetch-* para garantir que a requisição não se originou de uma chamada cross-origin inapropriada, ou através da definição de um campo de cabeçalho restritivo de resposta HTTP Cross-Origin-Resource-Policy para instruir o navegador a bloquear o conteúdo retornado. | 3 | -## V3.6 External Resource Integrity +## V3.6 Integridade de Recursos Externos -This section provides guidance for the safe hosting of content on third-party sites. +Esta seção fornece orientações para a hospedagem segura de conteúdo em sites de terceiros. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **3.6.1** | Verify that client-side assets, such as JavaScript libraries, CSS, or web fonts, are only hosted externally (e.g., on a Content Delivery Network) if the resource is static and versioned and Subresource Integrity (SRI) is used to validate the integrity of the asset. If this is not possible, there should be a documented security decision to justify this for each resource. | 3 | +| **3.6.1** | Verifique se ativos do lado do cliente (client-side assets), como bibliotecas JavaScript, CSS ou fontes da web (web fonts), são hospedados externamente (ex., em uma Content Delivery Network - CDN) apenas se o recurso for estático e versionado, e se a Integridade de Sub-recurso (Subresource Integrity - SRI) for usada para validar a integridade do ativo. Se isso não for possível, deve haver uma decisão de segurança documentada para justificar isso para cada recurso. | 3 | -## V3.7 Other Browser Security Considerations +## V3.7 Outras Considerações de Segurança do Navegador -This section includes various other security controls and modern browser security features required for client-side browser security. +Esta seção inclui vários outros controles de segurança e recursos de segurança de navegadores modernos exigidos para a segurança do navegador do lado do cliente (client-side). -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **3.7.1** | Verify that the application only uses client-side technologies which are still supported and considered secure. Examples of technologies which do not meet this requirement include NSAPI plugins, Flash, Shockwave, ActiveX, Silverlight, NACL, or client-side Java applets. | 2 | -| **3.7.2** | Verify that the application will only automatically redirect the user to a different hostname or domain (which is not controlled by the application) where the destination appears on an allowlist. | 2 | -| **3.7.3** | Verify that the application shows a notification when the user is being redirected to a URL outside of the application's control, with an option to cancel the navigation. | 3 | -| **3.7.4** | Verify that the application's top-level domain (e.g., site.tld) is added to the public preload list for HTTP Strict Transport Security (HSTS). This ensures that the use of TLS for the application is built directly into the main browsers, rather than relying only on the Strict-Transport-Security response header field. | 3 | -| **3.7.5** | Verify that the application behaves as documented (such as warning the user or blocking access) if the browser used to access the application does not support the expected security features. | 3 | +| **3.7.1** | Verifique se a aplicação usa apenas tecnologias do lado do cliente (client-side) que ainda são suportadas e consideradas seguras. Exemplos de tecnologias que não atendem a este requisito incluem plug-ins NSAPI, Flash, Shockwave, ActiveX, Silverlight, NACL ou miniaplicativos (applets) Java do lado do cliente. | 2 | +| **3.7.2** | Verifique se a aplicação redirecionará automaticamente o usuário para um hostname ou domínio diferente (que não seja controlado pela aplicação) apenas se o destino constar em uma lista de permissões (allowlist). | 2 | +| **3.7.3** | Verifique se a aplicação exibe uma notificação quando o usuário está sendo redirecionado para um URL fora do controle da aplicação, com a opção de cancelar a navegação. | 3 | +| **3.7.4** | Verifique se o domínio de nível superior da aplicação (ex., site.tld) é adicionado à lista pública de pré-carregamento (preload list) para o HTTP Strict Transport Security (HSTS). Isso garante que o uso de TLS para a aplicação seja integrado diretamente aos principais navegadores, em vez de depender apenas do campo de cabeçalho de resposta Strict-Transport-Security. | 3 | +| **3.7.5** | Verifique se a aplicação se comporta conforme o documentado (como avisar o usuário ou bloquear o acesso) caso o navegador usado para acessar a aplicação não suporte os recursos de segurança esperados. | 3 | -## References +## Referências -For more information, see also: +Para mais informações, veja também: * [Set-Cookie __Host- prefix details](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#cookie_prefixes) * [OWASP Content Security Policy Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html) * [OWASP Secure Headers Project](https://owasp.org/www-project-secure-headers/) * [OWASP Cross-Site Request Forgery Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html) * [HSTS Browser Preload List submission form](https://hstspreload.org/) -* [OWASP DOM Clobbering Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/DOM_Clobbering_Prevention_Cheat_Sheet.html) +* [OWASP DOM Clobbering Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/DOM_Clobbering_Prevention_Cheat_Sheet.html) \ No newline at end of file diff --git a/5.0/pt/0x13-V4-API-and-Web-Service.md b/5.0/pt/0x13-V4-API-and-Web-Service.md index 470abc3ef7..f9a36f83ef 100644 --- a/5.0/pt/0x13-V4-API-and-Web-Service.md +++ b/5.0/pt/0x13-V4-API-and-Web-Service.md @@ -1,64 +1,64 @@ -# V4 API and Web Service +# V4 API e Web Service -## Control Objective +## Objetivo de Controle -Several considerations apply specifically to applications that expose APIs for use by web browsers or other consumers (commonly using JSON, XML, or GraphQL). This chapter covers the relevant security configurations and mechanisms that should be applied. +Diversas considerações se aplicam especificamente a aplicações que expõem APIs para uso por navegadores web ou outros consumidores (comumente usando JSON, XML ou GraphQL). Este capítulo abrange as configurações e os mecanismos de segurança relevantes que devem ser aplicados. -Note that authentication, session management, and input validation concerns from other chapters also apply to APIs, so this chapter cannot be taken out of context or tested in isolation. +Note que as preocupações com autenticação, gerenciamento de sessão e validação de entrada de outros capítulos também se aplicam a APIs, portanto, este capítulo não pode ser tirado de contexto ou testado isoladamente. -## V4.1 Generic Web Service Security +## V4.1 Segurança Genérica de Web Service -This section addresses general web service security considerations and, consequently, basic web service hygiene practices. +Esta seção aborda considerações gerais de segurança de web services e, consequentemente, práticas básicas de higiene de web services. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **4.1.1** | Verify that every HTTP response with a message body contains a Content-Type header field that matches the actual content of the response, including the charset parameter to specify safe character encoding (e.g., UTF-8, ISO-8859-1) according to IANA Media Types, such as "text/", "/+xml" and "/xml". | 1 | -| **4.1.2** | Verify that only user-facing endpoints (intended for manual web-browser access) automatically redirect from HTTP to HTTPS, while other services or endpoints do not implement transparent redirects. This is to avoid a situation where a client is erroneously sending unencrypted HTTP requests, but since the requests are being automatically redirected to HTTPS, the leakage of sensitive data goes undiscovered. | 2 | -| **4.1.3** | Verify that any HTTP header field used by the application and set by an intermediary layer, such as a load balancer, a web proxy, or a backend-for-frontend service, cannot be overridden by the end-user. Example headers might include X-Real-IP, X-Forwarded-*, or X-User-ID. | 2 | -| **4.1.4** | Verify that only HTTP methods that are explicitly supported by the application or its API (including OPTIONS during preflight requests) can be used and that unused methods are blocked. | 3 | -| **4.1.5** | Verify that per-message digital signatures are used to provide additional assurance on top of transport protections for requests or transactions which are highly sensitive or which traverse a number of systems. | 3 | +| **4.1.1** | Verifique se toda resposta HTTP com um corpo de mensagem contém um campo de cabeçalho Content-Type que corresponda ao conteúdo real da resposta, incluindo o parâmetro charset para especificar uma codificação de caracteres segura (ex., UTF-8, ISO-8859-1) de acordo com os Tipos de Mídia da IANA, como "text/", "/+xml" e "/xml". | 1 | +| **4.1.2** | Verifique se apenas endpoints voltados ao usuário (destinados ao acesso manual por navegador web) redirecionam automaticamente de HTTP para HTTPS, enquanto outros serviços ou endpoints não implementam redirecionamentos transparentes. Isso serve para evitar uma situação em que um cliente envia erroneamente requisições HTTP não criptografadas, mas como as requisições são redirecionadas automaticamente para HTTPS, o vazamento de dados sensíveis passa despercebido. | 2 | +| **4.1.3** | Verifique se qualquer campo de cabeçalho HTTP usado pela aplicação e definido por uma camada intermediária, como um balanceador de carga, um proxy web ou um serviço backend-for-frontend, não pode ser substituído (overridden) pelo usuário final. Exemplos de cabeçalhos podem incluir X-Real-IP, X-Forwarded-* ou X-User-ID. | 2 | +| **4.1.4** | Verifique se apenas os métodos HTTP explicitamente suportados pela aplicação ou por sua API (incluindo OPTIONS durante requisições preflight) podem ser usados e se os métodos não utilizados estão bloqueados. | 3 | +| **4.1.5** | Verifique se assinaturas digitais por mensagem são usadas para fornecer garantia adicional, além das proteções de transporte, para requisições ou transações que são altamente sensíveis ou que atravessam vários sistemas. | 3 | -## V4.2 HTTP Message Structure Validation +## V4.2 Validação da Estrutura da Mensagem HTTP -This section explains how the structure and header fields of an HTTP message should be validated to prevent attacks such as request smuggling, response splitting, header injection, and denial of service via overly long HTTP messages. +Esta seção explica como a estrutura e os campos de cabeçalho de uma mensagem HTTP devem ser validados para evitar ataques como falsificação de requisição (request smuggling), divisão de resposta (response splitting), injeção de cabeçalho e negação de serviço por meio de mensagens HTTP excessivamente longas. -These requirements are relevant for general HTTP message processing and generation, but are especially important when converting HTTP messages between different HTTP versions. +Esses requisitos são relevantes para o processamento e a geração geral de mensagens HTTP, mas são especialmente importantes ao converter mensagens HTTP entre diferentes versões do HTTP. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **4.2.1** | Verify that all application components (including load balancers, firewalls, and application servers) determine boundaries of incoming HTTP messages using the appropriate mechanism for the HTTP version to prevent HTTP request smuggling. In HTTP/1.x, if a Transfer-Encoding header field is present, the Content-Length header must be ignored per RFC 2616. When using HTTP/2 or HTTP/3, if a Content-Length header field is present, the receiver must ensure that it is consistent with the length of the DATA frames. | 2 | -| **4.2.2** | Verify that when generating HTTP messages, the Content-Length header field does not conflict with the length of the content as determined by the framing of the HTTP protocol, in order to prevent request smuggling attacks. | 3 | -| **4.2.3** | Verify that the application does not send nor accept HTTP/2 or HTTP/3 messages with connection-specific header fields such as Transfer-Encoding to prevent response splitting and header injection attacks. | 3 | -| **4.2.4** | Verify that the application only accepts HTTP/2 and HTTP/3 requests where the header fields and values do not contain any CR (\r), LF (\n), or CRLF (\r\n) sequences, to prevent header injection attacks. | 3 | -| **4.2.5** | Verify that, if the application (backend or frontend) builds and sends requests, it uses validation, sanitization, or other mechanisms to avoid creating URIs (such as for API calls) or HTTP request header fields (such as Authorization or Cookie), which are too long to be accepted by the receiving component. This could cause a denial of service, such as when sending an overly long request (e.g., a long cookie header field), which results in the server always responding with an error status. | 3 | +| **4.2.1** | Verifique se todos os componentes da aplicação (incluindo balanceadores de carga, firewalls e servidores de aplicação) determinam os limites das mensagens HTTP de entrada usando o mecanismo apropriado para a versão do HTTP, a fim de evitar falsificação de requisição HTTP (HTTP request smuggling). No HTTP/1.x, se um campo de cabeçalho Transfer-Encoding estiver presente, o cabeçalho Content-Length deve ser ignorado conforme a RFC 2616. Ao usar HTTP/2 ou HTTP/3, se um campo de cabeçalho Content-Length estiver presente, o receptor deve garantir que seja consistente com o comprimento dos frames DATA. | 2 | +| **4.2.2** | Verifique se, ao gerar mensagens HTTP, o campo de cabeçalho Content-Length não entra em conflito com o comprimento do conteúdo determinado pelo enquadramento (framing) do protocolo HTTP, a fim de evitar ataques de request smuggling. | 3 | +| **4.2.3** | Verifique se a aplicação não envia nem aceita mensagens HTTP/2 ou HTTP/3 com campos de cabeçalho específicos da conexão, como Transfer-Encoding, para evitar ataques de response splitting e injeção de cabeçalho. | 3 | +| **4.2.4** | Verifique se a aplicação aceita apenas requisições HTTP/2 e HTTP/3 onde os campos de cabeçalho e valores não contêm nenhuma sequência CR (\r), LF (\n) ou CRLF (\r\n), para evitar ataques de injeção de cabeçalho. | 3 | +| **4.2.5** | Verifique se, caso a aplicação (backend ou frontend) construa e envie requisições, ela usa validação, sanitização ou outros mecanismos para evitar a criação de URIs (como para chamadas de API) ou campos de cabeçalho de requisição HTTP (como Authorization ou Cookie) que sejam longos demais para serem aceitos pelo componente receptor. Isso poderia causar uma negação de serviço, como ao enviar uma requisição excessivamente longa (ex., um campo de cabeçalho de cookie longo), resultando no servidor sempre respondendo com um status de erro. | 3 | ## V4.3 GraphQL -GraphQL is becoming more common as a way of creating data-rich clients that are not tightly coupled to a variety of backend services. This section covers security considerations for GraphQL. +O GraphQL está se tornando mais comum como uma forma de criar clientes ricos em dados que não são fortemente acoplados a uma variedade de serviços de backend. Esta seção aborda as considerações de segurança para o GraphQL. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **4.3.1** | Verify that a query allowlist, depth limiting, amount limiting, or query cost analysis is used to prevent GraphQL or data layer expression Denial of Service (DoS) as a result of expensive, nested queries. | 2 | -| **4.3.2** | Verify that GraphQL introspection queries are disabled in the production environment unless the GraphQL API is meant to be used by other parties. | 2 | +| **4.3.1** | Verifique se uma lista de permissões (allowlist) de consultas, limitação de profundidade, limitação de quantidade ou análise de custo de consulta é usada para evitar Negação de Serviço (DoS) de expressão na camada de dados ou GraphQL como resultado de consultas aninhadas e custosas. | 2 | +| **4.3.2** | Verifique se as consultas de introspecção do GraphQL estão desabilitadas no ambiente de produção, a menos que a API do GraphQL seja destinada a ser usada por terceiros. | 2 | ## V4.4 WebSocket -WebSocket is a communications protocol that provides a simultaneous two-way communication channel over a single TCP connection. It was standardized by the IETF as RFC 6455 in 2011 and is distinct from HTTP, even though it is designed to work over HTTP ports 443 and 80. +O WebSocket é um protocolo de comunicações que fornece um canal de comunicação bidirecional simultâneo em uma única conexão TCP. Ele foi padronizado pela IETF como RFC 6455 em 2011 e é distinto do HTTP, embora seja projetado para funcionar nas portas HTTP 443 e 80. -This section provides key security requirements to prevent attacks related to communication security and session management that specifically exploit this real-time communication channel. +Esta seção fornece os principais requisitos de segurança para prevenir ataques relacionados à segurança da comunicação e ao gerenciamento de sessão que exploram especificamente esse canal de comunicação em tempo real. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **4.4.1** | Verify that WebSocket over TLS (WSS) is used for all WebSocket connections. | 1 | -| **4.4.2** | Verify that, during the initial HTTP WebSocket handshake, the Origin header field is checked against a list of origins allowed for the application. | 2 | -| **4.4.3** | Verify that, if the application's standard session management cannot be used, dedicated tokens are being used for this, which comply with the relevant Session Management security requirements. | 2 | -| **4.4.4** | Verify that dedicated WebSocket session management tokens are initially obtained or validated through the previously authenticated HTTPS session when transitioning an existing HTTPS session to a WebSocket channel. | 2 | +| **4.4.1** | Verifique se o WebSocket over TLS (WSS) é usado para todas as conexões WebSocket. | 1 | +| **4.4.2** | Verifique se, durante o handshake inicial do WebSocket HTTP, o campo de cabeçalho Origin é verificado em relação a uma lista de origens permitidas para a aplicação. | 2 | +| **4.4.3** | Verifique se, caso o gerenciamento de sessão padrão da aplicação não possa ser usado, tokens dedicados estão sendo usados para isso, os quais cumprem os requisitos de segurança relevantes de Gerenciamento de Sessão. | 2 | +| **4.4.4** | Verifique se os tokens dedicados de gerenciamento de sessão do WebSocket são inicialmente obtidos ou validados por meio da sessão HTTPS previamente autenticada ao fazer a transição de uma sessão HTTPS existente para um canal WebSocket. | 2 | -## References +## Referências -For more information, see also: +Para mais informações, veja também: * [OWASP REST Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html) -* Resources on GraphQL Authorization from [graphql.org](https://graphql.org/learn/authorization/) and [Apollo](https://www.apollographql.com/docs/apollo-server/security/authentication/#authorization-methods). +* Recursos sobre Autorização GraphQL em [graphql.org](https://graphql.org/learn/authorization/) e [Apollo](https://www.apollographql.com/docs/apollo-server/security/authentication/#authorization-methods). * [OWASP Web Security Testing Guide: GraphQL Testing](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/12-API_Testing/01-Testing_GraphQL) -* [OWASP Web Security Testing Guide: Testing WebSockets](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/11-Client-side_Testing/10-Testing_WebSockets) +* [OWASP Web Security Testing Guide: Testing WebSockets](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/11-Client-side_Testing/10-Testing_WebSockets) \ No newline at end of file diff --git a/5.0/pt/0x14-V5-File-Handling.md b/5.0/pt/0x14-V5-File-Handling.md index e8d601cefe..55abdf90cc 100644 --- a/5.0/pt/0x14-V5-File-Handling.md +++ b/5.0/pt/0x14-V5-File-Handling.md @@ -1,54 +1,54 @@ -# V5 File Handling +# V5 Manipulação de Arquivos -## Control Objective +## Objetivo de Controle -The use of files can present a variety of risks to the application, including denial of service, unauthorized access, and storage exhaustion. This chapter includes requirements to address these risks. +O uso de arquivos pode apresentar uma variedade de riscos à aplicação, incluindo negação de serviço, acesso não autorizado e esgotamento de armazenamento. Este capítulo inclui requisitos para abordar esses riscos. -## V5.1 File Handling Documentation +## V5.1 Documentação de Manipulação de Arquivos -This section includes a requirement to document the expected characteristics of files accepted by the application, as a necessary precondition for developing and verifying relevant security checks. +Esta seção inclui um requisito para documentar as características esperadas dos arquivos aceitos pela aplicação, como uma pré-condição necessária para desenvolver e verificar verificações de segurança relevantes. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **5.1.1** | Verify that the documentation defines the permitted file types, expected file extensions, and maximum size (including unpacked size) for each upload feature. Additionally, ensure that the documentation specifies how files are made safe for end-users to download and process, such as how the application behaves when a malicious file is detected. | 2 | +| **5.1.1** | Verifique se a documentação define os tipos de arquivos permitidos, as extensões de arquivo esperadas e o tamanho máximo (incluindo o tamanho descompactado) para cada recurso de upload. Além disso, certifique-se de que a documentação especifique como os arquivos são tornados seguros para que os usuários finais façam download e os processem, como, por exemplo, o comportamento da aplicação quando um arquivo malicioso é detectado. | 2 | -## V5.2 File Upload and Content +## V5.2 Upload de Arquivo e Conteúdo -File upload functionality is a primary source of untrusted files. This section outlines the requirements for ensuring that the presence, volume, or content of these files cannot harm the application. +A funcionalidade de upload de arquivo é uma fonte primária de arquivos não confiáveis. Esta seção descreve os requisitos para garantir que a presença, o volume ou o conteúdo desses arquivos não possam prejudicar a aplicação. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **5.2.1** | Verify that the application will only accept files of a size which it can process without causing a loss of performance or a denial of service attack. | 1 | -| **5.2.2** | Verify that when the application accepts a file, either on its own or within an archive such as a zip file, it checks if the file extension matches an expected file extension and validates that the contents correspond to the type represented by the extension. This includes, but is not limited to, checking the initial 'magic bytes', performing image re-writing, and using specialized libraries for file content validation. For L1, this can focus just on files which are used to make specific business or security decisions. For L2 and up, this must apply to all files being accepted. | 1 | -| **5.2.3** | Verify that the application checks compressed files (e.g., zip, gz, docx, odt) against maximum allowed uncompressed size and against maximum number of files before uncompressing the file. | 2 | -| **5.2.4** | Verify that a file size quota and maximum number of files per user are enforced to ensure that a single user cannot fill up the storage with too many files, or excessively large files. | 3 | -| **5.2.5** | Verify that the application does not allow uploading compressed files containing symlinks unless this is specifically required (in which case it will be necessary to enforce an allowlist of the files that can be symlinked to). | 3 | -| **5.2.6** | Verify that the application rejects uploaded images with a pixel size larger than the maximum allowed, to prevent pixel flood attacks. | 3 | +| **5.2.1** | Verifique se a aplicação aceitará apenas arquivos de um tamanho que possa processar sem causar perda de desempenho ou um ataque de negação de serviço. | 1 | +| **5.2.2** | Verifique se, quando a aplicação aceita um arquivo, seja individualmente ou dentro de um arquivo compactado como um zip, ela verifica se a extensão do arquivo corresponde a uma extensão esperada e valida se o conteúdo corresponde ao tipo representado pela extensão. Isso inclui, mas não se limita a, verificar os 'magic bytes' (bytes mágicos) iniciais, realizar a reescrita de imagem e usar bibliotecas especializadas para validação de conteúdo de arquivo. Para L1, o foco pode ser apenas nos arquivos que são usados para tomar decisões específicas de negócios ou segurança. Para L2 e superior, isso deve se aplicar a todos os arquivos sendo aceitos. | 1 | +| **5.2.3** | Verifique se a aplicação verifica os arquivos compactados (ex., zip, gz, docx, odt) em relação ao tamanho máximo não compactado permitido e em relação ao número máximo de arquivos antes de descompactar o arquivo. | 2 | +| **5.2.4** | Verifique se uma cota de tamanho de arquivo e um número máximo de arquivos por usuário são aplicados para garantir que um único usuário não possa encher o armazenamento com muitos arquivos ou arquivos excessivamente grandes. | 3 | +| **5.2.5** | Verifique se a aplicação não permite o upload de arquivos compactados contendo links simbólicos (symlinks), a menos que isso seja especificamente exigido (nesse caso, será necessário impor uma lista de permissões dos arquivos que podem ser vinculados via symlink). | 3 | +| **5.2.6** | Verifique se a aplicação rejeita imagens enviadas com um tamanho de pixel maior que o máximo permitido, para evitar ataques de inundação de pixels (pixel flood). | 3 | -## V5.3 File Storage +## V5.3 Armazenamento de Arquivos -This section includes requirements to prevent files from being inappropriately executed after upload, to detect dangerous content, and to avoid untrusted data being used to control where files are being stored. +Esta seção inclui requisitos para evitar que arquivos sejam executados indevidamente após o upload, para detectar conteúdo perigoso e para evitar que dados não confiáveis sejam usados para controlar onde os arquivos estão sendo armazenados. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **5.3.1** | Verify that files uploaded or generated by untrusted input and stored in a public folder, are not executed as server-side program code when accessed directly with an HTTP request. | 1 | -| **5.3.2** | Verify that when the application creates file paths for file operations, instead of user-submitted filenames, it uses internally generated or trusted data, or if user-submitted filenames or file metadata must be used, strict validation and sanitization must be applied. This is to protect against path traversal, local or remote file inclusion (LFI, RFI), and server-side request forgery (SSRF) attacks. | 1 | -| **5.3.3** | Verify that server-side file processing, such as file decompression, ignores user-provided path information to prevent vulnerabilities such as zip slip. | 3 | +| **5.3.1** | Verifique se os arquivos carregados ou gerados por entrada não confiável e armazenados em uma pasta pública não são executados como código de programa no lado do servidor quando acessados diretamente por uma requisição HTTP. | 1 | +| **5.3.2** | Verifique se, quando a aplicação cria caminhos de arquivo para operações de arquivo, em vez de usar nomes de arquivo enviados pelo usuário, ela usa dados gerados internamente ou confiáveis. Se os nomes de arquivo enviados pelo usuário ou os metadados do arquivo precisarem ser usados, validação e sanitização estritas devem ser aplicadas. Isso visa proteger contra ataques de path traversal, inclusão de arquivo local ou remoto (LFI, RFI) e falsificação de solicitação do lado do servidor (SSRF). | 1 | +| **5.3.3** | Verifique se o processamento de arquivos no lado do servidor, como a descompactação de arquivos, ignora as informações de caminho fornecidas pelo usuário para evitar vulnerabilidades como zip slip. | 3 | -## V5.4 File Download +## V5.4 Download de Arquivos -This section contains requirements to mitigate risks when serving files to be downloaded, including path traversal and injection attacks. This also includes making sure they don't contain dangerous content. +Esta seção contém requisitos para mitigar riscos ao servir arquivos a serem baixados, incluindo ataques de path traversal e injeção. Isso também inclui certificar-se de que eles não contêm conteúdo perigoso. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **5.4.1** | Verify that the application validates or ignores user-submitted filenames, including in a JSON, JSONP, or URL parameter and specifies a filename in the Content-Disposition header field in the response. | 2 | -| **5.4.2** | Verify that file names served (e.g., in HTTP response header fields or email attachments) are encoded or sanitized (e.g., following RFC 6266) to preserve document structure and prevent injection attacks. | 2 | -| **5.4.3** | Verify that files obtained from untrusted sources are scanned by antivirus scanners to prevent serving of known malicious content. | 2 | +| **5.4.1** | Verifique se a aplicação valida ou ignora os nomes de arquivo enviados pelo usuário, inclusive em um JSON, JSONP ou parâmetro de URL, e especifica um nome de arquivo no campo de cabeçalho Content-Disposition na resposta. | 2 | +| **5.4.2** | Verifique se os nomes de arquivos servidos (por exemplo, em campos de cabeçalho de resposta HTTP ou anexos de e-mail) são codificados ou sanitizados (por exemplo, seguindo a RFC 6266) para preservar a estrutura do documento e prevenir ataques de injeção. | 2 | +| **5.4.3** | Verifique se os arquivos obtidos de fontes não confiáveis são verificados por scanners antivírus para evitar a veiculação de conteúdo malicioso conhecido. | 2 | -## References +## Referências -For more information, see also: +Para mais informações, veja também: * [OWASP File Upload Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html) * [Example of using symlinks for arbitrary file read](https://hackerone.com/reports/1439593) -* [Explanation of "Magic Bytes" from Wikipedia](https://en.wikipedia.org/wiki/List_of_file_signatures) +* [Explanation of "Magic Bytes" from Wikipedia](https://en.wikipedia.org/wiki/List_of_file_signatures) \ No newline at end of file diff --git a/5.0/pt/0x15-V6-Authentication.md b/5.0/pt/0x15-V6-Authentication.md index d9fa0025ad..e21830c142 100644 --- a/5.0/pt/0x15-V6-Authentication.md +++ b/5.0/pt/0x15-V6-Authentication.md @@ -1,159 +1,159 @@ -# V6 Authentication +# V6 Autenticação -## Control Objective +## Objetivo de Controle -Authentication is the process of establishing or confirming the authenticity of an individual or device. It involves verifying claims made by a person or about a device, ensuring resistance to impersonation, and preventing the recovery or interception of passwords. +Autenticação é o processo de estabelecer ou confirmar a autenticidade de um indivíduo ou dispositivo. Envolve a verificação de reivindicações (claims) feitas por uma pessoa ou sobre um dispositivo, garantindo a resistência à falsificação de identidade (impersonation) e evitando a recuperação ou interceptação de senhas. -[NIST SP 800-63](https://pages.nist.gov/800-63-3/) is a modern, evidence-based standard that is valuable for organizations worldwide, but is particularly relevant to US agencies and those interacting with US agencies. +O [NIST SP 800-63](https://pages.nist.gov/800-63-3/) é um padrão moderno, baseado em evidências, que é valioso para organizações em todo o mundo, mas é particularmente relevante para agências dos EUA e para aqueles que interagem com elas. -While many of the requirements in this chapter are based on the second section of the standard (known as NIST SP 800-63B "Digital Identity Guidelines - Authentication and Lifecycle Management"), the chapter focuses on common threats and frequently exploited authentication weaknesses. It does not attempt to comprehensively cover every point in the standard. For cases where full NIST SP 800-63 compliance is necessary, please refer to NIST SP 800-63. +Embora muitos dos requisitos neste capítulo baseiem-se na segunda seção do padrão (conhecido como NIST SP 800-63B "Digital Identity Guidelines - Authentication and Lifecycle Management"), o capítulo foca em ameaças comuns e fraquezas de autenticação frequentemente exploradas. Ele não tenta cobrir de forma abrangente todos os pontos do padrão. Para casos em que a conformidade total com o NIST SP 800-63 for necessária, consulte o NIST SP 800-63. -Additionally, NIST SP 800-63 terminology may sometimes differ, and this chapter often uses more commonly understood terminology to improve clarity. +Além disso, a terminologia do NIST SP 800-63 pode, às vezes, ser diferente, e este capítulo frequentemente usa uma terminologia mais comumente compreendida para melhorar a clareza. -A common feature of more advanced applications is the ability to adapt authentication stages required based on various risk factors. This feature is covered in the "Authorization" chapter, since these mechanisms also need to be considered for authorization decisions. +Um recurso comum de aplicações mais avançadas é a capacidade de adaptar os estágios de autenticação exigidos com base em vários fatores de risco. Esse recurso é abordado no capítulo "Autorização", uma vez que esses mecanismos também precisam ser considerados para decisões de autorização. -## V6.1 Authentication Documentation +## V6.1 Documentação de Autenticação -This section contains requirements detailing the authentication documentation that should be maintained for an application. This is crucial for implementing and assessing how the relevant authentication controls should be configured. +Esta seção contém requisitos que detalham a documentação de autenticação que deve ser mantida para uma aplicação. Isso é crucial para implementar e avaliar como os controles de autenticação relevantes devem ser configurados. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **6.1.1** | Verify that application documentation defines how controls such as rate limiting, anti-automation, and adaptive response, are used to defend against attacks such as credential stuffing and password brute force. The documentation must make clear how these controls are configured and prevent malicious account lockout. | 1 | -| **6.1.2** | Verify that a list of context-specific words is documented in order to prevent their use in passwords. The list could include permutations of organization names, product names, system identifiers, project codenames, department or role names, and similar. | 2 | -| **6.1.3** | Verify that, if the application includes multiple authentication pathways, these are all documented together with the security controls and authentication strength which must be consistently enforced across them. | 2 | +| **6.1.1** | Verifique se a documentação da aplicação define como os controles, como limitação de taxa (rate limiting), antiautomação e resposta adaptativa, são usados para se defender contra ataques como preenchimento de credenciais (credential stuffing) e força bruta de senha. A documentação deve deixar claro como esses controles são configurados e impedir o bloqueio malicioso de contas (account lockout). | 1 | +| **6.1.2** | Verifique se uma lista de palavras específicas do contexto está documentada para impedir o seu uso em senhas. A lista pode incluir permutações de nomes da organização, nomes de produtos, identificadores de sistema, codinomes de projeto, nomes de departamentos ou funções, e similares. | 2 | +| **6.1.3** | Verifique se, caso a aplicação inclua vários caminhos de autenticação, todos estejam documentados juntamente com os controles de segurança e a força de autenticação que devem ser aplicados consistentemente em todos eles. | 2 | -## V6.2 Password Security +## V6.2 Segurança de Senha -Passwords, called "Memorized Secrets" by NIST SP 800-63, include passwords, passphrases, PINs, unlock patterns, and picking the correct kitten or another image element. They are generally considered "something you know" and are often used as a single-factor authentication mechanism. +As senhas, chamadas de "Segredos Memorizados" (Memorized Secrets) pelo NIST SP 800-63, incluem senhas, frases secretas (passphrases), PINs, padrões de desbloqueio e escolher o gatinho correto ou outro elemento de imagem. Geralmente, são consideradas "algo que você sabe" e costumam ser usadas como um mecanismo de autenticação de fator único. -As such, this section contains requirements for making sure that passwords are created and handled securely. Most of the requirements are L1 as they are most important at that level. From L2 onwards, multi-factor authentication mechanisms are required, where passwords may be one of those factors. +Como tal, esta seção contém requisitos para garantir que as senhas sejam criadas e tratadas de forma segura. A maioria dos requisitos é L1, pois eles são mais importantes nesse nível. Do L2 em diante, exigem-se mecanismos de autenticação multifator, onde as senhas podem ser um desses fatores. -The requirements in this section mostly relate to [§ 5.1.1.2](https://pages.nist.gov/800-63-3/sp800-63b.html#memsecretver) of [NIST's Guidance](https://pages.nist.gov/800-63-3/sp800-63b.html). +Os requisitos nesta seção relacionam-se principalmente à [§ 5.1.1.2](https://pages.nist.gov/800-63-3/sp800-63b.html#memsecretver) do [Guia do NIST](https://pages.nist.gov/800-63-3/sp800-63b.html). -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **6.2.1** | Verify that user set passwords are at least 8 characters in length although a minimum of 15 characters is strongly recommended. | 1 | -| **6.2.2** | Verify that users can change their password. | 1 | -| **6.2.3** | Verify that password change functionality requires the user's current and new password. | 1 | -| **6.2.4** | Verify that passwords submitted during account registration or password change are checked against an available set of, at least, the top 3000 passwords which match the application's password policy, e.g. minimum length. | 1 | -| **6.2.5** | Verify that passwords of any composition can be used, without rules limiting the type of characters permitted. There must be no requirement for a minimum number of upper or lower case characters, numbers, or special characters. | 1 | -| **6.2.6** | Verify that password input fields use type=password to mask the entry. Applications may allow the user to temporarily view the entire masked password, or the last typed character of the password. | 1 | -| **6.2.7** | Verify that "paste" functionality, browser password helpers, and external password managers are permitted. | 1 | -| **6.2.8** | Verify that the application verifies the user's password exactly as received from the user, without any modifications such as truncation or case transformation. | 1 | -| **6.2.9** | Verify that passwords of at least 64 characters are permitted. | 2 | -| **6.2.10** | Verify that a user's password stays valid until it is discovered to be compromised or the user rotates it. The application must not require periodic credential rotation. | 2 | -| **6.2.11** | Verify that the documented list of context specific words is used to prevent easy to guess passwords being created. | 2 | -| **6.2.12** | Verify that passwords submitted during account registration or password changes are checked against a set of breached passwords. | 2 | +| **6.2.1** | Verifique se as senhas definidas pelo usuário têm pelo menos 8 caracteres de comprimento, embora um mínimo de 15 caracteres seja fortemente recomendado. | 1 | +| **6.2.2** | Verifique se os usuários podem alterar sua senha. | 1 | +| **6.2.3** | Verifique se a funcionalidade de alteração de senha exige a senha atual e a nova senha do usuário. | 1 | +| **6.2.4** | Verifique se as senhas enviadas durante o registro da conta ou na alteração da senha são verificadas em um conjunto disponível de, pelo menos, as 3000 senhas mais comuns que correspondem à política de senha da aplicação, por exemplo, o comprimento mínimo. | 1 | +| **6.2.5** | Verifique se senhas de qualquer composição podem ser usadas, sem regras que limitem o tipo de caracteres permitidos. Não deve haver requisito para um número mínimo de letras maiúsculas ou minúsculas, números ou caracteres especiais. | 1 | +| **6.2.6** | Verifique se os campos de entrada de senha usam type=password para mascarar a entrada. As aplicações podem permitir que o usuário visualize temporariamente toda a senha mascarada ou o último caractere digitado da senha. | 1 | +| **6.2.7** | Verifique se a funcionalidade de "colar" (paste), ajudantes de senha de navegador e gerenciadores de senha externos são permitidos. | 1 | +| **6.2.8** | Verifique se a aplicação verifica a senha do usuário exatamente como recebida dele, sem nenhuma modificação como truncamento ou transformação de maiúsculas e minúsculas (case transformation). | 1 | +| **6.2.9** | Verifique se senhas de pelo menos 64 caracteres são permitidas. | 2 | +| **6.2.10** | Verifique se a senha de um usuário permanece válida até que seja descoberta como comprometida ou o usuário a troque. A aplicação não deve exigir a rotação periódica de credenciais. | 2 | +| **6.2.11** | Verifique se a lista documentada de palavras específicas do contexto é usada para evitar que senhas fáceis de adivinhar sejam criadas. | 2 | +| **6.2.12** | Verifique se as senhas enviadas durante o registro da conta ou alterações de senha são verificadas em relação a um conjunto de senhas vazadas (breached passwords). | 2 | -## V6.3 General Authentication Security +## V6.3 Segurança Geral de Autenticação -This section contains general requirements for the security of authentication mechanisms as well as setting out the different expectations for levels. L2 applications must force the use of multi-factor authentication (MFA). L3 applications must use hardware-based authentication, performed in an attested and trusted execution environment (TEE). This could include device-bound passkeys, eIDAS Level of Assurance (LoA) High enforced authenticators, authenticators with NIST Authenticator Assurance Level 3 (AAL3) assurance, or an equivalent mechanism. +Esta seção contém requisitos gerais para a segurança dos mecanismos de autenticação, além de estabelecer as diferentes expectativas para os níveis. Aplicações L2 devem forçar o uso de autenticação multifator (MFA). Aplicações L3 devem usar autenticação baseada em hardware, executada em um ambiente de execução atestado e confiável (TEE). Isso pode incluir passkeys vinculadas a dispositivos (device-bound), autenticadores aplicados com Nível de Garantia (LoA) Alto do eIDAS, autenticadores com nível de garantia NIST Authenticator Assurance Level 3 (AAL3) ou um mecanismo equivalente. -While this is a relatively aggressive stance on MFA, it is critical to raise the bar around this to protect users, and any attempt to relax these requirements should be accompanied by a clear plan on how the risks around authentication will be mitigated, taking into account NIST's guidance and research on the topic. +Embora esta seja uma postura relativamente agressiva em relação à MFA, é fundamental elevar o padrão em torno disso para proteger os usuários, e qualquer tentativa de relaxar esses requisitos deve ser acompanhada de um plano claro sobre como os riscos em torno da autenticação serão mitigados, levando em consideração as orientações e pesquisas do NIST sobre o tópico. -Note that at the time of release, NIST SP 800-63 considers email as [not acceptable](https://pages.nist.gov/800-63-FAQ/#q-b11) as an authentication mechanism ([archived copy](https://web.archive.org/web/20250330115328/https://pages.nist.gov/800-63-FAQ/#q-b11)). +Observe que, no momento do lançamento, o NIST SP 800-63 considera o e-mail como um mecanismo de autenticação [inaceitável](https://pages.nist.gov/800-63-FAQ/#q-b11) ([cópia arquivada](https://web.archive.org/web/20250330115328/https://pages.nist.gov/800-63-FAQ/#q-b11)). -The requirements in this section relate to a variety of sections of [NIST's Guidance](https://pages.nist.gov/800-63-3/sp800-63b.html), including: [§ 4.2.1](https://pages.nist.gov/800-63-3/sp800-63b.html#421-permitted-authenticator-types), [§ 4.3.1](https://pages.nist.gov/800-63-3/sp800-63b.html#431-permitted-authenticator-types), [§ 5.2.2](https://pages.nist.gov/800-63-3/sp800-63b.html#522-rate-limiting-throttling), and [§ 6.1.2](https://pages.nist.gov/800-63-3/sp800-63b.html#-612-post-enrollment-binding). +Os requisitos nesta seção se relacionam a uma variedade de seções do [Guia do NIST](https://pages.nist.gov/800-63-3/sp800-63b.html), incluindo: [§ 4.2.1](https://pages.nist.gov/800-63-3/sp800-63b.html#421-permitted-authenticator-types), [§ 4.3.1](https://pages.nist.gov/800-63-3/sp800-63b.html#431-permitted-authenticator-types), [§ 5.2.2](https://pages.nist.gov/800-63-3/sp800-63b.html#522-rate-limiting-throttling) e [§ 6.1.2](https://pages.nist.gov/800-63-3/sp800-63b.html#-612-post-enrollment-binding). -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **6.3.1** | Verify that controls to prevent attacks such as credential stuffing and password brute force are implemented according to the application's security documentation. | 1 | -| **6.3.2** | Verify that default user accounts (e.g., "root", "admin", or "sa") are not present in the application or are disabled. | 1 | -| **6.3.3** | Verify that either a multi-factor authentication mechanism or a combination of single-factor authentication mechanisms, must be used in order to access the application. For L3, one of the factors must be a hardware-based authentication mechanism which provides compromise and impersonation resistance against phishing attacks while verifying the intent to authenticate by requiring a user-initiated action (such as a button press on a FIDO hardware key or a mobile phone). Relaxing any of the considerations in this requirement requires a fully documented rationale and a comprehensive set of mitigating controls. | 2 | -| **6.3.4** | Verify that, if the application includes multiple authentication pathways, there are no undocumented pathways and that security controls and authentication strength are enforced consistently. | 2 | -| **6.3.5** | Verify that users are notified of suspicious authentication attempts (successful or unsuccessful). This may include authentication attempts from an unusual location or client, partially successful authentication (only one of multiple factors), an authentication attempt after a long period of inactivity or a successful authentication after several unsuccessful attempts. | 3 | -| **6.3.6** | Verify that email is not used as either a single-factor or multi-factor authentication mechanism. | 3 | -| **6.3.7** | Verify that users are notified after updates to authentication details, such as credential resets or modification of the username or email address. | 3 | -| **6.3.8** | Verify that valid users cannot be deduced from failed authentication challenges, such as by basing on error messages, HTTP response codes, or different response times. Registration and forgot password functionality must also have this protection. | 3 | +| **6.3.1** | Verifique se os controles para prevenir ataques, como preenchimento de credenciais e força bruta de senha, são implementados de acordo com a documentação de segurança da aplicação. | 1 | +| **6.3.2** | Verifique se contas de usuário padrão (ex., "root", "admin" ou "sa") não estão presentes na aplicação ou estão desativadas. | 1 | +| **6.3.3** | Verifique se um mecanismo de autenticação multifator ou uma combinação de mecanismos de autenticação de fator único deve ser usado para acessar a aplicação. Para o L3, um dos fatores deve ser um mecanismo de autenticação baseado em hardware que ofereça resistência contra comprometimento e falsificação (impersonation) contra ataques de phishing, enquanto verifica a intenção de autenticar por meio da exigência de uma ação iniciada pelo usuário (como o pressionamento de um botão em uma chave de hardware FIDO ou telefone celular). Relaxar qualquer uma das considerações neste requisito exige uma justificativa totalmente documentada e um conjunto abrangente de controles mitigadores. | 2 | +| **6.3.4** | Verifique se, caso a aplicação inclua vários caminhos de autenticação, não há caminhos não documentados e que os controles de segurança e a força de autenticação são impostos consistentemente. | 2 | +| **6.3.5** | Verifique se os usuários são notificados sobre tentativas suspeitas de autenticação (bem-sucedidas ou mal-sucedidas). Isso pode incluir tentativas de autenticação de um local ou cliente incomum, autenticação parcialmente bem-sucedida (apenas um dos múltiplos fatores), uma tentativa de autenticação após um longo período de inatividade ou uma autenticação bem-sucedida após várias tentativas malsucedidas. | 3 | +| **6.3.6** | Verifique se o e-mail não é usado como mecanismo de autenticação de fator único nem multifator. | 3 | +| **6.3.7** | Verifique se os usuários são notificados após atualizações de detalhes de autenticação, como redefinições de credenciais ou modificação do nome de usuário ou endereço de e-mail. | 3 | +| **6.3.8** | Verifique se usuários válidos não podem ser deduzidos de desafios de autenticação malsucedidos, como baseando-se em mensagens de erro, códigos de resposta HTTP ou diferentes tempos de resposta. A funcionalidade de registro e esquecimento de senha também deve ter essa proteção. | 3 | -## V6.4 Authentication Factor Lifecycle and Recovery +## V6.4 Ciclo de Vida e Recuperação do Fator de Autenticação -Authentication factors may include passwords, soft tokens, hardware tokens, and biometric devices. Securely handling the lifecycle of these mechanisms is critical to the security of an application, and this section includes requirements related to this. +Os fatores de autenticação podem incluir senhas, tokens de software, tokens de hardware e dispositivos biométricos. Lidar com o ciclo de vida desses mecanismos de forma segura é fundamental para a segurança de uma aplicação, e esta seção inclui requisitos relacionados a isso. -The requirements in this section mostly relate to [§ 5.1.1.2](https://pages.nist.gov/800-63-3/sp800-63b.html#memsecretver) or [§ 6.1.2.3](https://pages.nist.gov/800-63-3/sp800-63b.html#replacement) of [NIST's Guidance](https://pages.nist.gov/800-63-3/sp800-63b.html). +Os requisitos nesta seção relacionam-se principalmente à [§ 5.1.1.2](https://pages.nist.gov/800-63-3/sp800-63b.html#memsecretver) ou [§ 6.1.2.3](https://pages.nist.gov/800-63-3/sp800-63b.html#replacement) do [Guia do NIST](https://pages.nist.gov/800-63-3/sp800-63b.html). -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **6.4.1** | Verify that system generated initial passwords or activation codes are securely randomly generated, follow the existing password policy, and expire after a short period of time or after they are initially used. These initial secrets must not be permitted to become the long term password. | 1 | -| **6.4.2** | Verify that password hints or knowledge-based authentication (so-called "secret questions") are not present. | 1 | -| **6.4.3** | Verify that a secure process for resetting a forgotten password is implemented, that does not bypass any enabled multi-factor authentication mechanisms. | 2 | -| **6.4.4** | Verify that if a multi-factor authentication factor is lost, evidence of identity proofing is performed at the same level as during enrollment. | 2 | -| **6.4.5** | Verify that renewal instructions for authentication mechanisms which expire are sent with enough time to be carried out before the old authentication mechanism expires, configuring automated reminders if necessary. | 3 | -| **6.4.6** | Verify that administrative users can initiate the password reset process for the user, but that this does not allow them to change or choose the user's password. This prevents a situation where they know the user's password. | 3 | +| **6.4.1** | Verifique se as senhas iniciais geradas pelo sistema ou códigos de ativação são gerados aleatoriamente de forma segura, seguem a política de senha existente e expiram após um curto período ou depois de serem usados inicialmente. Esses segredos iniciais não podem se tornar a senha de longo prazo. | 1 | +| **6.4.2** | Verifique se não estão presentes dicas de senha ou autenticação baseada em conhecimento (as chamadas "perguntas secretas"). | 1 | +| **6.4.3** | Verifique se um processo seguro para a redefinição de uma senha esquecida está implementado, o qual não ignora (bypass) nenhum mecanismo de autenticação multifator habilitado. | 2 | +| **6.4.4** | Verifique se, em caso de perda de um fator de autenticação multifator, a comprovação de identidade é realizada no mesmo nível que durante a inscrição (enrollment). | 2 | +| **6.4.5** | Verifique se as instruções de renovação para os mecanismos de autenticação que expiram são enviadas com tempo suficiente para serem realizadas antes que o antigo mecanismo expire, configurando lembretes automatizados se necessário. | 3 | +| **6.4.6** | Verifique se os usuários administrativos podem iniciar o processo de redefinição de senha para o usuário, mas que isso não permita que eles alterem ou escolham a senha do usuário. Isso evita uma situação em que eles conheçam a senha do usuário. | 3 | -## V6.5 General Multi-factor authentication requirements +## V6.5 Requisitos Gerais de Autenticação Multifator -This section provides general guidance that will be relevant to various different multi-factor authentication methods. +Esta seção fornece orientações gerais que serão relevantes para vários métodos diferentes de autenticação multifator. -The mechanisms include: +Os mecanismos incluem: -* Lookup Secrets -* Time based One-time Passwords (TOTPs) -* Out-of-Band mechanisms +* Segredos de Consulta (Lookup Secrets) +* Senhas de Uso Único Baseadas em Tempo (TOTPs) +* Mecanismos Fora de Banda (Out-of-Band) -Lookup secrets are pre-generated lists of secret codes, similar to Transaction Authorization Numbers (TAN), social media recovery codes, or a grid containing a set of random values. This type of authentication mechanism is considered "something you have" because the codes are deliberately not memorable so will need to be stored somewhere. +Os segredos de consulta são listas pré-geradas de códigos secretos, semelhantes a Números de Autorização de Transação (TAN), códigos de recuperação de mídia social ou uma grade contendo um conjunto de valores aleatórios. Este tipo de mecanismo de autenticação é considerado "algo que você possui" porque os códigos deliberadamente não são memoráveis, logo precisarão ser armazenados em algum lugar. -Time based One-time Passwords (TOTPs) are physical or soft tokens that display a continually changing pseudo-random one-time challenge. This type of authentication mechanism is considered "something you have". Multi-factor TOTPs are similar to single-factor TOTPs, but require a valid PIN code, biometric unlocking, USB insertion or NFC pairing, or some additional value (such as transaction signing calculators) to be entered to create the final One-time Password (OTP). +As Senhas de Uso Único Baseadas em Tempo (TOTPs) são tokens físicos ou de software que exibem um desafio pseudoaleatório de uso único em constante mudança. Este tipo de mecanismo de autenticação é considerado "algo que você possui". TOTPs multifator são semelhantes aos TOTPs de fator único, mas requerem a inserção de um código PIN válido, desbloqueio biométrico, inserção de USB, emparelhamento NFC ou algum valor adicional (como calculadoras de assinatura de transação) para criar a Senha de Uso Único (OTP) final. -Details on out-of-band mechanisms will be provided in the next section. +Detalhes sobre os mecanismos out-of-band serão fornecidos na próxima seção. -The requirements in these sections mostly relate to [§ 5.1.2](https://pages.nist.gov/800-63-3/sp800-63b.html#-512-look-up-secrets), [§ 5.1.3](https://pages.nist.gov/800-63-3/sp800-63b.html#-513-out-of-band-devices), [§ 5.1.4.2](https://pages.nist.gov/800-63-3/sp800-63b.html#5142-single-factor-otp-verifiers), [§ 5.1.5.2](https://pages.nist.gov/800-63-3/sp800-63b.html#5152-multi-factor-otp-verifiers), [§ 5.2.1](https://pages.nist.gov/800-63-3/sp800-63b.html#521-physical-authenticators), and [§ 5.2.3](https://pages.nist.gov/800-63-3/sp800-63b.html#523-use-of-biometrics) of [NIST's Guidance](https://pages.nist.gov/800-63-3/sp800-63b.html). +Os requisitos nestas seções relacionam-se principalmente à [§ 5.1.2](https://pages.nist.gov/800-63-3/sp800-63b.html#-512-look-up-secrets), [§ 5.1.3](https://pages.nist.gov/800-63-3/sp800-63b.html#-513-out-of-band-devices), [§ 5.1.4.2](https://pages.nist.gov/800-63-3/sp800-63b.html#5142-single-factor-otp-verifiers), [§ 5.1.5.2](https://pages.nist.gov/800-63-3/sp800-63b.html#5152-multi-factor-otp-verifiers), [§ 5.2.1](https://pages.nist.gov/800-63-3/sp800-63b.html#521-physical-authenticators) e [§ 5.2.3](https://pages.nist.gov/800-63-3/sp800-63b.html#523-use-of-biometrics) do [Guia do NIST](https://pages.nist.gov/800-63-3/sp800-63b.html). -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **6.5.1** | Verify that lookup secrets, out-of-band authentication requests or codes, and time-based one-time passwords (TOTPs) are only successfully usable once. | 2 | -| **6.5.2** | Verify that, when being stored in the application's backend, lookup secrets with less than 112 bits of entropy (19 random alphanumeric characters or 34 random digits) are hashed with an approved password storage hashing algorithm that incorporates a 32-bit random salt. A standard hash function can be used if the secret has 112 bits of entropy or more. | 2 | -| **6.5.3** | Verify that lookup secrets, out-of-band authentication code, and time-based one-time password seeds, are generated using a Cryptographically Secure Pseudorandom Number Generator (CSPRNG) to avoid predictable values. | 2 | -| **6.5.4** | Verify that lookup secrets and out-of-band authentication codes have a minimum of 20 bits of entropy (typically 4 random alphanumeric characters or 6 random digits is sufficient). | 2 | -| **6.5.5** | Verify that out-of-band authentication requests, codes, or tokens, as well as time-based one-time passwords (TOTPs) have a defined lifetime. Out of band requests must have a maximum lifetime of 10 minutes and for TOTP a maximum lifetime of 30 seconds. | 2 | -| **6.5.6** | Verify that any authentication factor (including physical devices) can be revoked in case of theft or other loss. | 3 | -| **6.5.7** | Verify that biometric authentication mechanisms are only used as secondary factors together with either something you have or something you know. | 3 | -| **6.5.8** | Verify that time-based one-time passwords (TOTPs) are checked based on a time source from a trusted service and not from an untrusted or client provided time. | 3 | +| **6.5.1** | Verifique se os segredos de consulta, solicitações ou códigos de autenticação out-of-band e senhas de uso único baseadas em tempo (TOTPs) podem ser usados com sucesso apenas uma vez. | 2 | +| **6.5.2** | Verifique se, quando armazenados no backend da aplicação, os segredos de consulta com menos de 112 bits de entropia (19 caracteres alfanuméricos aleatórios ou 34 dígitos aleatórios) recebem hash usando um algoritmo aprovado de hash para armazenamento de senhas que incorpore um salt aleatório de 32 bits. Uma função de hash padrão pode ser usada se o segredo tiver 112 bits de entropia ou mais. | 2 | +| **6.5.3** | Verifique se os segredos de consulta, código de autenticação out-of-band e sementes de senha de uso único baseada em tempo são gerados usando um Gerador de Números Pseudoaleatórios Criptograficamente Seguro (CSPRNG) para evitar valores previsíveis. | 2 | +| **6.5.4** | Verifique se os segredos de consulta e os códigos de autenticação out-of-band têm um mínimo de 20 bits de entropia (normalmente 4 caracteres alfanuméricos aleatórios ou 6 dígitos aleatórios são suficientes). | 2 | +| **6.5.5** | Verifique se as solicitações de autenticação out-of-band, códigos ou tokens, bem como as senhas de uso único baseadas em tempo (TOTPs) têm uma vida útil (lifetime) definida. As solicitações out-of-band devem ter uma vida útil máxima de 10 minutos e as TOTPs uma vida útil máxima de 30 segundos. | 2 | +| **6.5.6** | Verifique se qualquer fator de autenticação (incluindo dispositivos físicos) pode ser revogado em caso de roubo ou outra perda. | 3 | +| **6.5.7** | Verifique se os mecanismos de autenticação biométrica são usados ​​apenas como fatores secundários em conjunto com algo que você possui ou algo que você sabe. | 3 | +| **6.5.8** | Verifique se as senhas de uso único baseadas em tempo (TOTPs) são checadas com base em uma fonte de tempo de um serviço confiável e não de um tempo não confiável ou fornecido pelo cliente. | 3 | -## V6.6 Out-of-Band authentication mechanisms +## V6.6 Mecanismos de Autenticação Fora de Banda (Out-of-Band) -This usually involves the authentication server communicating with a physical device over a secure secondary channel. For example, sending push notifications to mobile devices. This type of authentication mechanism is considered "something you have". +Geralmente, isso envolve o servidor de autenticação comunicando-se com um dispositivo físico por meio de um canal secundário seguro. Por exemplo, enviando notificações por push para dispositivos móveis. Esse tipo de mecanismo de autenticação é considerado "algo que você possui". -Unsafe out-of-band authentication mechanisms such as e-mail and VOIP are not permitted. PSTN and SMS authentication are currently considered to be ["restricted" authentication mechanisms](https://pages.nist.gov/800-63-FAQ/#q-b01) by NIST and should be deprecated in favor of Time based One-time Passwords (TOTPs), a cryptographic mechanism, or similar. NIST SP 800-63B [§ 5.1.3.3](https://pages.nist.gov/800-63-3/sp800-63b.html#-5133-authentication-using-the-public-switched-telephone-network) recommends addressing the risks of device swap, SIM change, number porting, or other abnormal behavior, if telephone or SMS out-of-band authentication absolutely has to be supported. While this ASVS section does not mandate this as a requirement, not taking these precautions for a sensitive L2 app or an L3 app should be seen as a significant red flag. +Mecanismos de autenticação out-of-band inseguros, como e-mail e VOIP, não são permitidos. A autenticação por PSTN e SMS é atualmente considerada um [mecanismo de autenticação "restrito"](https://pages.nist.gov/800-63-FAQ/#q-b01) pelo NIST e deve ser preterida em favor de Senhas de Uso Único Baseadas em Tempo (TOTPs), um mecanismo criptográfico, ou similar. A seção [§ 5.1.3.3](https://pages.nist.gov/800-63-3/sp800-63b.html#-5133-authentication-using-the-public-switched-telephone-network) do NIST SP 800-63B recomenda tratar os riscos de troca de dispositivo, troca de SIM, portabilidade de número ou outro comportamento anormal, caso a autenticação telefônica ou SMS out-of-band deva absolutamente ser suportada. Embora esta seção do ASVS não exija isso como um requisito, não tomar essas precauções para um aplicativo L2 sensível ou um aplicativo L3 deve ser visto como um sinal de alerta vermelho significativo. -Note that NIST has also recently provided guidance which [discourages the use of push notifications](https://pages.nist.gov/800-63-4/sp800-63b/authenticators/#fig-3). While this ASVS section does not do so, it is important to be aware of the risks of "push bombing". +Observe que o NIST também forneceu recentemente orientações que [desencorajam o uso de notificações push](https://pages.nist.gov/800-63-4/sp800-63b/authenticators/#fig-3). Embora esta seção do ASVS não faça isso, é importante estar ciente dos riscos de "bombardeio de notificações push" (push bombing). -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **6.6.1** | Verify that authentication mechanisms using the Public Switched Telephone Network (PSTN) to deliver One-time Passwords (OTPs) via phone or SMS are offered only when the phone number has previously been validated, alternate stronger methods (such as Time based One-time Passwords) are also offered, and the service provides information on their security risks to users. For L3 applications, phone and SMS must not be available as options. | 2 | -| **6.6.2** | Verify that out-of-band authentication requests, codes, or tokens are bound to the original authentication request for which they were generated and are not usable for a previous or subsequent one. | 2 | -| **6.6.3** | Verify that a code based out-of-band authentication mechanism is protected against brute force attacks by using rate limiting. Consider also using a code with at least 64 bits of entropy. | 2 | -| **6.6.4** | Verify that, where push notifications are used for multi-factor authentication, rate limiting is used to prevent push bombing attacks. Number matching may also mitigate this risk. | 3 | +| **6.6.1** | Verifique se os mecanismos de autenticação usando a Rede Telefônica Pública Comutada (PSTN) para entregar Senhas de Uso Único (OTPs) via telefone ou SMS são oferecidos apenas quando o número de telefone foi validado previamente, se métodos alternativos e mais fortes (como Senhas de Uso Único Baseadas em Tempo) também são oferecidos e se o serviço fornece informações sobre seus riscos de segurança aos usuários. Para aplicações L3, telefone e SMS não devem estar disponíveis como opções. | 2 | +| **6.6.2** | Verifique se as solicitações de autenticação out-of-band, códigos ou tokens estão vinculados à solicitação de autenticação original para a qual foram gerados e não são utilizáveis para uma solicitação anterior ou subsequente. | 2 | +| **6.6.3** | Verifique se um mecanismo de autenticação out-of-band baseado em código está protegido contra ataques de força bruta usando limitação de taxa (rate limiting). Considere também o uso de um código com pelo menos 64 bits de entropia. | 2 | +| **6.6.4** | Verifique se, quando notificações push são usadas para autenticação multifator, a limitação de taxa é usada para evitar ataques de bombardeio de push (push bombing). A correspondência de números (number matching) também pode mitigar esse risco. | 3 | -## V6.7 Cryptographic authentication mechanism +## V6.7 Mecanismos de Autenticação Criptográfica -Cryptographic authentication mechanisms include smart cards or FIDO keys, where the user has to plug in or pair the cryptographic device to the computer to complete authentication. The authentication server will send a challenge nonce to the cryptographic device or software, and the device or software calculates a response based upon a securely stored cryptographic key. The requirements in this section provide implementation-specific guidance for these mechanisms, with guidance on cryptographic algorithms being covered in the "Cryptography" chapter. +Mecanismos de autenticação criptográfica incluem smart cards ou chaves FIDO, onde o usuário precisa conectar ou emparelhar o dispositivo criptográfico ao computador para concluir a autenticação. O servidor de autenticação enviará um nonce de desafio ao dispositivo ou software criptográfico, e o dispositivo ou software calcula uma resposta baseada em uma chave criptográfica armazenada de forma segura. Os requisitos nesta seção fornecem orientações específicas de implementação para esses mecanismos, sendo que a orientação sobre algoritmos criptográficos é abordada no capítulo "Criptografia". -Where shared or secret keys are used for cryptographic authentication, these should be stored using the same mechanisms as other system secrets, as documented in the "Secret Management" section in the "Configuration" chapter. +Quando chaves compartilhadas ou secretas são usadas para autenticação criptográfica, elas devem ser armazenadas usando os mesmos mecanismos de outros segredos do sistema, conforme documentado na seção "Gerenciamento de Segredos" no capítulo "Configuração". -The requirements in this section mostly relate to [§ 5.1.7.2](https://pages.nist.gov/800-63-3/sp800-63b.html#sfcdv) of [NIST's Guidance](https://pages.nist.gov/800-63-3/sp800-63b.html). +Os requisitos nesta seção relacionam-se principalmente à [§ 5.1.7.2](https://pages.nist.gov/800-63-3/sp800-63b.html#sfcdv) do [Guia do NIST](https://pages.nist.gov/800-63-3/sp800-63b.html). -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **6.7.1** | Verify that the certificates used to verify cryptographic authentication assertions are stored in a way protects them from modification. | 3 | -| **6.7.2** | Verify that the challenge nonce is at least 64 bits in length, and statistically unique or unique over the lifetime of the cryptographic device. | 3 | +| **6.7.1** | Verifique se os certificados usados para verificar afirmações (assertions) de autenticação criptográfica são armazenados de forma que os proteja contra modificações. | 3 | +| **6.7.2** | Verifique se o nonce de desafio tem pelo menos 64 bits de comprimento, e é estatisticamente único ou único durante toda a vida útil do dispositivo criptográfico. | 3 | -## V6.8 Authentication with an Identity Provider +## V6.8 Autenticação com um Provedor de Identidade (Identity Provider) -Identity Providers (IdPs) provide federated identity for users. Users will often have more than one identity with multiple IdPs, such as an enterprise identity using Azure AD, Okta, Ping Identity, or Google, or consumer identity using Facebook, Twitter, Google, or WeChat, to name just a few common alternatives. This list is not an endorsement of these companies or services, but simply an encouragement for developers to consider the reality that many users have many established identities. Organizations should consider integrating with existing user identities, as per the risk profile of the IdP's strength of identity proofing. For example, it is unlikely a government organization would accept a social media identity as a login for sensitive systems, as it is easy to create fake or throwaway identities, whereas a mobile game company may well need to integrate with major social media platforms to grow their active player base. +Provedores de Identidade (IdPs) oferecem identidade federada para os usuários. Os usuários frequentemente terão mais de uma identidade em vários IdPs, como uma identidade corporativa usando o Azure AD, Okta, Ping Identity ou Google, ou identidade de consumidor usando Facebook, Twitter, Google ou WeChat, para citar apenas algumas alternativas comuns. Esta lista não é um endosso a essas empresas ou serviços, mas simplesmente um encorajamento para que os desenvolvedores considerem a realidade de que muitos usuários possuem várias identidades estabelecidas. As organizações devem considerar a integração com identidades de usuários existentes, de acordo com o perfil de risco da força da comprovação de identidade do IdP. Por exemplo, é improvável que uma organização governamental aceite uma identidade de mídia social como login para sistemas sensíveis, já que é fácil criar identidades falsas ou descartáveis, enquanto uma empresa de jogos para dispositivos móveis pode precisar se integrar com grandes plataformas de mídia social para expandir sua base ativa de jogadores. -Secure use of external identity providers requires careful configuration and verification to prevent identity spoofing or forged assertions. This section provides requirements to address these risks. +O uso seguro de provedores de identidade externos exige configuração e verificação cuidadosas para prevenir a falsificação de identidade ou asserções forjadas. Esta seção fornece requisitos para mitigar esses riscos. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **6.8.1** | Verify that, if the application supports multiple identity providers (IdPs), the user's identity cannot be spoofed via another supported identity provider (eg. by using the same user identifier). The standard mitigation would be for the application to register and identify the user using a combination of the IdP ID (serving as a namespace) and the user's ID in the IdP. | 2 | -| **6.8.2** | Verify that the presence and integrity of digital signatures on authentication assertions (for example on JWTs or SAML assertions) are always validated, rejecting any assertions that are unsigned or have invalid signatures. | 2 | -| **6.8.3** | Verify that SAML assertions are uniquely processed and used only once within the validity period to prevent replay attacks. | 2 | -| **6.8.4** | Verify that, if an application uses a separate Identity Provider (IdP) and expects specific authentication strength, methods, or recentness for specific functions, the application verifies this using the information returned by the IdP. For example, if OIDC is used, this might be achieved by validating ID Token claims such as 'acr', 'amr', and 'auth_time' (if present). If the IdP does not provide this information, the application must have a documented fallback approach that assumes that the minimum strength authentication mechanism was used (for example, single-factor authentication using username and password). | 2 | +| **6.8.1** | Verifique se, caso a aplicação suporte múltiplos provedores de identidade (IdPs), a identidade do usuário não pode ser falsificada (spoofed) por meio de outro provedor de identidade suportado (por exemplo, usando o mesmo identificador de usuário). A mitigação padrão seria a aplicação registrar e identificar o usuário usando uma combinação do ID do IdP (servindo como um namespace) e o ID do usuário no IdP. | 2 | +| **6.8.2** | Verifique se a presença e a integridade de assinaturas digitais em asserções de autenticação (por exemplo, em JWTs ou asserções SAML) são sempre validadas, rejeitando quaisquer asserções que não estejam assinadas ou possuam assinaturas inválidas. | 2 | +| **6.8.3** | Verifique se asserções SAML são processadas de maneira única e usadas apenas uma vez dentro do período de validade para prevenir ataques de repetição (replay attacks). | 2 | +| **6.8.4** | Verifique se, caso uma aplicação use um Provedor de Identidade (IdP) separado e espere uma força de autenticação, métodos ou atualidade específicos para funções específicas, a aplicação verifique isso usando as informações retornadas pelo IdP. Por exemplo, se o OIDC for usado, isso pode ser obtido validando as claims (reivindicações) do ID Token, como 'acr', 'amr' e 'auth_time' (se presentes). Se o IdP não fornecer essas informações, a aplicação deve ter uma abordagem de contingência documentada que assume que o mecanismo de autenticação de força mínima foi usado (por exemplo, autenticação de fator único usando nome de usuário e senha). | 2 | -## References +## Referências -For more information, see also: +Para mais informações, veja também: * [NIST SP 800-63 - Digital Identity Guidelines](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-3.pdf) * [NIST SP 800-63B - Authentication and Lifecycle Management](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf) @@ -163,4 +163,4 @@ For more information, see also: * [OWASP Forgot Password Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html) * [OWASP Choosing and Using Security Questions Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Choosing_and_Using_Security_Questions_Cheat_Sheet.html) * [CISA Guidance on "Number Matching"](https://www.cisa.gov/sites/default/files/publications/fact-sheet-implement-number-matching-in-mfa-applications-508c.pdf) -* [Details on the FIDO Alliance](https://fidoalliance.org/) +* [Details on the FIDO Alliance](https://fidoalliance.org/) \ No newline at end of file diff --git a/5.0/pt/0x16-V7-Session-Management.md b/5.0/pt/0x16-V7-Session-Management.md index 0124d000ac..11f3104b0a 100644 --- a/5.0/pt/0x16-V7-Session-Management.md +++ b/5.0/pt/0x16-V7-Session-Management.md @@ -1,91 +1,91 @@ -# V7 Session Management +# V7 Gerenciamento de Sessão -## Control Objective +## Objetivo de Controle -Session management mechanisms allow applications to correlate user and device interactions over time, even when using stateless communication protocols (such as HTTP). Modern applications may use multiple session tokens with distinct characteristics and purposes. A secure session management system is one that prevents attackers from obtaining, utilizing, or otherwise abusing a victim's session. Applications maintaining sessions must ensure that the following high-level session management requirements are met: +Os mecanismos de gerenciamento de sessão permitem que as aplicações correlacionem as interações do usuário e do dispositivo ao longo do tempo, mesmo ao usar protocolos de comunicação sem estado (como o HTTP). Aplicações modernas podem usar vários tokens de sessão com características e propósitos distintos. Um sistema de gerenciamento de sessão seguro é aquele que impede que invasores obtenham, utilizem ou, de outra forma, abusem da sessão de uma vítima. Aplicações que mantêm sessões devem garantir que os seguintes requisitos de alto nível de gerenciamento de sessão sejam atendidos: -* Sessions are unique to each individual and cannot be guessed or shared. -* Sessions are invalidated when no longer required and are timed out during periods of inactivity. +* As sessões são exclusivas de cada indivíduo e não podem ser adivinhadas ou compartilhadas. +* As sessões são invalidadas quando não são mais necessárias e expiram durante períodos de inatividade. -Many of the requirements in this chapter relate to selected [NIST SP 800-63 Digital Identity Guidelines](https://pages.nist.gov/800-63-4/) controls, focusing on common threats and commonly exploited authentication weaknesses. +Muitos dos requisitos neste capítulo estão relacionados aos controles selecionados do [NIST SP 800-63 Digital Identity Guidelines](https://pages.nist.gov/800-63-4/), concentrando-se em ameaças comuns e fraquezas de autenticação frequentemente exploradas. -Note that requirements for specific implementation details of certain session management mechanisms can be found elsewhere: +Observe que os requisitos para detalhes de implementação específicos de determinados mecanismos de gerenciamento de sessão podem ser encontrados em outras partes: -* HTTP Cookies are a common mechanism for securing session tokens. Specific security requirements for cookies can be found in the "Web Frontend Security" chapter. -* Self-contained tokens are frequently used as a way of maintaining sessions. Specific security requirements can be found in the "Self-contained Tokens" chapter. +* Cookies HTTP são um mecanismo comum para proteger tokens de sessão. Os requisitos específicos de segurança para cookies podem ser encontrados no capítulo "Segurança de Frontend Web" (Web Frontend Security). +* Tokens autocontidos (Self-contained tokens) são frequentemente usados como uma forma de manter sessões. Requisitos de segurança específicos podem ser encontrados no capítulo "Tokens Autocontidos" (Self-contained Tokens). -## V7.1 Session Management Documentation +## V7.1 Documentação de Gerenciamento de Sessão -There is no single pattern that suits all applications. Therefore, it is not feasible to define universal boundaries and limits that suit all cases. A risk analysis with documented security decisions related to session handling must be conducted as a prerequisite to implementation and testing. This ensures that the session management system is tailored to the specific requirements of the application. +Não existe um padrão único que atenda a todas as aplicações. Portanto, não é viável definir fronteiras e limites universais que sirvam para todos os casos. Uma análise de risco com decisões de segurança documentadas relacionadas ao tratamento de sessões deve ser conduzida como um pré-requisito para implementação e teste. Isso garante que o sistema de gerenciamento de sessão seja adaptado aos requisitos específicos da aplicação. -Regardless of whether a stateful or "stateless" session mechanism is chosen, the analysis must be complete and documented to demonstrate that the selected solution is capable of satisfying all relevant security requirements. Interaction with any Single Sign-on (SSO) mechanisms in use should also be considered. +Independentemente de ser escolhido um mecanismo de sessão stateful ou "stateless" (sem estado), a análise deve ser completa e documentada para demonstrar que a solução selecionada é capaz de satisfazer todos os requisitos de segurança relevantes. A interação com quaisquer mecanismos de Single Sign-on (SSO) em uso também deve ser considerada. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **7.1.1** | Verify that the user's session inactivity timeout and absolute maximum session lifetime are documented, are appropriate in combination with other controls, and that the documentation includes justification for any deviations from NIST SP 800-63B re-authentication requirements. | 2 | -| **7.1.2** | Verify that the documentation defines how many concurrent (parallel) sessions are allowed for one account as well as the intended behaviors and actions to be taken when the maximum number of active sessions is reached. | 2 | -| **7.1.3** | Verify that all systems that create and manage user sessions as part of a federated identity management ecosystem (such as SSO systems) are documented along with controls to coordinate session lifetimes, termination, and any other conditions that require re-authentication. | 2 | +| **7.1.1** | Verifique se o tempo limite de inatividade da sessão do usuário e o tempo de vida (lifetime) máximo absoluto da sessão estão documentados, são apropriados em combinação com outros controles e se a documentação inclui justificativa para quaisquer desvios dos requisitos de reautenticação do NIST SP 800-63B. | 2 | +| **7.1.2** | Verifique se a documentação define quantas sessões concorrentes (paralelas) são permitidas para uma conta, bem como os comportamentos e as ações pretendidas a serem tomadas quando o número máximo de sessões ativas for alcançado. | 2 | +| **7.1.3** | Verifique se todos os sistemas que criam e gerenciam sessões de usuário como parte de um ecossistema de gerenciamento de identidade federada (como sistemas SSO) estão documentados juntamente com os controles para coordenar tempos de vida das sessões, encerramento e quaisquer outras condições que exijam reautenticação. | 2 | -## V7.2 Fundamental Session Management Security +## V7.2 Segurança Fundamental do Gerenciamento de Sessão -This section satisfies the essential requirements of secure sessions by verifying that session tokens are securely generated and validated. +Esta seção atende aos requisitos essenciais de sessões seguras verificando se os tokens de sessão são gerados e validados com segurança. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **7.2.1** | Verify that the application performs all session token verification using a trusted, backend service. | 1 | -| **7.2.2** | Verify that the application uses either self-contained or reference tokens that are dynamically generated for session management, i.e. not using static API secrets and keys. | 1 | -| **7.2.3** | Verify that if reference tokens are used to represent user sessions, they are unique and generated using a cryptographically secure pseudo-random number generator (CSPRNG) and possess at least 128 bits of entropy. | 1 | -| **7.2.4** | Verify that the application generates a new session token on user authentication, including re-authentication, and terminates the current session token. | 1 | +| **7.2.1** | Verifique se a aplicação realiza toda a verificação do token de sessão usando um serviço de backend confiável. | 1 | +| **7.2.2** | Verifique se a aplicação usa tokens autocontidos ou de referência gerados dinamicamente para o gerenciamento de sessão, ou seja, não usando chaves e segredos estáticos de API. | 1 | +| **7.2.3** | Verifique se, caso tokens de referência sejam usados para representar sessões de usuário, eles são únicos e gerados usando um gerador de números pseudoaleatórios criptograficamente seguro (CSPRNG) e possuem pelo menos 128 bits de entropia. | 1 | +| **7.2.4** | Verifique se a aplicação gera um novo token de sessão no momento da autenticação do usuário, incluindo a reautenticação, e encerra o token de sessão atual. | 1 | -## V7.3 Session Timeout +## V7.3 Tempo Limite de Sessão (Session Timeout) -Session timeout mechanisms serve to minimize the window of opportunity for session hijacking and other forms of session abuse. Timeouts must satisfy documented security decisions. +Mecanismos de timeout (tempo limite) de sessão servem para minimizar a janela de oportunidade para sequestro de sessão (session hijacking) e outras formas de abuso de sessão. Os timeouts devem satisfazer as decisões de segurança documentadas. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **7.3.1** | Verify that there is an inactivity timeout such that re-authentication is enforced according to risk analysis and documented security decisions. | 2 | -| **7.3.2** | Verify that there is an absolute maximum session lifetime such that re-authentication is enforced according to risk analysis and documented security decisions. | 2 | +| **7.3.1** | Verifique se existe um tempo limite (timeout) de inatividade de modo que a reautenticação seja forçada de acordo com a análise de risco e as decisões de segurança documentadas. | 2 | +| **7.3.2** | Verifique se existe um tempo de vida (lifetime) máximo absoluto para a sessão, de forma que a reautenticação seja forçada de acordo com a análise de risco e as decisões de segurança documentadas. | 2 | -## V7.4 Session Termination +## V7.4 Encerramento da Sessão -Session termination may be handled either by the application itself or by the SSO provider if the SSO provider is handling session management instead of the application. It may be necessary to decide whether the SSO provider is in scope when considering the requirements in this section as some may be controlled by the provider. +O encerramento da sessão pode ser tratado pela própria aplicação ou pelo provedor de SSO, caso o provedor de SSO esteja lidando com o gerenciamento de sessão em vez da aplicação. Pode ser necessário decidir se o provedor de SSO está no escopo ao considerar os requisitos nesta seção, pois alguns deles podem ser controlados pelo provedor. -Session termination should result in requiring re-authentication and be effective across the application, federated login (if present), and any relying parties. +O encerramento da sessão deve resultar na exigência de reautenticação e ser eficaz em toda a aplicação, login federado (se presente) e quaisquer relying parties (partes confiáveis). -For stateful session mechanisms, termination typically involves invalidating the session on the backend. In the case of self-contained tokens, additional measures are required to revoke or block these tokens, as they may otherwise remain valid until expiration. +Para mecanismos de sessão stateful, o encerramento normalmente envolve a invalidação da sessão no backend. No caso de tokens autocontidos, medidas adicionais são necessárias para revogar ou bloquear esses tokens, pois de outra forma eles poderiam permanecer válidos até a expiração. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **7.4.1** | Verify that when session termination is triggered (such as logout or expiration), the application disallows any further use of the session. For reference tokens or stateful sessions, this means invalidating the session data at the application backend. Applications using self-contained tokens will need a solution such as maintaining a list of terminated tokens, disallowing tokens produced before a per-user date and time or rotating a per-user signing key. | 1 | -| **7.4.2** | Verify that the application terminates all active sessions when a user account is disabled or deleted (such as an employee leaving the company). | 1 | -| **7.4.3** | Verify that the application gives the option to terminate all other active sessions after a successful change or removal of any authentication factor (including password change via reset or recovery and, if present, an MFA settings update). | 2 | -| **7.4.4** | Verify that all pages that require authentication have easy and visible access to logout functionality. | 2 | -| **7.4.5** | Verify that application administrators are able to terminate active sessions for an individual user or for all users. | 2 | +| **7.4.1** | Verifique se, quando o encerramento da sessão é acionado (como em caso de logout ou expiração), a aplicação proíbe qualquer uso adicional da sessão. Para tokens de referência ou sessões stateful, isso significa invalidar os dados da sessão no backend da aplicação. As aplicações que usam tokens autocontidos precisarão de uma solução como manter uma lista de tokens encerrados, proibir tokens produzidos antes de uma data e hora por usuário ou rotacionar a chave de assinatura por usuário. | 1 | +| **7.4.2** | Verifique se a aplicação encerra todas as sessões ativas quando uma conta de usuário é desativada ou excluída (como quando um funcionário deixa a empresa). | 1 | +| **7.4.3** | Verifique se a aplicação fornece a opção de encerrar todas as outras sessões ativas após uma mudança ou remoção bem-sucedida de qualquer fator de autenticação (incluindo alteração de senha via redefinição ou recuperação e, se presente, atualização de configurações de MFA). | 2 | +| **7.4.4** | Verifique se todas as páginas que requerem autenticação têm um acesso fácil e visível à funcionalidade de logout. | 2 | +| **7.4.5** | Verifique se os administradores da aplicação conseguem encerrar sessões ativas para um usuário individual ou para todos os usuários. | 2 | -## V7.5 Defenses Against Session Abuse +## V7.5 Defesas Contra o Abuso de Sessão -This section provides requirements to mitigate the risk posed by active sessions that are either hijacked or abused through vectors that rely on the existence and capabilities of active user sessions. For example, using malicious content execution to force an authenticated victim browser to perform an action using the victim's session. +Esta seção fornece requisitos para mitigar o risco representado por sessões ativas que sejam sequestradas ou abusadas por meio de vetores que dependem da existência e das capacidades das sessões de usuário ativas. Por exemplo, usando a execução de conteúdo malicioso para forçar um navegador de vítima autenticado a executar uma ação utilizando a sessão da vítima. -Note that the level-specific guidance in the "Authentication" chapter should be taken into account when considering requirements in this section. +Note que a orientação específica por nível no capítulo "Autenticação" (Authentication) deve ser levada em consideração ao avaliar os requisitos desta seção. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **7.5.1** | Verify that the application requires full re-authentication before allowing modifications to sensitive account attributes which may affect authentication such as email address, phone number, MFA configuration, or other information used in account recovery. | 2 | -| **7.5.2** | Verify that users are able to view and (having authenticated again with at least one factor) terminate any or all currently active sessions. | 2 | -| **7.5.3** | Verify that the application requires further authentication with at least one factor or secondary verification before performing highly sensitive transactions or operations. | 3 | +| **7.5.1** | Verifique se a aplicação exige uma reautenticação completa antes de permitir modificações em atributos sensíveis da conta que possam afetar a autenticação, como endereço de e-mail, número de telefone, configuração de MFA ou outras informações usadas na recuperação da conta. | 2 | +| **7.5.2** | Verifique se os usuários são capazes de visualizar e (tendo se autenticado novamente com pelo menos um fator) encerrar qualquer ou todas as sessões ativas no momento. | 2 | +| **7.5.3** | Verifique se a aplicação exige uma autenticação posterior com pelo menos um fator ou verificação secundária antes de executar transações ou operações altamente confidenciais. | 3 | -## V7.6 Federated Re-authentication +## V7.6 Reautenticação Federada -This section relates to those writing Relying Party (RP) or Identity Provider (IdP) code. These requirements are derived from the [NIST SP 800-63C](https://pages.nist.gov/800-63-4/sp800-63c.html) for Federation & Assertions. +Esta seção se relaciona àqueles que escrevem o código da Relying Party (RP) ou do Provedor de Identidade (IdP). Esses requisitos são derivados do [NIST SP 800-63C](https://pages.nist.gov/800-63-4/sp800-63c.html) para Federação e Asserções. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **7.6.1** | Verify that session lifetime and termination between Relying Parties (RPs) and Identity Providers (IdPs) behave as documented, requiring re-authentication as necessary such as when the maximum time between IdP authentication events is reached. | 2 | -| **7.6.2** | Verify that creation of a session requires either the user's consent or an explicit action, preventing the creation of new application sessions without user interaction. | 2 | +| **7.6.1** | Verifique se o tempo de vida e o encerramento da sessão entre Relying Parties (RPs) e Provedores de Identidade (IdPs) se comportam conforme o documentado, exigindo a reautenticação conforme necessário, como, por exemplo, quando o tempo máximo entre os eventos de autenticação do IdP é atingido. | 2 | +| **7.6.2** | Verifique se a criação de uma sessão requer o consentimento do usuário ou uma ação explícita, prevenindo a criação de novas sessões na aplicação sem interação do usuário. | 2 | -## References +## Referências -For more information, see also: +Para mais informações, veja também: * [OWASP Web Security Testing Guide: Session Management Testing](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/06-Session_Management_Testing) -* [OWASP Session Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html) +* [OWASP Session Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html) \ No newline at end of file diff --git a/5.0/pt/0x17-V8-Authorization.md b/5.0/pt/0x17-V8-Authorization.md index eef4209554..9540a0ca3b 100644 --- a/5.0/pt/0x17-V8-Authorization.md +++ b/5.0/pt/0x17-V8-Authorization.md @@ -1,56 +1,56 @@ -# V8 Authorization +# V8 Autorização -## Control Objective +## Objetivo de Controle -Authorization ensures that access is granted only to permitted consumers (users, servers, and other clients). To enforce the Principle of Least Privilege (POLP), verified applications must meet the following high-level requirements: +A autorização garante que o acesso seja concedido apenas aos consumidores permitidos (usuários, servidores e outros clientes). Para aplicar o Princípio do Menor Privilégio (Principle of Least Privilege - POLP), aplicações verificadas devem atender aos seguintes requisitos de alto nível: -* Document authorization rules, including decision-making factors and environmental contexts. -* Consumers should have access only to resources permitted by their defined entitlements. +* Documentar regras de autorização, incluindo fatores de tomada de decisão e contextos ambientais. +* Os consumidores devem ter acesso apenas aos recursos permitidos por seus direitos definidos. -## V8.1 Authorization Documentation +## V8.1 Documentação de Autorização -Comprehensive authorization documentation is essential to ensure that security decisions are consistently applied, auditable, and aligned with organizational policies. This reduces the risk of unauthorized access by making security requirements clear and actionable for developers, administrators, and testers. +A documentação abrangente de autorização é essencial para garantir que as decisões de segurança sejam aplicadas de forma consistente, passíveis de auditoria e alinhadas com as políticas organizacionais. Isso reduz o risco de acesso não autorizado, tornando os requisitos de segurança claros e acionáveis ​​para desenvolvedores, administradores e testadores. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **8.1.1** | Verify that authorization documentation defines rules for restricting function-level and data-specific access based on consumer permissions and resource attributes. | 1 | -| **8.1.2** | Verify that authorization documentation defines rules for field-level access restrictions (both read and write) based on consumer permissions and resource attributes. Note that these rules might depend on other attribute values of the relevant data object, such as state or status. | 2 | -| **8.1.3** | Verify that the application's documentation defines the environmental and contextual attributes (including but not limited to, time of day, user location, IP address, or device) that are used in the application to make security decisions, including those pertaining to authentication and authorization. | 3 | -| **8.1.4** | Verify that authentication and authorization documentation defines how environmental and contextual factors are used in decision-making, in addition to function-level, data-specific, and field-level authorization. This should include the attributes evaluated, thresholds for risk, and actions taken (e.g., allow, challenge, deny, step-up authentication). | 3 | +| **8.1.1** | Verifique se a documentação de autorização define regras para restringir o acesso em nível de função e específico a dados com base nas permissões do consumidor e nos atributos do recurso. | 1 | +| **8.1.2** | Verifique se a documentação de autorização define regras para restrições de acesso em nível de campo (tanto para leitura quanto escrita) com base nas permissões do consumidor e atributos do recurso. Note que essas regras podem depender de outros valores de atributos do objeto de dados relevante, como estado ou status. | 2 | +| **8.1.3** | Verifique se a documentação da aplicação define os atributos ambientais e contextuais (incluindo, mas não se limitando a, hora do dia, localização do usuário, endereço IP ou dispositivo) que são usados na aplicação para tomar decisões de segurança, incluindo as pertinentes à autenticação e autorização. | 3 | +| **8.1.4** | Verifique se a documentação de autenticação e autorização define como fatores ambientais e contextuais são usados na tomada de decisões, além da autorização em nível de função, específica a dados e em nível de campo. Isso deve incluir os atributos avaliados, os limites de risco e as ações tomadas (ex., permitir, desafiar, negar, autenticação step-up). | 3 | -## V8.2 General Authorization Design +## V8.2 Design Geral de Autorização -Implementing granular authorization controls at the function, data, and field levels ensures that consumers can access only what has been explicitly granted to them. +A implementação de controles de autorização granulares no nível de função, dados e campos garante que os consumidores possam acessar apenas o que lhes foi explicitamente concedido. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **8.2.1** | Verify that the application ensures that function-level access is restricted to consumers with explicit permissions. | 1 | -| **8.2.2** | Verify that the application ensures that data-specific access is restricted to consumers with explicit permissions to specific data items to mitigate insecure direct object reference (IDOR) and broken object level authorization (BOLA). | 1 | -| **8.2.3** | Verify that the application ensures that field-level access is restricted to consumers with explicit permissions to specific fields to mitigate broken object property level authorization (BOPLA). | 2 | -| **8.2.4** | Verify that adaptive security controls based on a consumer's environmental and contextual attributes (such as time of day, location, IP address, or device) are implemented for authentication and authorization decisions, as defined in the application's documentation. These controls must be applied when the consumer tries to start a new session and also during an existing session. | 3 | +| **8.2.1** | Verifique se a aplicação garante que o acesso em nível de função seja restrito a consumidores com permissões explícitas. | 1 | +| **8.2.2** | Verifique se a aplicação garante que o acesso específico a dados seja restrito a consumidores com permissões explícitas a itens de dados específicos para mitigar referência direta insegura a objeto (IDOR) e autorização em nível de objeto quebrada (BOLA). | 1 | +| **8.2.3** | Verifique se a aplicação garante que o acesso em nível de campo seja restrito a consumidores com permissões explícitas a campos específicos para mitigar autorização em nível de propriedade de objeto quebrada (BOPLA). | 2 | +| **8.2.4** | Verifique se os controles de segurança adaptativos baseados nos atributos ambientais e contextuais do consumidor (como hora do dia, localização, endereço IP ou dispositivo) são implementados para decisões de autenticação e autorização, conforme definido na documentação da aplicação. Esses controles devem ser aplicados quando o consumidor tentar iniciar uma nova sessão e também durante uma sessão existente. | 3 | -## V8.3 Operation Level Authorization +## V8.3 Autorização em Nível de Operação -The immediate application of authorization changes in the appropriate tier of an application's architecture is crucial to preventing unauthorized actions, especially in dynamic environments. +A aplicação imediata de mudanças de autorização na camada (tier) apropriada da arquitetura de uma aplicação é crucial para evitar ações não autorizadas, especialmente em ambientes dinâmicos. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **8.3.1** | Verify that the application enforces authorization rules at a trusted service layer and doesn't rely on controls that an untrusted consumer could manipulate, such as client-side JavaScript. | 1 | -| **8.3.2** | Verify that changes to values on which authorization decisions are made are applied immediately. Where changes cannot be applied immediately, (such as when relying on data in self-contained tokens), there must be mitigating controls to alert when a consumer performs an action when they are no longer authorized to do so and revert the change. Note that this alternative would not mitigate information leakage. | 3 | -| **8.3.3** | Verify that access to an object is based on the originating subject's (e.g. consumer's) permissions, not on the permissions of any intermediary or service acting on their behalf. For example, if a consumer calls a web service using a self-contained token for authentication, and the service then requests data from a different service, the second service will use the consumer's token, rather than a machine-to-machine token from the first service, to make permission decisions. | 3 | +| **8.3.1** | Verifique se a aplicação impõe as regras de autorização em uma camada de serviço confiável e não depende de controles que um consumidor não confiável possa manipular, como JavaScript no lado do cliente. | 1 | +| **8.3.2** | Verifique se as alterações aos valores sobre os quais as decisões de autorização são tomadas são aplicadas imediatamente. Nos casos onde as mudanças não podem ser aplicadas imediatamente (como quando se depende de dados em tokens autocontidos), deve haver controles mitigadores para alertar quando um consumidor realizar uma ação para a qual ele não está mais autorizado a fazer, e para reverter a mudança. Note que essa alternativa não mitigaria o vazamento de informações. | 3 | +| **8.3.3** | Verifique se o acesso a um objeto é baseado nas permissões do sujeito (ex., consumidor) originador, não nas permissões de qualquer intermediário ou serviço atuando em nome deles. Por exemplo, se um consumidor chama um web service usando um token autocontido para autenticação, e o serviço então solicita dados de um serviço diferente, o segundo serviço usará o token do consumidor, em vez de um token machine-to-machine do primeiro serviço, para tomar decisões de permissão. | 3 | -## V8.4 Other Authorization Considerations +## V8.4 Outras Considerações sobre Autorização -Additional considerations for authorization, particularly for administrative interfaces and multi-tenant environments, help prevent unauthorized access. +Considerações adicionais de autorização, particularmente para interfaces administrativas e ambientes multilocatário (multi-tenant), ajudam a evitar acessos não autorizados. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **8.4.1** | Verify that multi-tenant applications use cross-tenant controls to ensure consumer operations will never affect tenants with which they do not have permissions to interact. | 2 | -| **8.4.2** | Verify that access to administrative interfaces incorporates multiple layers of security, including continuous consumer identity verification, device security posture assessment, and contextual risk analysis, ensuring that network location or trusted endpoints are not the sole factors for authorization even though they may reduce the likelihood of unauthorized access. | 3 | +| **8.4.1** | Verifique se aplicações multilocatário (multi-tenant) usam controles cruzados de inquilinos (cross-tenant) para garantir que as operações do consumidor nunca afetem inquilinos com os quais eles não têm permissão para interagir. | 2 | +| **8.4.2** | Verifique se o acesso a interfaces administrativas incorpora várias camadas de segurança, incluindo a verificação contínua da identidade do consumidor, avaliação da postura de segurança do dispositivo e análise de risco contextual, garantindo que a localização da rede ou endpoints confiáveis não sejam os únicos fatores para a autorização, embora possam reduzir a probabilidade de acesso não autorizado. | 3 | -## References +## Referências -For more information, see also: +Para mais informações, veja também: * [OWASP Web Security Testing Guide: Authorization](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/05-Authorization_Testing) -* [OWASP Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) +* [OWASP Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) \ No newline at end of file diff --git a/5.0/pt/0x18-V9-Self-contained-Tokens.md b/5.0/pt/0x18-V9-Self-contained-Tokens.md index d34dd16b3e..f704d666eb 100644 --- a/5.0/pt/0x18-V9-Self-contained-Tokens.md +++ b/5.0/pt/0x18-V9-Self-contained-Tokens.md @@ -1,36 +1,36 @@ -# V9 Self-contained Tokens +# V9 Tokens Autocontidos (Self-contained Tokens) -## Control Objective +## Objetivo de Controle -The concept of a self-contained token is mentioned in the original RFC 6749 OAuth 2.0 from 2012. It refers to a token containing data or claims on which a receiving service will rely to make security decisions. This should be differentiated from a simple token containing only an identifier, which a receiving service uses to look up data locally. The most common examples of self-contained tokens are JSON Web Tokens (JWTs) and SAML assertions. +O conceito de um token autocontido (self-contained token) é mencionado no RFC 6749 original do OAuth 2.0 de 2012. Refere-se a um token contendo dados ou claims (reivindicações) nos quais um serviço receptor se baseará para tomar decisões de segurança. Isso deve ser diferenciado de um token simples contendo apenas um identificador, o qual um serviço receptor usa para pesquisar os dados localmente. Os exemplos mais comuns de tokens autocontidos são os JSON Web Tokens (JWTs) e as asserções SAML. -The use of self-contained tokens has become very widespread, even outside of OAuth and OIDC. At the same time, the security of this mechanism relies on the ability to validate the integrity of the token and to ensure that the token is valid for a particular context. There are many pitfalls with this process, and this chapter provides specific details of the mechanisms that applications should have in place to prevent them. +O uso de tokens autocontidos tornou-se muito difundido, mesmo fora do OAuth e OIDC. Ao mesmo tempo, a segurança desse mecanismo depende da capacidade de validar a integridade do token e de garantir que o token seja válido para um contexto particular. Existem muitas armadilhas com este processo, e este capítulo fornece detalhes específicos sobre os mecanismos que as aplicações devem ter para evitá-las. -## V9.1 Token source and integrity +## V9.1 Origem e Integridade do Token -This section includes requirements to ensure that the token has been produced by a trusted party and has not been tampered with. +Esta seção inclui requisitos para garantir que o token tenha sido produzido por uma parte confiável e não tenha sido adulterado. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **9.1.1** | Verify that self-contained tokens are validated using their digital signature or MAC to protect against tampering before accepting the token's contents. | 1 | -| **9.1.2** | Verify that only algorithms on an allowlist can be used to create and verify self-contained tokens, for a given context. The allowlist must include the permitted algorithms, ideally only either symmetric or asymmetric algorithms, and must not include the 'None' algorithm. If both symmetric and asymmetric must be supported, additional controls will be needed to prevent key confusion. | 1 | -| **9.1.3** | Verify that key material that is used to validate self-contained tokens is from trusted pre-configured sources for the token issuer, preventing attackers from specifying untrusted sources and keys. For JWTs and other JWS structures, headers such as 'jku', 'x5u', and 'jwk' must be validated against an allowlist of trusted sources. | 1 | +| **9.1.1** | Verifique se os tokens autocontidos são validados usando sua assinatura digital ou MAC para proteger contra adulteração antes de aceitar o conteúdo do token. | 1 | +| **9.1.2** | Verifique se apenas algoritmos em uma lista de permissões (allowlist) podem ser usados para criar e verificar tokens autocontidos para um determinado contexto. A lista de permissões deve incluir os algoritmos permitidos, idealmente apenas algoritmos simétricos ou assimétricos, e não deve incluir o algoritmo 'None'. Se ambos, simétricos e assimétricos, precisarem ser suportados, controles adicionais serão necessários para evitar a confusão de chaves (key confusion). | 1 | +| **9.1.3** | Verifique se o material criptográfico (key material) que é usado para validar tokens autocontidos vem de fontes confiáveis pré-configuradas para o emissor do token, evitando que atacantes especifiquem fontes e chaves não confiáveis. Para JWTs e outras estruturas JWS, cabeçalhos como 'jku', 'x5u' e 'jwk' devem ser validados contra uma lista de permissões de fontes confiáveis. | 1 | -## V9.2 Token content +## V9.2 Conteúdo do Token -Before making security decisions based on the content of a self-contained token, it is necessary to validate that the token has been presented within its validity period and that it is intended for use by the receiving service and for the purpose for which it was presented. This helps avoid insecure cross-usage between different services or with different token types from the same issuer. +Antes de tomar decisões de segurança baseadas no conteúdo de um token autocontido, é necessário validar se o token foi apresentado dentro de seu período de validade e se destina-se ao uso pelo serviço receptor e para o propósito para o qual foi apresentado. Isso ajuda a evitar o uso cruzado inseguro (cross-usage) entre diferentes serviços ou com diferentes tipos de token do mesmo emissor. -Specific requirements for OAuth and OIDC are covered in the dedicated chapter. +Requisitos específicos para OAuth e OIDC são abordados no capítulo dedicado. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **9.2.1** | Verify that, if a validity time span is present in the token data, the token and its content are accepted only if the verification time is within this validity time span. For example, for JWTs, the claims 'nbf' and 'exp' must be verified. | 1 | -| **9.2.2** | Verify that the service receiving a token validates the token to be the correct type and is meant for the intended purpose before accepting the token's contents. For example, only access tokens can be accepted for authorization decisions and only ID Tokens can be used for proving user authentication. | 2 | -| **9.2.3** | Verify that the service only accepts tokens which are intended for use with that service (audience). For JWTs, this can be achieved by validating the 'aud' claim against an allowlist defined in the service. | 2 | -| **9.2.4** | Verify that, if a token issuer uses the same private key for issuing tokens to different audiences, the issued tokens contain an audience restriction that uniquely identifies the intended audiences. This will prevent a token from being reused with an unintended audience. If the audience identifier is dynamically provisioned, the token issuer must validate these audiences in order to make sure that they do not result in audience impersonation. | 2 | +| **9.2.1** | Verifique se, caso haja um intervalo de tempo de validade presente nos dados do token, o token e seu conteúdo sejam aceitos apenas se o tempo de verificação estiver dentro deste intervalo de tempo de validade. Por exemplo, para JWTs, as claims 'nbf' e 'exp' devem ser verificadas. | 1 | +| **9.2.2** | Verifique se o serviço que recebe um token valida que o token seja do tipo correto e tenha o propósito pretendido antes de aceitar os conteúdos do token. Por exemplo, apenas tokens de acesso (access tokens) podem ser aceitos para decisões de autorização e apenas ID Tokens podem ser usados para provar a autenticação do usuário. | 2 | +| **9.2.3** | Verifique se o serviço apenas aceita tokens que são destinados ao uso com esse serviço (audiência). Para JWTs, isso pode ser alcançado validando a claim 'aud' em relação a uma lista de permissões definida no serviço. | 2 | +| **9.2.4** | Verifique se, caso um emissor de token use a mesma chave privada para emitir tokens para públicos diferentes, os tokens emitidos contenham uma restrição de audiência (audience restriction) que identifique unicamente as audiências pretendidas. Isso evitará que um token seja reutilizado com um público não intencional. Se o identificador de audiência for provisionado dinamicamente, o emissor do token deverá validar essas audiências para garantir que não resultem em falsificação de audiência (audience impersonation). | 2 | -## References +## Referências -For more information, see also: +Para mais informações, veja também: -* [OWASP JSON Web Token Cheat Sheet for Java Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.html) (but has useful general guidance) +* [OWASP JSON Web Token Cheat Sheet for Java Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.html) (embora tenha orientações gerais úteis) \ No newline at end of file diff --git a/5.0/pt/0x19-V10-OAuth-and-OIDC.md b/5.0/pt/0x19-V10-OAuth-and-OIDC.md index e726216b4b..350936b248 100644 --- a/5.0/pt/0x19-V10-OAuth-and-OIDC.md +++ b/5.0/pt/0x19-V10-OAuth-and-OIDC.md @@ -1,151 +1,151 @@ -# V10 OAuth and OIDC +# V10 OAuth e OIDC -## Control Objective +## Objetivo de Controle -OAuth2 (referred to as OAuth in this chapter) is an industry-standard framework for delegated authorization. For example, using OAuth, a client application can obtain access to APIs (server resources) on a user's behalf, provided the user has authorized the client application to do so. +O OAuth2 (referido como OAuth neste capítulo) é um framework padrão da indústria para autorização delegada. Por exemplo, usando o OAuth, uma aplicação cliente pode obter acesso a APIs (recursos do servidor) em nome de um usuário, desde que o usuário tenha autorizado a aplicação cliente a fazer isso. -By itself, OAuth is not designed for user authentication. The OpenID Connect (OIDC) framework extends OAuth by adding a user identity layer on top of OAuth. OIDC provides support for features including standardized user information, Single Sign-On (SSO), and session management. As OIDC is an extension of OAuth, the OAuth requirements in this chapter also apply to OIDC. +Por si só, o OAuth não é projetado para autenticação de usuários. O framework OpenID Connect (OIDC) estende o OAuth adicionando uma camada de identidade de usuário sobre o OAuth. O OIDC fornece suporte para recursos que incluem informações de usuário padronizadas, Single Sign-On (SSO) e gerenciamento de sessão. Como o OIDC é uma extensão do OAuth, os requisitos de OAuth neste capítulo também se aplicam ao OIDC. -The following roles are defined in OAuth: +Os seguintes papéis (roles) são definidos no OAuth: -* The OAuth client is the application that attempts to obtain access to server resources (e.g., by calling an API using the issued access token). The OAuth client is often a server-side application. - * A confidential client is a client capable of maintaining the confidentiality of the credentials it uses to authenticate itself with the authorization server. - * A public client is not capable of maintaining the confidentiality of credentials for authenticating with the authorization server. Therefore, instead of authenticating itself (e.g., using 'client_id' and 'client_secret' parameters), it only identifies itself (using a 'client_id' parameter). -* The OAuth resource server (RS) is the server API exposing resources to OAuth clients. -* The OAuth authorization server (AS) is a server application that issues access tokens to OAuth clients. These access tokens allow OAuth clients to access RS resources, either on behalf of an end-user or on the OAuth client's own behalf. The AS is often a separate application, but (if appropriate) it may be integrated into a suitable RS. -* The resource owner (RO) is the end-user who authorizes OAuth clients to obtain limited access to resources hosted on the resource server on their behalf. The resource owner consents to this delegated authorization by interacting with the authorization server. +* O cliente OAuth é a aplicação que tenta obter acesso aos recursos do servidor (ex., chamando uma API usando o token de acesso emitido). O cliente OAuth geralmente é uma aplicação do lado do servidor (server-side). + * Um cliente confidencial é um cliente capaz de manter a confidencialidade das credenciais que usa para se autenticar no servidor de autorização. + * Um cliente público não é capaz de manter a confidencialidade das credenciais para autenticação no servidor de autorização. Portanto, em vez de se autenticar (ex., usando parâmetros 'client_id' e 'client_secret'), ele apenas se identifica (usando um parâmetro 'client_id'). +* O servidor de recursos OAuth (Resource Server - RS) é a API do servidor que expõe os recursos aos clientes OAuth. +* O servidor de autorização OAuth (Authorization Server - AS) é uma aplicação de servidor que emite tokens de acesso aos clientes OAuth. Esses tokens de acesso permitem que os clientes OAuth acessem os recursos do RS, seja em nome de um usuário final ou em nome próprio do cliente OAuth. O AS é frequentemente uma aplicação separada, mas (se apropriado) pode ser integrado a um RS adequado. +* O proprietário do recurso (Resource Owner - RO) é o usuário final que autoriza os clientes OAuth a obter acesso limitado aos recursos hospedados no servidor de recursos em seu nome. O proprietário do recurso consente com esta autorização delegada interagindo com o servidor de autorização. -The following roles are defined in OIDC: +Os seguintes papéis são definidos no OIDC: -* The relying party (RP) is the client application requesting end-user authentication through the OpenID Provider. It assumes the role of an OAuth client. -* The OpenID Provider (OP) is an OAuth AS that is capable of authenticating the end-user and provides OIDC claims to an RP. The OP may be the identity provider (IdP), but in federated scenarios, the OP and the identity provider (where the end-user authenticates) may be different server applications. +* A Relying Party (RP - Parte Confiável) é a aplicação cliente que solicita a autenticação do usuário final através do Provedor OpenID. Ela assume o papel de um cliente OAuth. +* O Provedor OpenID (OpenID Provider - OP) é um AS do OAuth que é capaz de autenticar o usuário final e fornecer as claims (reivindicações) OIDC a uma RP. O OP pode ser o provedor de identidade (IdP), mas em cenários federados, o OP e o provedor de identidade (onde o usuário final se autentica) podem ser aplicações de servidor diferentes. -OAuth and OIDC were initially designed for third-party applications. Today, they are often used by first-party applications as well. However, when used in first-party scenarios, such as authentication and session management, the protocol adds some complexity, which may introduce new security challenges. +O OAuth e o OIDC foram inicialmente projetados para aplicações de terceiros. Hoje, eles são frequentemente usados por aplicações próprias (first-party) também. No entanto, quando usados em cenários first-party, como autenticação e gerenciamento de sessão, o protocolo adiciona certa complexidade, o que pode introduzir novos desafios de segurança. -OAuth and OIDC can be used for many types of applications, but the focus for ASVS and the requirements in this chapter is on web applications and APIs. +O OAuth e o OIDC podem ser usados para muitos tipos de aplicações, mas o foco para o ASVS e os requisitos neste capítulo está em aplicações web e APIs. -Since OAuth and OIDC can be considered logic on top of web technologies, general requirements from other chapters always apply, and this chapter cannot be taken out of context. +Como o OAuth e o OIDC podem ser considerados uma lógica acima das tecnologias web, os requisitos gerais de outros capítulos sempre se aplicam, e este capítulo não pode ser tirado de contexto. -This chapter addresses best current practices for OAuth2 and OIDC aligned with specifications found at and . Even if RFCs are considered mature, they are updated frequently. Thus, it is important to align with the latest versions when applying the requirements in this chapter. See the references section for more details. +Este capítulo aborda as melhores práticas atuais para OAuth2 e OIDC, alinhadas com as especificações encontradas em e . Mesmo que as RFCs sejam consideradas maduras, elas são atualizadas com frequência. Portanto, é importante alinhar-se com as versões mais recentes ao aplicar os requisitos neste capítulo. Veja a seção de referências para mais detalhes. -Given the complexity of the area, it is vitally important for a secure OAuth or OIDC solution to use well-known industry-standard authorization servers and apply the recommended security configuration. +Dada a complexidade da área, é de vital importância para uma solução segura de OAuth ou OIDC o uso de servidores de autorização conhecidos e padrão da indústria, além de aplicar a configuração de segurança recomendada. -Terminology used in this chapter aligns with OAuth RFCs and OIDC specifications, but note that OIDC terminology is only used for OIDC-specific requirements; otherwise, OAuth terminology is used. +A terminologia usada neste capítulo se alinha com as RFCs do OAuth e as especificações do OIDC, mas note que a terminologia do OIDC é usada apenas para requisitos específicos do OIDC; caso contrário, a terminologia do OAuth é usada. -In the context of OAuth and OIDC, the term "token" in this chapter refers to: +No contexto do OAuth e OIDC, o termo "token" neste capítulo refere-se a: -* Access tokens, which shall only be consumed by the RS and can either be reference tokens that are validated using introspection or self-contained tokens that are validated using some key material. -* Refresh tokens, which shall only be consumed by the authorization server that issued the token. -* OIDC ID Tokens, which shall only be consumed by the client that triggered the authorization flow. +* Tokens de acesso (Access tokens), que devem ser consumidos apenas pelo RS e podem ser tokens de referência validados via introspecção (introspection) ou tokens autocontidos (self-contained tokens) validados usando algum material criptográfico. +* Tokens de atualização (Refresh tokens), que devem ser consumidos apenas pelo servidor de autorização que emitiu o token. +* Tokens de ID OIDC (ID Tokens), que devem ser consumidos apenas pelo cliente que iniciou o fluxo de autorização. -The risk levels for some of the requirements in this chapter depend on whether the client is a confidential client or regarded as a public client. Since using strong client authentication mitigates many attack vectors, a few requirements might be relaxed when using a confidential client for L1 applications. +Os níveis de risco para alguns dos requisitos neste capítulo dependem de o cliente ser um cliente confidencial ou considerado um cliente público. Uma vez que o uso de autenticação forte de cliente mitiga muitos vetores de ataque, alguns requisitos podem ser relaxados ao usar um cliente confidencial para aplicações de Nível 1 (L1). -## V10.1 Generic OAuth and OIDC Security +## V10.1 Segurança Genérica de OAuth e OIDC -This section covers generic architectural requirements that apply to all applications using OAuth or OIDC. +Esta seção cobre os requisitos arquitetônicos genéricos que se aplicam a todas as aplicações usando OAuth ou OIDC. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **10.1.1** | Verify that tokens are only sent to components that strictly need them. For example, when using a backend-for-frontend pattern for browser-based JavaScript applications, access and refresh tokens shall only be accessible for the backend. | 2 | -| **10.1.2** | Verify that the client only accepts values from the authorization server (such as the authorization code or ID Token) if these values result from an authorization flow that was initiated by the same user agent session and transaction. This requires that client-generated secrets, such as the proof key for code exchange (PKCE) 'code_verifier', 'state' or OIDC 'nonce', are not guessable, are specific to the transaction, and are securely bound to both the client and the user agent session in which the transaction was started. | 2 | +| **10.1.1** | Verifique se os tokens são enviados apenas aos componentes que estritamente necessitam deles. Por exemplo, ao usar o padrão backend-for-frontend para aplicações JavaScript baseadas no navegador, os tokens de acesso e de atualização devem estar acessíveis apenas para o backend. | 2 | +| **10.1.2** | Verifique se o cliente apenas aceita valores do servidor de autorização (como o authorization code ou ID Token) se esses valores resultarem de um fluxo de autorização que foi iniciado pela mesma sessão do user agent e transação. Isso exige que segredos gerados pelo cliente, como o 'code_verifier' do proof key for code exchange (PKCE), o 'state' ou o 'nonce' do OIDC, não sejam adivinháveis, sejam específicos para a transação e estejam vinculados de forma segura tanto ao cliente quanto à sessão do user agent na qual a transação foi iniciada. | 2 | -## V10.2 OAuth Client +## V10.2 Cliente OAuth -These requirements detail the responsibilities for OAuth client applications. The client can be, for example, a web server backend (often acting as a Backend For Frontend, BFF), a backend service integration, or a frontend Single Page Application (SPA, aka browser-based application). +Estes requisitos detalham as responsabilidades das aplicações cliente OAuth. O cliente pode ser, por exemplo, um backend de servidor web (muitas vezes atuando como um Backend For Frontend, BFF), uma integração de serviço backend ou um Frontend Single Page Application (SPA, também conhecida como aplicação baseada em navegador). -In general, backend clients are regarded as confidential clients and frontend clients are regarded as public clients. However, native applications running on the end-user device can be regarded as confidential when using OAuth dynamic client registration. +Em geral, os clientes de backend são considerados clientes confidenciais e os clientes de frontend são considerados clientes públicos. No entanto, as aplicações nativas em execução no dispositivo do usuário final podem ser consideradas confidenciais ao usar o registro dinâmico de cliente (dynamic client registration) do OAuth. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **10.2.1** | Verify that, if the code flow is used, the OAuth client has protection against browser-based request forgery attacks, commonly known as cross-site request forgery (CSRF), which trigger token requests, either by using proof key for code exchange (PKCE) functionality or checking the 'state' parameter that was sent in the authorization request. | 2 | -| **10.2.2** | Verify that, if the OAuth client can interact with more than one authorization server, it has a defense against mix-up attacks. For example, it could require that the authorization server return the 'iss' parameter value and validate it in the authorization response and the token response. | 2 | -| **10.2.3** | Verify that the OAuth client only requests the required scopes (or other authorization parameters) in requests to the authorization server. | 3 | +| **10.2.1** | Verifique se, caso o code flow seja usado, o cliente OAuth tem proteção contra ataques de falsificação de requisição baseados em navegador, comumente conhecidos como falsificação de requisição entre sites (Cross-Site Request Forgery - CSRF), que disparam solicitações de token, seja usando a funcionalidade proof key for code exchange (PKCE) ou verificando o parâmetro 'state' que foi enviado na solicitação de autorização. | 2 | +| **10.2.2** | Verifique se, caso o cliente OAuth possa interagir com mais de um servidor de autorização, ele possui uma defesa contra ataques de confusão (mix-up attacks). Por exemplo, ele pode exigir que o servidor de autorização retorne o valor do parâmetro 'iss' e validá-lo na resposta de autorização e na resposta de token. | 2 | +| **10.2.3** | Verifique se o cliente OAuth solicita apenas os escopos (ou outros parâmetros de autorização) necessários nas solicitações ao servidor de autorização. | 3 | -## V10.3 OAuth Resource Server +## V10.3 Servidor de Recursos OAuth -In the context of ASVS and this chapter, the resource server is an API. To provide secure access, the resource server must: +No contexto do ASVS e deste capítulo, o servidor de recursos (resource server) é uma API. Para fornecer acesso seguro, o servidor de recursos deve: -* Validate the access token, according to the token format and relevant protocol specifications, e.g., JWT-validation or OAuth token introspection. -* If valid, enforce authorization decisions based on the information from the access token and permissions which have been granted. For example, the resource server needs to verify that the client (acting on behalf of RO) is authorized to access the requested resource. +* Validar o token de acesso, de acordo com o formato do token e as especificações relevantes do protocolo, por exemplo, validação de JWT ou introspecção de token OAuth. +* Se for válido, aplicar decisões de autorização com base nas informações do token de acesso e nas permissões que foram concedidas. Por exemplo, o servidor de recursos precisa verificar se o cliente (agindo em nome do RO) está autorizado a acessar o recurso solicitado. -Therefore, the requirements listed here are OAuth or OIDC specific and should be performed after token validation and before performing authorization based on information from the token. +Portanto, os requisitos listados aqui são específicos de OAuth ou OIDC e devem ser executados após a validação do token e antes de realizar a autorização baseada em informações contidas no token. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **10.3.1** | Verify that the resource server only accepts access tokens that are intended for use with that service (audience). The audience may be included in a structured access token (such as the 'aud' claim in JWT), or it can be checked using the token introspection endpoint. | 2 | -| **10.3.2** | Verify that the resource server enforces authorization decisions based on claims from the access token that define delegated authorization. If claims such as 'sub', 'scope', and 'authorization_details' are present, they must be part of the decision. | 2 | -| **10.3.3** | Verify that if an access control decision requires identifying a unique user from an access token (JWT or related token introspection response), the resource server identifies the user from claims that cannot be reassigned to other users. Typically, it means using a combination of 'iss' and 'sub' claims. | 2 | -| **10.3.4** | Verify that, if the resource server requires specific authentication strength, methods, or recentness, it verifies that the presented access token satisfies these constraints. For example, if present, using the OIDC 'acr', 'amr' and 'auth_time' claims respectively. | 2 | -| **10.3.5** | Verify that the resource server prevents the use of stolen access tokens or replay of access tokens (from unauthorized parties) by requiring sender-constrained access tokens, either Mutual TLS for OAuth 2 or OAuth 2 Demonstration of Proof of Possession (DPoP). | 3 | +| **10.3.1** | Verifique se o servidor de recursos aceita apenas tokens de acesso que são destinados para uso com aquele serviço (audiência). A audiência (audience) pode ser incluída em um token de acesso estruturado (como a claim 'aud' no JWT), ou pode ser verificada usando o endpoint de introspecção do token. | 2 | +| **10.3.2** | Verifique se o servidor de recursos impõe decisões de autorização baseadas em claims do token de acesso que definem a autorização delegada. Se claims como 'sub', 'scope' e 'authorization_details' estiverem presentes, eles devem fazer parte da decisão. | 2 | +| **10.3.3** | Verifique se, caso uma decisão de controle de acesso exija a identificação de um usuário único a partir de um token de acesso (JWT ou resposta de introspecção de token relacionada), o servidor de recursos identifica o usuário a partir de claims que não possam ser reatribuídas a outros usuários. Normalmente, isso significa usar uma combinação das claims 'iss' e 'sub'. | 2 | +| **10.3.4** | Verifique se, caso o servidor de recursos exija força, métodos ou atualidade de autenticação específicos, ele verifica se o token de acesso apresentado satisfaz essas restrições. Por exemplo, se presentes, usando as claims OIDC 'acr', 'amr' e 'auth_time', respectivamente. | 2 | +| **10.3.5** | Verifique se o servidor de recursos impede o uso de tokens de acesso roubados ou a repetição (replay) de tokens de acesso (de partes não autorizadas) exigindo tokens de acesso restritos ao remetente (sender-constrained access tokens), seja via Mutual TLS para OAuth 2 ou OAuth 2 Demonstration of Proof of Possession (DPoP). | 3 | -## V10.4 OAuth Authorization Server +## V10.4 Servidor de Autorização OAuth -These requirements detail the responsibilities for OAuth authorization servers, including OpenID Providers. +Estes requisitos detalham as responsabilidades dos servidores de autorização OAuth, incluindo os Provedores OpenID. -For client authentication, the 'self_signed_tls_client_auth' method is allowed with the prerequisites required by [section 2.2](https://datatracker.ietf.org/doc/html/rfc8705#name-self-signed-certificate-mut) of [RFC 8705](https://datatracker.ietf.org/doc/html/rfc8705). +Para autenticação do cliente, o método 'self_signed_tls_client_auth' é permitido de acordo com os pré-requisitos exigidos pela [seção 2.2](https://datatracker.ietf.org/doc/html/rfc8705#name-self-signed-certificate-mut) da [RFC 8705](https://datatracker.ietf.org/doc/html/rfc8705). -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **10.4.1** | Verify that the authorization server validates redirect URIs based on a client-specific allowlist of pre-registered URIs using exact string comparison. | 1 | -| **10.4.2** | Verify that, if the authorization server returns the authorization code in the authorization response, it can be used only once for a token request. For the second valid request with an authorization code that has already been used to issue an access token, the authorization server must reject a token request and revoke any issued tokens related to the authorization code. | 1 | -| **10.4.3** | Verify that the authorization code is short-lived. The maximum lifetime can be up to 10 minutes for L1 and L2 applications and up to 1 minute for L3 applications. | 1 | -| **10.4.4** | Verify that for a given client, the authorization server only allows the usage of grants that this client needs to use. Note that the grants 'token' (Implicit flow) and 'password' (Resource Owner Password Credentials flow) must no longer be used. | 1 | -| **10.4.5** | Verify that the authorization server mitigates refresh token replay attacks for public clients, preferably using sender-constrained refresh tokens, i.e., Demonstrating Proof of Possession (DPoP) or Certificate-Bound Access Tokens using mutual TLS (mTLS). For L1 and L2 applications, refresh token rotation may be used. If refresh token rotation is used, the authorization server must invalidate the refresh token after usage, and revoke all refresh tokens for that authorization if an already used and invalidated refresh token is provided. | 1 | -| **10.4.6** | Verify that, if the code grant is used, the authorization server mitigates authorization code interception attacks by requiring proof key for code exchange (PKCE). For authorization requests, the authorization server must require a valid 'code_challenge' value and must not accept a 'code_challenge_method' value of 'plain'. For a token request, it must require validation of the 'code_verifier' parameter. | 2 | -| **10.4.7** | Verify that if the authorization server supports unauthenticated dynamic client registration, it mitigates the risk of malicious client applications. It must validate client metadata such as any registered URIs, ensure the user's consent, and warn the user before processing an authorization request with an untrusted client application. | 2 | -| **10.4.8** | Verify that refresh tokens have an absolute expiration, including if sliding refresh token expiration is applied. | 2 | -| **10.4.9** | Verify that refresh tokens and reference access tokens can be revoked by an authorized user using the authorization server user interface, to mitigate the risk of malicious clients or stolen tokens. | 2 | -| **10.4.10** | Verify that confidential client is authenticated for client-to-authorized server backchannel requests such as token requests, pushed authorization requests (PAR), and token revocation requests. | 2 | -| **10.4.11** | Verify that the authorization server configuration only assigns the required scopes to the OAuth client. | 2 | -| **10.4.12** | Verify that for a given client, the authorization server only allows the 'response_mode' value that this client needs to use. For example, by having the authorization server validate this value against the expected values or by using pushed authorization request (PAR) or JWT-secured Authorization Request (JAR). | 3 | -| **10.4.13** | Verify that grant type 'code' is always used together with pushed authorization requests (PAR). | 3 | -| **10.4.14** | Verify that the authorization server issues only sender-constrained (Proof-of-Possession) access tokens, either with certificate-bound access tokens using mutual TLS (mTLS) or DPoP-bound access tokens (Demonstration of Proof of Possession). | 3 | -| **10.4.15** | Verify that, for a server-side client (which is not executed on the end-user device), the authorization server ensures that the 'authorization_details' parameter value is from the client backend and that the user has not tampered with it. For example, by requiring the usage of pushed authorization request (PAR) or JWT-secured Authorization Request (JAR). | 3 | -| **10.4.16** | Verify that the client is confidential and the authorization server requires the use of strong client authentication methods (based on public-key cryptography and resistant to replay attacks), such as mutual TLS ('tls_client_auth', 'self_signed_tls_client_auth') or private key JWT ('private_key_jwt'). | 3 | - -## V10.5 OIDC Client - -As the OIDC relying party acts as an OAuth client, the requirements from the section "OAuth Client" apply as well. - -Note that the "Authentication with an Identity Provider" section in the "Authentication" chapter also contains relevant general requirements. - -| # | Description | Level | +| **10.4.1** | Verifique se o servidor de autorização valida as URIs de redirecionamento (redirect URIs) com base em uma lista de permissões específica do cliente contendo URIs pré-registradas, usando comparação exata de strings. | 1 | +| **10.4.2** | Verifique se, caso o servidor de autorização retorne o código de autorização (authorization code) na resposta de autorização, este possa ser usado apenas uma vez para uma solicitação de token. Para a segunda solicitação válida com um código de autorização que já foi usado para emitir um token de acesso, o servidor de autorização deve rejeitar a solicitação de token e revogar quaisquer tokens emitidos relacionados ao código de autorização. | 1 | +| **10.4.3** | Verifique se o código de autorização tem vida útil curta. A vida útil máxima pode ser de até 10 minutos para aplicações L1 e L2 e de até 1 minuto para aplicações L3. | 1 | +| **10.4.4** | Verifique se, para um determinado cliente, o servidor de autorização permite apenas o uso de tipos de concessão (grants) que este cliente precisa utilizar. Note que os grants 'token' (Implicit flow) e 'password' (Resource Owner Password Credentials flow) não devem mais ser usados. | 1 | +| **10.4.5** | Verifique se o servidor de autorização mitiga os ataques de replay de token de atualização (refresh token) para clientes públicos, preferencialmente usando tokens de atualização restritos ao remetente (sender-constrained), ou seja, Demonstrating Proof of Possession (DPoP) ou Tokens de Acesso Vinculados a Certificado usando mutual TLS (mTLS). Para aplicações L1 e L2, a rotação de token de atualização (refresh token rotation) pode ser usada. Se a rotação de token de atualização for usada, o servidor de autorização deve invalidar o token de atualização após o uso e revogar todos os tokens de atualização para aquela autorização se um token de atualização já usado e invalidado for fornecido. | 1 | +| **10.4.6** | Verifique se, caso o grant do tipo 'code' seja usado, o servidor de autorização mitiga os ataques de interceptação do código de autorização exigindo o proof key for code exchange (PKCE). Para solicitações de autorização, o servidor de autorização deve exigir um valor 'code_challenge' válido e não deve aceitar o valor 'code_challenge_method' como 'plain'. Para uma solicitação de token, ele deve exigir a validação do parâmetro 'code_verifier'. | 2 | +| **10.4.7** | Verifique se, caso o servidor de autorização suporte registro dinâmico de cliente não autenticado (unauthenticated dynamic client registration), ele mitiga o risco de aplicações clientes maliciosas. Ele deve validar os metadados do cliente, como quaisquer URIs registradas, garantir o consentimento do usuário e avisar o usuário antes de processar uma solicitação de autorização com uma aplicação cliente não confiável. | 2 | +| **10.4.8** | Verifique se os tokens de atualização possuem uma expiração absoluta, inclusive se a expiração contínua (sliding expiration) de token de atualização for aplicada. | 2 | +| **10.4.9** | Verifique se os tokens de atualização e os tokens de acesso de referência podem ser revogados por um usuário autorizado usando a interface do usuário do servidor de autorização, para mitigar o risco de clientes maliciosos ou tokens roubados. | 2 | +| **10.4.10** | Verifique se o cliente confidencial é autenticado para as solicitações backchannel entre o cliente e o servidor de autorização, como solicitações de token, solicitações de autorização enviadas por push (PAR) e solicitações de revogação de token. | 2 | +| **10.4.11** | Verifique se a configuração do servidor de autorização atribui apenas os escopos (scopes) necessários ao cliente OAuth. | 2 | +| **10.4.12** | Verifique se, para um determinado cliente, o servidor de autorização permite apenas o valor de 'response_mode' que este cliente precisa utilizar. Por exemplo, fazendo com que o servidor de autorização valide esse valor em relação aos valores esperados ou usando solicitações de autorização enviadas por push (PAR) ou JWT-secured Authorization Request (JAR). | 3 | +| **10.4.13** | Verifique se o grant type 'code' é sempre usado em conjunto com as pushed authorization requests (PAR). | 3 | +| **10.4.14** | Verifique se o servidor de autorização emite apenas tokens de acesso restritos ao remetente (sender-constrained - Proof-of-Possession), seja com tokens de acesso vinculados a certificados usando mutual TLS (mTLS) ou tokens de acesso vinculados a DPoP (Demonstration of Proof of Possession). | 3 | +| **10.4.15** | Verifique se, para um cliente no lado do servidor (server-side, que não é executado no dispositivo do usuário final), o servidor de autorização garante que o valor do parâmetro 'authorization_details' provenha do backend do cliente e que o usuário não o tenha adulterado. Por exemplo, exigindo o uso de uma pushed authorization request (PAR) ou JWT-secured Authorization Request (JAR). | 3 | +| **10.4.16** | Verifique se o cliente é confidencial e o servidor de autorização exige o uso de métodos de autenticação de cliente fortes (baseados em criptografia de chave pública e resistentes a ataques de replay), como mutual TLS ('tls_client_auth', 'self_signed_tls_client_auth') ou JWT de chave privada ('private_key_jwt'). | 3 | + +## V10.5 Cliente OIDC + +Como a Relying Party (Parte Confiável) do OIDC age como um cliente OAuth, os requisitos da seção "Cliente OAuth" também se aplicam. + +Note que a seção "Autenticação com um Provedor de Identidade" no capítulo "Autenticação" também contém requisitos gerais relevantes. + +| # | Descrição | Nível | | :---: | :--- | :---: | -| **10.5.1** | Verify that the client (as the relying party) mitigates ID Token replay attacks. For example, by ensuring that the 'nonce' claim in the ID Token matches the 'nonce' value sent in the authentication request to the OpenID Provider (in OAuth2 refereed to as the authorization request sent to the authorization server). | 2 | -| **10.5.2** | Verify that the client uniquely identifies the user from ID Token claims, usually the 'sub' claim, which cannot be reassigned to other users (for the scope of an identity provider). | 2 | -| **10.5.3** | Verify that the client rejects attempts by a malicious authorization server to impersonate another authorization server through authorization server metadata. The client must reject authorization server metadata if the issuer URL in the authorization server metadata does not exactly match the pre-configured issuer URL expected by the client. | 2 | -| **10.5.4** | Verify that the client validates that the ID Token is intended to be used for that client (audience) by checking that the 'aud' claim from the token is equal to the 'client_id' value for the client. | 2 | -| **10.5.5** | Verify that, when using OIDC back-channel logout, the relying party mitigates denial of service through forced logout and cross-JWT confusion in the logout flow. The client must verify that the logout token is correctly typed with a value of 'logout+jwt', contains the 'event' claim with the correct member name, and does not contain a 'nonce' claim. Note that it is also recommended to have a short expiration (e.g., 2 minutes). | 2 | +| **10.5.1** | Verifique se o cliente (como Relying Party) mitiga os ataques de replay do ID Token. Por exemplo, garantindo que a claim 'nonce' no ID Token corresponda ao valor 'nonce' enviado na solicitação de autenticação para o Provedor OpenID (no OAuth2 referido como a solicitação de autorização enviada ao servidor de autorização). | 2 | +| **10.5.2** | Verifique se o cliente identifica o usuário de forma única a partir das claims do ID Token, geralmente a claim 'sub', a qual não pode ser reatribuída a outros usuários (no escopo de um provedor de identidade). | 2 | +| **10.5.3** | Verifique se o cliente rejeita as tentativas de um servidor de autorização malicioso de se passar por outro servidor de autorização através de metadados do servidor de autorização. O cliente deve rejeitar os metadados do servidor de autorização se o URL do emissor (issuer) nos metadados do servidor de autorização não corresponder exatamente ao URL do emissor pré-configurado esperado pelo cliente. | 2 | +| **10.5.4** | Verifique se o cliente valida se o ID Token tem a intenção de ser usado para aquele cliente (audiência), verificando se a claim 'aud' do token é igual ao valor 'client_id' para o cliente. | 2 | +| **10.5.5** | Verifique se, ao usar o logout back-channel do OIDC, a Relying Party mitiga a negação de serviço através de logout forçado e confusão cruzada de JWT (cross-JWT confusion) no fluxo de logout. O cliente deve verificar se o token de logout está digitado corretamente com um valor de 'logout+jwt', se contém a claim 'event' com o nome de membro correto e se não contém uma claim 'nonce'. Note que também é recomendado ter uma expiração curta (por exemplo, 2 minutos). | 2 | -## V10.6 OpenID Provider +## V10.6 Provedor OpenID -As OpenID Providers act as OAuth authorization servers, the requirements from the section "OAuth Authorization Server" apply as well. +Como os Provedores OpenID agem como servidores de autorização OAuth, os requisitos da seção "Servidor de Autorização OAuth" também se aplicam. -Note that if using the ID Token flow (not the code flow), no access tokens are issued, and many of the requirements for OAuth AS are not applicable. +Note que, se estiver usando o fluxo ID Token (não o fluxo de código), nenhum token de acesso é emitido e muitos dos requisitos para OAuth AS não são aplicáveis. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **10.6.1** | Verify that the OpenID Provider only allows values 'code', 'ciba', 'id_token', or 'id_token code' for response mode. Note that 'code' is preferred over 'id_token code' (the OIDC Hybrid flow), and 'token' (any Implicit flow) must not be used. | 2 | -| **10.6.2** | Verify that the OpenID Provider mitigates denial of service through forced logout. By obtaining explicit confirmation from the end-user or, if present, validating parameters in the logout request (initiated by the relying party), such as the 'id_token_hint'. | 2 | +| **10.6.1** | Verifique se o Provedor OpenID permite apenas os valores 'code', 'ciba', 'id_token' ou 'id_token code' para o modo de resposta (response mode). Note que 'code' é preferível a 'id_token code' (o fluxo Híbrido OIDC) e 'token' (qualquer fluxo Implícito) não deve ser usado. | 2 | +| **10.6.2** | Verifique se o Provedor OpenID mitiga a negação de serviço através de logout forçado. Obtendo a confirmação explícita do usuário final ou, se presente, validando os parâmetros na solicitação de logout (iniciada pela Relying Party), como o 'id_token_hint'. | 2 | -## V10.7 Consent Management +## V10.7 Gerenciamento de Consentimento -These requirements cover the verification of the user's consent by the authorization server. Without proper user consent verification, a malicious actor may obtain permissions on the user's behalf through spoofing or social-engineering. +Estes requisitos abrangem a verificação do consentimento do usuário pelo servidor de autorização. Sem a verificação adequada do consentimento do usuário, um ator malicioso pode obter permissões em nome do usuário através de falsificação ou engenharia social. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **10.7.1** | Verify that the authorization server ensures that the user consents to each authorization request. If the identity of the client cannot be assured, the authorization server must always explicitly prompt the user for consent. | 2 | -| **10.7.2** | Verify that when the authorization server prompts for user consent, it presents sufficient and clear information about what is being consented to. When applicable, this should include the nature of the requested authorizations (typically based on scope, resource server, Rich Authorization Requests (RAR) authorization details), the identity of the authorized application, and the lifetime of these authorizations. | 2 | -| **10.7.3** | Verify that the user can review, modify, and revoke consents which the user has granted through the authorization server. | 2 | +| **10.7.1** | Verifique se o servidor de autorização garante que o usuário consente com cada solicitação de autorização. Se a identidade do cliente não puder ser assegurada, o servidor de autorização deve sempre solicitar explicitamente o consentimento do usuário. | 2 | +| **10.7.2** | Verifique se, quando o servidor de autorização solicita o consentimento do usuário, ele apresenta informações suficientes e claras sobre ao que se está consentindo. Quando aplicável, isso deve incluir a natureza das autorizações solicitadas (geralmente com base no escopo, servidor de recursos, detalhes de autorização do Rich Authorization Requests - RAR), a identidade da aplicação autorizada e a vida útil dessas autorizações. | 2 | +| **10.7.3** | Verifique se o usuário pode revisar, modificar e revogar os consentimentos que o usuário concedeu através do servidor de autorização. | 2 | -## References +## Referências -For more information on OAuth, please see: +Para obter mais informações sobre o OAuth, consulte: * [oauth.net](https://oauth.net/) * [OWASP OAuth 2.0 Protocol Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/OAuth2_Cheat_Sheet.html) -For OAuth-related requirements in ASVS following published and in draft status RFC-s are used: +Para requisitos relacionados ao OAuth no ASVS, são utilizadas as seguintes RFCs, publicadas e em status de rascunho (draft): * [RFC6749 The OAuth 2.0 Authorization Framework](https://datatracker.ietf.org/doc/html/rfc6749) * [RFC6750 The OAuth 2.0 Authorization Framework: Bearer Token Usage](https://datatracker.ietf.org/doc/html/rfc6750) @@ -163,7 +163,7 @@ For OAuth-related requirements in ASVS following published and in draft status R * [draft OAuth 2.0 for Browser-Based Applications](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps) * [draft The OAuth 2.1 Authorization Framework](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-12) -For more information on OpenID Connect, please see: +Para obter mais informações sobre o OpenID Connect, consulte: * [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html) -* [FAPI 2.0 Security Profile](https://openid.net/specs/fapi-security-profile-2_0-final.html) +* [FAPI 2.0 Security Profile](https://openid.net/specs/fapi-security-profile-2_0-final.html) \ No newline at end of file diff --git a/5.0/pt/0x20-V11-Cryptography.md b/5.0/pt/0x20-V11-Cryptography.md index be70abcd6f..1cae62057c 100644 --- a/5.0/pt/0x20-V11-Cryptography.md +++ b/5.0/pt/0x20-V11-Cryptography.md @@ -1,107 +1,107 @@ -# V11 Cryptography +# V11 Criptografia -## Control Objective +## Objetivo de Controle -The objective of this chapter is to define best practices for the general use of cryptography, as well as to instill a fundamental understanding of cryptographic principles and inspire a shift toward more resilient and modern approaches. It encourages the following: +O objetivo deste capítulo é definir as melhores práticas para o uso geral da criptografia, bem como incutir uma compreensão fundamental dos princípios criptográficos e inspirar uma mudança em direção a abordagens mais resilientes e modernas. Ele incentiva o seguinte: -* Implementing robust cryptographic systems that fail securely, adapt to evolving threats, and are future-proof. -* Utilizing cryptographic mechanisms that are both secure and aligned with industry best practices. -* Maintaining a secure cryptographic key management system with appropriate access controls and auditing. -* Regularly evaluating the cryptographic landscape to assess new risks and adapt algorithms accordingly. -* Discovering and managing cryptographic use cases throughout the application's lifecycle to ensure that all cryptographic assets are accounted for and secured. +* Implementar sistemas criptográficos robustos que falhem de forma segura (fail securely), que se adaptem às ameaças em evolução e que sejam preparados para o futuro (future-proof). +* Utilizar mecanismos criptográficos que sejam ao mesmo tempo seguros e alinhados com as melhores práticas do setor. +* Manter um sistema seguro de gerenciamento de chaves criptográficas com controles de acesso e auditoria apropriados. +* Avaliar regularmente o cenário criptográfico para verificar novos riscos e adaptar algoritmos de acordo. +* Descobrir e gerenciar os casos de uso de criptografia ao longo de todo o ciclo de vida da aplicação para garantir que todos os ativos criptográficos sejam contabilizados e protegidos. -In addition to outlining general principles and best practices, this document also provides more in-depth technical information about the requirements in Appendix C - Cryptography Standards. This includes algorithms and modes that are considered "approved" for the purposes of the requirements in this chapter. +Além de delinear princípios gerais e melhores práticas, este documento também fornece informações técnicas mais detalhadas sobre os requisitos no Apêndice C - Padrões de Criptografia. Isso inclui algoritmos e modos que são considerados "aprovados" para os propósitos dos requisitos deste capítulo. -Requirements that use cryptography to solve a separate problem, such as secrets management or communications security, will be in different parts of the standard. +Requisitos que usam criptografia para resolver um problema separado, como gerenciamento de segredos ou segurança de comunicações, estarão em partes diferentes do padrão. -## V11.1 Cryptographic Inventory and Documentation +## V11.1 Inventário e Documentação Criptográfica -Applications need to be designed with strong cryptographic architecture to protect data assets according to their classification. Encrypting everything is wasteful; not encrypting anything is legally negligent. A balance must be struck, usually during architectural or high-level design, design sprints, or architectural spikes. Designing cryptography "on the fly" or retrofitting it will inevitably cost much more to implement securely than simply building it in from the start. +As aplicações precisam ser projetadas com uma forte arquitetura criptográfica para proteger os ativos de dados de acordo com sua classificação. Criptografar tudo é um desperdício; não criptografar nada é uma negligência legal. Um equilíbrio deve ser alcançado, geralmente durante o design da arquitetura ou o design de alto nível (high-level design), design sprints ou architectural spikes. Projetar a criptografia "no improviso" ou fazer adequações retroativas (retrofitting) custará inevitavelmente muito mais para implementar de forma segura do que construí-la desde o início. -It is important to ensure that all cryptographic assets are regularly discovered, inventoried, and assessed. Please see the appendix for more information on how this can be done. +É importante garantir que todos os ativos criptográficos sejam descobertos, inventariados e avaliados regularmente. Por favor, consulte o apêndice para mais informações sobre como isso pode ser feito. -The need to future-proof cryptographic systems against the eventual rise of quantum computing is also critical. Post-Quantum Cryptography (PQC) refers to cryptographic algorithms designed to remain secure against attacks by quantum computers, which are expected to break widely used algorithms such as RSA and elliptic curve cryptography (ECC). +A necessidade de proteger sistemas criptográficos no futuro contra o eventual surgimento da computação quântica também é fundamental. A Criptografia Pós-Quântica (Post-Quantum Cryptography - PQC) refere-se a algoritmos criptográficos projetados para permanecerem seguros contra ataques por computadores quânticos, que têm a expectativa de quebrar os algoritmos amplamente usados, como o RSA e a Criptografia de Curva Elíptica (ECC). -Please see the appendix for current guidance on vetted PQC primitives and standards. +Por favor, consulte o apêndice para orientações atuais sobre primitivas PQC validadas e padrões. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **11.1.1** | Verify that there is a documented policy for management of cryptographic keys and a cryptographic key lifecycle that follows a key management standard such as NIST SP 800-57. This should include ensuring that keys are not overshared (for example, with more than two entities for shared secrets and more than one entity for private keys). | 2 | -| **11.1.2** | Verify that a cryptographic inventory is performed, maintained, regularly updated, and includes all cryptographic keys, algorithms, and certificates used by the application. It must also document where keys can and cannot be used in the system, and the types of data that can and cannot be protected using the keys. | 2 | -| **11.1.3** | Verify that cryptographic discovery mechanisms are employed to identify all instances of cryptography in the system, including encryption, hashing, and signing operations. | 3 | -| **11.1.4** | Verify that a cryptographic inventory is maintained. This must include a documented plan that outlines the migration path to new cryptographic standards, such as post-quantum cryptography, in order to react to future threats. | 3 | +| **11.1.1** | Verifique se há uma política documentada para o gerenciamento de chaves criptográficas e um ciclo de vida da chave criptográfica que siga um padrão de gerenciamento de chaves como o NIST SP 800-57. Isso deve incluir a garantia de que as chaves não sejam supercompartilhadas (overshared) (por exemplo, com mais de duas entidades para segredos compartilhados e mais de uma entidade para chaves privadas). | 2 | +| **11.1.2** | Verifique se um inventário criptográfico é realizado, mantido, atualizado regularmente e se inclui todas as chaves criptográficas, algoritmos e certificados usados pela aplicação. Ele também deve documentar onde as chaves podem ou não ser usadas no sistema e os tipos de dados que podem ou não ser protegidos usando as chaves. | 2 | +| **11.1.3** | Verifique se mecanismos de descoberta criptográfica são empregados para identificar todas as instâncias de criptografia no sistema, incluindo operações de criptografia, hashing e assinatura. | 3 | +| **11.1.4** | Verifique se um inventário criptográfico é mantido. Ele deve incluir um plano documentado que descreve o caminho de migração para os novos padrões de criptografia, como a criptografia pós-quântica, a fim de reagir a ameaças futuras. | 3 | -## V11.2 Secure Cryptography Implementation +## V11.2 Implementação Segura de Criptografia -This section defines the requirements for the selection, implementation, and ongoing management of core cryptographic algorithms for an application. The objective is to ensure that only robust, industry-accepted cryptographic primitives are deployed, in alignment with current standards (e.g., NIST, ISO/IEC) and best practices. Organizations must ensure that each cryptographic component is selected based on peer-reviewed evidence and practical security testing. +Esta seção define os requisitos para a seleção, implementação e gerenciamento contínuo dos principais algoritmos criptográficos de uma aplicação. O objetivo é garantir que apenas primitivas criptográficas robustas e aceitas no setor sejam implantadas, em alinhamento com as normas vigentes (por exemplo, NIST, ISO/IEC) e melhores práticas. As organizações devem garantir que cada componente criptográfico seja selecionado com base em evidências revisadas por pares (peer-reviewed) e testes de segurança práticos. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **11.2.1** | Verify that industry-validated implementations (including libraries and hardware-accelerated implementations) are used for cryptographic operations. | 2 | -| **11.2.2** | Verify that the application is designed with crypto agility such that random number, authenticated encryption, MAC, or hashing algorithms, key lengths, rounds, ciphers and modes can be reconfigured, upgraded, or swapped at any time, to protect against cryptographic breaks. Similarly, it must also be possible to replace keys and passwords and re-encrypt data. This will allow for seamless upgrades to post-quantum cryptography (PQC), once high-assurance implementations of approved PQC schemes or standards are widely available. | 2 | -| **11.2.3** | Verify that all cryptographic primitives utilize a minimum of 128-bits of security based on the algorithm, key size, and configuration. For example, a 256-bit ECC key provides roughly 128 bits of security where RSA requires a 3072-bit key to achieve 128 bits of security. | 2 | -| **11.2.4** | Verify that all cryptographic operations are constant-time, with no 'short-circuit' operations in comparisons, calculations, or returns, to avoid leaking information. | 3 | -| **11.2.5** | Verify that all cryptographic modules fail securely, and errors are handled in a way that does not enable vulnerabilities, such as Padding Oracle attacks. | 3 | +| **11.2.1** | Verifique se implementações validadas pela indústria (incluindo bibliotecas e implementações aceleradas por hardware) são usadas para operações criptográficas. | 2 | +| **11.2.2** | Verifique se a aplicação é projetada com agilidade criptográfica (crypto agility), de tal forma que números aleatórios, criptografia autenticada, MAC ou algoritmos de hash, comprimentos de chave, rodadas (rounds), cifras e modos possam ser reconfigurados, atualizados ou trocados a qualquer momento, para proteger contra quebras criptográficas. Da mesma forma, também deve ser possível substituir chaves e senhas e criptografar novamente os dados. Isso permitirá a realização de upgrades transparentes (seamless) para a criptografia pós-quântica (PQC), assim que implementações de alta garantia (high-assurance) de esquemas ou padrões aprovados de PQC estiverem amplamente disponíveis. | 2 | +| **11.2.3** | Verifique se todas as primitivas criptográficas utilizam um mínimo de 128 bits de segurança com base no algoritmo, no tamanho da chave e na configuração. Por exemplo, uma chave ECC de 256 bits fornece cerca de 128 bits de segurança, ao passo que o RSA requer uma chave de 3072 bits para alcançar 128 bits de segurança. | 2 | +| **11.2.4** | Verifique se todas as operações criptográficas têm tempo constante (constant-time), sem operações de 'curto-circuito' em comparações, cálculos ou retornos, para evitar o vazamento de informações. | 3 | +| **11.2.5** | Verifique se todos os módulos criptográficos falham com segurança (fail securely), e se os erros são tratados de maneira a não permitir o surgimento de vulnerabilidades, como ataques de Padding Oracle. | 3 | -## V11.3 Encryption Algorithms +## V11.3 Algoritmos de Criptografia -Authenticated encryption algorithms built on AES and CHACHA20 form the backbone of modern cryptographic practice. +Os algoritmos de criptografia autenticada construídos em AES e CHACHA20 formam a espinha dorsal da prática criptográfica moderna. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **11.3.1** | Verify that insecure block modes (e.g., ECB) and weak padding schemes (e.g., PKCS#1 v1.5) are not used. | 1 | -| **11.3.2** | Verify that only approved ciphers and modes such as AES with GCM are used. | 1 | -| **11.3.3** | Verify that encrypted data is protected against unauthorized modification preferably by using an approved authenticated encryption method or by combining an approved encryption method with an approved MAC algorithm. | 2 | -| **11.3.4** | Verify that nonces, initialization vectors, and other single-use numbers are not used for more than one encryption key and data-element pair. The method of generation must be appropriate for the algorithm being used. | 3 | -| **11.3.5** | Verify that any combination of an encryption algorithm and a MAC algorithm is operating in encrypt-then-MAC mode. | 3 | +| **11.3.1** | Verifique se os modos de bloco inseguros (por exemplo, ECB) e os esquemas de preenchimento fracos (weak padding schemes, por exemplo, PKCS#1 v1.5) não são usados. | 1 | +| **11.3.2** | Verifique se apenas as cifras e modos aprovados, como o AES com GCM, são usados. | 1 | +| **11.3.3** | Verifique se os dados criptografados estão protegidos contra modificações não autorizadas preferencialmente através do uso de um método de criptografia autenticada aprovado ou da combinação de um método de criptografia aprovado com um algoritmo MAC aprovado. | 2 | +| **11.3.4** | Verifique se os nonces, vetores de inicialização e outros números de uso único (single-use numbers) não são usados para mais de um par de chave de criptografia e elemento de dado. O método de geração deve ser adequado ao algoritmo em uso. | 3 | +| **11.3.5** | Verifique se qualquer combinação de um algoritmo de criptografia com um algoritmo MAC está operando no modo encrypt-then-MAC (criptografa-depois-MAC). | 3 | -## V11.4 Hashing and Hash-based Functions +## V11.4 Hashing e Funções Baseadas em Hash -Cryptographic hashes are used in a wide variety of cryptographic protocols, such as digital signatures, HMAC, key derivation functions (KDF), random bit generation, and password storage. The security of the cryptographic system is only as strong as the underlying hash functions used. This section outlines the requirements for using secure hash functions in cryptographic operations. +Os hashes criptográficos são usados em uma ampla variedade de protocolos criptográficos, como assinaturas digitais, HMAC, funções de derivação de chaves (KDF), geração aleatória de bits e armazenamento de senhas. A segurança do sistema criptográfico depende da força das funções hash subjacentes usadas. Esta seção descreve os requisitos para o uso de funções hash seguras em operações criptográficas. -For password storage, as well as the cryptography appendix, the [OWASP Password Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#password-hashing-algorithms) will also provide useful context and guidance. +Para o armazenamento de senhas, além do apêndice de criptografia, o [OWASP Password Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#password-hashing-algorithms) também fornecerá contexto e orientações úteis. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **11.4.1** | Verify that only approved hash functions are used for general cryptographic use cases, including digital signatures, HMAC, KDF, and random bit generation. Disallowed hash functions, such as MD5, must not be used for any cryptographic purpose. | 1 | -| **11.4.2** | Verify that passwords are stored using an approved, computationally intensive, key derivation function (also known as a "password hashing function"), with parameter settings configured based on current guidance. The settings should balance security and performance to make brute-force attacks sufficiently challenging for the required level of security. | 2 | -| **11.4.3** | Verify that hash functions used in digital signatures, as part of data authentication or data integrity are collision resistant and have appropriate bit-lengths. If collision resistance is required, the output length must be at least 256 bits. If only resistance to second pre-image attacks is required, the output length must be at least 128 bits. | 2 | -| **11.4.4** | Verify that the application uses approved key derivation functions with key stretching parameters when deriving secret keys from passwords. The parameters in use must balance security and performance to prevent brute-force attacks from compromising the resulting cryptographic key. | 2 | +| **11.4.1** | Verifique se apenas funções hash aprovadas são usadas para casos de uso gerais de criptografia, incluindo assinaturas digitais, HMAC, KDF e geração aleatória de bits. Funções de hash não permitidas, como o MD5, não devem ser usadas para nenhum propósito criptográfico. | 1 | +| **11.4.2** | Verifique se as senhas são armazenadas usando uma função de derivação de chave aprovada e de processamento intensivo (também conhecida como "função de hash de senha"), com parâmetros configurados de acordo com a orientação atual. As configurações devem equilibrar segurança e desempenho a fim de tornar os ataques de força bruta suficientemente desafiadores para o nível exigido de segurança. | 2 | +| **11.4.3** | Verifique se as funções hash usadas em assinaturas digitais, como parte da autenticação de dados ou integridade de dados, são resistentes à colisão e possuem os comprimentos de bits adequados. Se for exigida a resistência à colisão, o tamanho da saída deverá ser de, no mínimo, 256 bits. Se apenas a resistência aos ataques de segunda pré-imagem (second pre-image attacks) for exigida, o tamanho da saída deverá ser de, no mínimo, 128 bits. | 2 | +| **11.4.4** | Verifique se a aplicação usa funções de derivação de chave aprovadas com parâmetros de key stretching (alongamento de chave) ao derivar chaves secretas de senhas. Os parâmetros em uso devem equilibrar segurança e desempenho para evitar que ataques de força bruta comprometam a chave criptográfica resultante. | 2 | -## V11.5 Random Values +## V11.5 Valores Aleatórios -Cryptographically secure Pseudo-random Number Generation (CSPRNG) is incredibly difficult to get right. Generally, good sources of entropy within a system will be quickly depleted if over-used, but sources with less randomness can lead to predictable keys and secrets. +A Geração de Números Pseudoaleatórios Criptograficamente Segura (CSPRNG) é incrivelmente difícil de fazer da forma correta. Em geral, boas fontes de entropia dentro de um sistema esgotarão rapidamente se usadas em excesso, mas as fontes com menos aleatoriedade podem levar a chaves e segredos previsíveis. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **11.5.1** | Verify that all random numbers and strings which are intended to be non-guessable must be generated using a cryptographically secure pseudo-random number generator (CSPRNG) and have at least 128 bits of entropy. Note that UUIDs do not respect this condition. | 2 | -| **11.5.2** | Verify that the random number generation mechanism in use is designed to work securely, even under heavy demand. | 3 | +| **11.5.1** | Verifique se todos os números e strings aleatórios que se destinam a não serem adivinháveis devem ser gerados usando um gerador de números pseudoaleatórios criptograficamente seguro (CSPRNG) e têm pelo menos 128 bits de entropia. Note que UUIDs não respeitam esta condição. | 2 | +| **11.5.2** | Verifique se o mecanismo de geração de números aleatórios em uso foi projetado para funcionar de forma segura, mesmo sob alta demanda. | 3 | -## V11.6 Public Key Cryptography +## V11.6 Criptografia de Chave Pública -Public Key Cryptography will be used where it is not possible or not desirable to share a secret key between multiple parties. +A Criptografia de Chave Pública será usada onde não for possível ou indesejável compartilhar uma chave secreta entre várias partes. -As part of this, there exists a need for approved key exchange mechanisms, such as Diffie-Hellman and Elliptic Curve Diffie-Hellman (ECDH) to ensure that the cryptosystem remains secure against modern threats. The "Secure Communication" chapter provides requirements for TLS so the requirements in this section are intended for situations where Public Key Cryptography is being used in use cases other than TLS. +Como parte disso, existe a necessidade de mecanismos aprovados para a troca de chaves, como Diffie-Hellman e Curva Elíptica de Diffie-Hellman (ECDH), para garantir que o sistema criptográfico permaneça seguro contra ameaças modernas. O capítulo "Comunicação Segura" fornece os requisitos para o TLS, de forma que os requisitos nesta seção se destinam a situações em que a Criptografia de Chave Pública esteja sendo usada em casos de uso distintos do TLS. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **11.6.1** | Verify that only approved cryptographic algorithms and modes of operation are used for key generation and seeding, and digital signature generation and verification. Key generation algorithms must not generate insecure keys vulnerable to known attacks, for example, RSA keys which are vulnerable to Fermat factorization. | 2 | -| **11.6.2** | Verify that approved cryptographic algorithms are used for key exchange (such as Diffie-Hellman) with a focus on ensuring that key exchange mechanisms use secure parameters. This will prevent attacks on the key establishment process which could lead to adversary-in-the-middle attacks or cryptographic breaks. | 3 | +| **11.6.1** | Verifique se apenas modos de operação e algoritmos criptográficos aprovados são usados para geração de chaves, seeding, geração e verificação de assinatura digital. Os algoritmos de geração de chaves não devem gerar chaves inseguras que sejam vulneráveis a ataques conhecidos, por exemplo, as chaves RSA que são vulneráveis à fatoração de Fermat. | 2 | +| **11.6.2** | Verifique se os algoritmos criptográficos aprovados são usados para a troca de chaves (como o Diffie-Hellman), com foco em garantir que os mecanismos de troca de chaves utilizem parâmetros seguros. Isso evitará ataques ao processo de estabelecimento da chave que poderiam levar a ataques adversary-in-the-middle ou a quebras criptográficas. | 3 | -## V11.7 In-Use Data Cryptography +## V11.7 Criptografia de Dados Em Uso -Protecting data while it is being processed is paramount. Techniques such as full memory encryption, encryption of data in transit, and ensuring data is encrypted as quickly as possible after use is recommended. +Proteger os dados enquanto estão sendo processados é primordial. O uso de técnicas como criptografia completa de memória, criptografia de dados em trânsito e assegurar que os dados sejam criptografados o mais rápido possível após o uso, é recomendado. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **11.7.1** | Verify that full memory encryption is in use that protects sensitive data while it is in use, preventing access by unauthorized users or processes. | 3 | -| **11.7.2** | Verify that data minimization ensures the minimal amount of data is exposed during processing, and ensure that data is encrypted immediately after use or as soon as feasible. | 3 | +| **11.7.1** | Verifique se o uso de criptografia completa de memória está habilitado para proteger os dados sensíveis enquanto estiverem em uso, impedindo o acesso por usuários ou processos não autorizados. | 3 | +| **11.7.2** | Verifique se a minimização de dados garante a exposição de apenas a menor quantidade de dados durante o processamento, e assegure que os dados sejam criptografados imediatamente após o uso ou logo que for possível. | 3 | -## References +## Referências -For more information, see also: +Para mais informações, veja também: * [OWASP Web Security Testing Guide: Testing for Weak Cryptography](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography) * [OWASP Cryptographic Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html) * [FIPS 140-3](https://csrc.nist.gov/pubs/fips/140-3/final) -* [NIST SP 800-57](https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final) +* [NIST SP 800-57](https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final) \ No newline at end of file diff --git a/5.0/pt/0x21-V12-Secure-Communication.md b/5.0/pt/0x21-V12-Secure-Communication.md index 08013d3b6e..3ee5f6b6db 100644 --- a/5.0/pt/0x21-V12-Secure-Communication.md +++ b/5.0/pt/0x21-V12-Secure-Communication.md @@ -1,57 +1,57 @@ -# V12 Secure Communication +# V12 Comunicação Segura -## Control Objective +## Objetivo de Controle -This chapter includes requirements related to the specific mechanisms that should be in place to protect data in transit, both between an end-user client and a backend service, as well as between internal and backend services. +Este capítulo inclui requisitos relacionados aos mecanismos específicos que devem estar em vigor para proteger dados em trânsito, tanto entre um cliente (usuário final) e um serviço backend, quanto entre serviços internos e os de backend. -The general concepts promoted by this chapter include: +Os conceitos gerais promovidos por este capítulo incluem: -* Ensuring that communications are encrypted externally, and ideally internally as well. -* Configuring encryption mechanisms using the latest guidance, including preferred algorithms and ciphers. -* Ensuring that communications are not being intercepted by unauthorized parties through the use of signed certificates. +* Garantir que as comunicações sejam criptografadas externamente e, idealmente, internamente também. +* Configurar mecanismos de criptografia utilizando as diretrizes mais recentes, incluindo os algoritmos e cifras preferidos. +* Assegurar que as comunicações não sejam interceptadas por partes não autorizadas através do uso de certificados assinados. -In addition to outlining general principles and best practices, the ASVS also provides more in-depth technical information about cryptographic strength in Appendix C - Cryptography Standards. +Além de delinear princípios gerais e melhores práticas, o ASVS também fornece informações técnicas aprofundadas sobre a força criptográfica no Apêndice C - Padrões de Criptografia. -## V12.1 General TLS Security Guidance +## V12.1 Orientação Geral de Segurança TLS -This section provides initial guidance on how to secure TLS communications. Up-to-date tools should be used to review TLS configuration on an ongoing basis. +Esta seção fornece orientações iniciais sobre como proteger as comunicações TLS. Ferramentas atualizadas devem ser utilizadas para revisar a configuração TLS de maneira contínua. -While the use of wildcard TLS certificates is not inherently insecure, a compromise of a certificate that is deployed across all owned environments (e.g., production, staging, development, and test) may lead to a compromise of the security posture of the applications using it. Proper protection, management, and the use of separate TLS certificates in different environments should be employed if possible. +Embora o uso de certificados curinga (wildcard certificates) para o TLS não seja inerentemente inseguro, o comprometimento de um certificado que é implantado em todos os ambientes proprietários (ex., produção, homologação, desenvolvimento e testes) pode levar ao comprometimento da postura de segurança das aplicações que o utilizam. A proteção adequada, o gerenciamento e o uso de certificados TLS distintos em diferentes ambientes devem ser empregados, sempre que possível. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **12.1.1** | Verify that only the latest recommended versions of the TLS protocol are enabled, such as TLS 1.2 and TLS 1.3. The latest version of the TLS protocol must be the preferred option. | 1 | -| **12.1.2** | Verify that only recommended cipher suites are enabled, with the strongest cipher suites set as preferred. L3 applications must only support cipher suites which provide forward secrecy. | 2 | -| **12.1.3** | Verify that the application validates that mTLS client certificates are trusted before using the certificate identity for authentication or authorization. | 2 | -| **12.1.4** | Verify that proper certification revocation, such as Online Certificate Status Protocol (OCSP) Stapling, is enabled and configured. | 3 | -| **12.1.5** | Verify that Encrypted Client Hello (ECH) is enabled in the application's TLS settings to prevent exposure of sensitive metadata, such as the Server Name Indication (SNI), during TLS handshake processes. | 3 | +| **12.1.1** | Verifique se apenas as versões mais recentes recomendadas do protocolo TLS estão habilitadas, como TLS 1.2 e TLS 1.3. A versão mais recente do protocolo TLS deve ser a opção preferida. | 1 | +| **12.1.2** | Verifique se apenas as suites de criptografia recomendadas estão habilitadas, com as suites mais fortes definidas como preferidas. As aplicações L3 devem suportar exclusivamente cipher suites (suites de cifras) que forneçam forward secrecy (sigilo de encaminhamento perfeito). | 2 | +| **12.1.3** | Verifique se a aplicação valida se os certificados de cliente mTLS são confiáveis antes de usar a identidade do certificado para autenticação ou autorização. | 2 | +| **12.1.4** | Verifique se a revogação adequada de certificado, como o Online Certificate Status Protocol (OCSP) Stapling, está habilitada e configurada. | 3 | +| **12.1.5** | Verifique se o Encrypted Client Hello (ECH) está habilitado nas configurações TLS da aplicação para evitar a exposição de metadados sensíveis, como o Server Name Indication (SNI), durante os processos de handshake TLS. | 3 | -## V12.2 HTTPS Communication with External Facing Services +## V12.2 Comunicação HTTPS com Serviços Voltados Para a Internet (External Facing Services) -Ensure all HTTP traffic to external-facing services which the application exposes is sent encrypted, with publicly trusted certificates. +Garanta que todo o tráfego HTTP para serviços voltados externamente expostos pela aplicação seja enviado com criptografia, utilizando certificados confiáveis publicamente. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **12.2.1** | Verify that TLS is used for all connectivity between a client and external facing, HTTP-based services, and does not fall back to insecure or unencrypted communications. | 1 | -| **12.2.2** | Verify that external facing services use publicly trusted TLS certificates. | 1 | +| **12.2.1** | Verifique se o TLS é usado em todas as conectividades entre um cliente e serviços HTTP voltados externamente, e não faz retrocesso (fallback) para comunicações inseguras ou não criptografadas. | 1 | +| **12.2.2** | Verifique se os serviços voltados externamente utilizam certificados TLS que são publicamente confiáveis. | 1 | -## V12.3 General Service to Service Communication Security +## V12.3 Segurança da Comunicação Geral Serviço-a-Serviço -Server communications (both internal and external) involve more than just HTTP. Connections to and from other systems must also be secure, ideally using TLS. +As comunicações dos servidores (tanto as internas quanto as externas) envolvem muito mais do que apenas HTTP. As conexões de e para outros sistemas também devem ser seguras, utilizando idealmente o TLS. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **12.3.1** | Verify that an encrypted protocol such as TLS is used for all inbound and outbound connections to and from the application, including monitoring systems, management tools, remote access and SSH, middleware, databases, mainframes, partner systems, or external APIs. The server must not fall back to insecure or unencrypted protocols. | 2 | -| **12.3.2** | Verify that TLS clients validate certificates received before communicating with a TLS server. | 2 | -| **12.3.3** | Verify that TLS or another appropriate transport encryption mechanism used for all connectivity between internal, HTTP-based services within the application, and does not fall back to insecure or unencrypted communications. | 2 | -| **12.3.4** | Verify that TLS connections between internal services use trusted certificates. Where internally generated or self-signed certificates are used, the consuming service must be configured to only trust specific internal CAs and specific self-signed certificates. | 2 | -| **12.3.5** | Verify that services communicating internally within a system (intra-service communications) use strong authentication to ensure that each endpoint is verified. Strong authentication methods, such as TLS client authentication, must be employed to ensure identity, using public-key infrastructure and mechanisms that are resistant to replay attacks. For microservice architectures, consider using a service mesh to simplify certificate management and enhance security. | 3 | +| **12.3.1** | Verifique se um protocolo criptografado como o TLS é usado para todas as conexões de entrada e de saída da aplicação, incluindo os sistemas de monitoramento, ferramentas de gerenciamento, acesso remoto e SSH, middleware, bancos de dados, mainframes, sistemas de parceiros ou APIs externas. O servidor não deve retornar a protocolos inseguros ou não criptografados. | 2 | +| **12.3.2** | Verifique se os clientes TLS validam os certificados recebidos antes de se comunicarem com um servidor TLS. | 2 | +| **12.3.3** | Verifique se o TLS ou outro mecanismo adequado de criptografia de transporte é utilizado em todas as conectividades entre os serviços internos baseados em HTTP na aplicação, e não faz retrocesso (fallback) para comunicações inseguras ou não criptografadas. | 2 | +| **12.3.4** | Verifique se as conexões TLS entre os serviços internos utilizam certificados confiáveis. Onde certificados autoassinados (self-signed) ou gerados internamente forem utilizados, o serviço consumidor deve ser configurado para confiar apenas em CAs internas específicas e em certificados autoassinados específicos. | 2 | +| **12.3.5** | Verifique se os serviços que se comunicam internamente em um sistema (comunicações intra-serviço) usam autenticação forte para garantir a verificação de cada endpoint. Métodos de autenticação fortes, como a autenticação de cliente TLS, devem ser empregados para assegurar a identidade, usando infraestrutura de chave pública e mecanismos que são resistentes a ataques de repetição (replay attacks). Para as arquiteturas de microserviços, considere o uso de uma malha de serviços (service mesh) para simplificar o gerenciamento de certificados e aprimorar a segurança. | 3 | -## References +## Referências -For more information, see also: +Para mais informações, veja também: * [OWASP - Transport Layer Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html) * [Mozilla's Server Side TLS configuration guide](https://wiki.mozilla.org/Security/Server_Side_TLS) * [Mozilla's tool to generate known good TLS configurations](https://ssl-config.mozilla.org/). -* [O-Saft - OWASP Project to validate TLS configuration](https://owasp.org/www-project-o-saft/) +* [O-Saft - OWASP Project to validate TLS configuration](https://owasp.org/www-project-o-saft/) \ No newline at end of file diff --git a/5.0/pt/0x22-V13-Configuration.md b/5.0/pt/0x22-V13-Configuration.md index 9bac566a49..1247f27b7e 100644 --- a/5.0/pt/0x22-V13-Configuration.md +++ b/5.0/pt/0x22-V13-Configuration.md @@ -1,68 +1,68 @@ -# V13 Configuration +# V13 Configuração -## Control Objective +## Objetivo de Controle -The application's default configuration must be secure for use on the Internet. +A configuração padrão da aplicação deve ser segura para uso na Internet. -This chapter provides guidance on the various configurations necessary to achieve this, including those applied during development, build, and deployment. +Este capítulo fornece orientações sobre as diversas configurações necessárias para atingir isso, incluindo as que são aplicadas durante as fases de desenvolvimento, build e implantação (deployment). -Topics covered include preventing data leakage, securely managing communication between components, and protecting secrets. +Os tópicos abordados incluem prevenção de vazamento de dados, o gerenciamento seguro da comunicação entre os componentes e a proteção de segredos. -## V13.1 Configuration Documentation +## V13.1 Documentação da Configuração -This section outlines documentation requirements for how the application communicates with internal and external services, as well as techniques to prevent loss of availability due to service inaccessibility. It also addresses documentation related to secrets. +Esta seção descreve os requisitos de documentação sobre como a aplicação se comunica com serviços internos e externos, bem como as técnicas utilizadas para impedir a perda de disponibilidade provocada pela inacessibilidade de serviços. Também abrange a documentação relacionada aos segredos. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **13.1.1** | Verify that all communication needs for the application are documented. This must include external services which the application relies upon and cases where an end user might be able to provide an external location to which the application will then connect. | 2 | -| **13.1.2** | Verify that for each service the application uses, the documentation defines the maximum number of concurrent connections (e.g., connection pool limits) and how the application behaves when that limit is reached, including any fallback or recovery mechanisms, to prevent denial of service conditions. | 3 | -| **13.1.3** | Verify that the application documentation defines resource‑management strategies for every external system or service it uses (e.g., databases, file handles, threads, HTTP connections). This should include resource‑release procedures, timeout settings, failure handling, and where retry logic is implemented, specifying retry limits, delays, and back‑off algorithms. For synchronous HTTP request–response operations it should mandate short timeouts and either disable retries or strictly limit retries to prevent cascading delays and resource exhaustion. | 3 | -| **13.1.4** | Verify that the application's documentation defines the secrets that are critical for the security of the application and a schedule for rotating them, based on the organization's threat model and business requirements. | 3 | +| **13.1.1** | Verifique se todas as necessidades de comunicação para a aplicação estão documentadas. Isso deve incluir os serviços externos dos quais a aplicação depende e os casos onde um usuário final poderia ser capaz de fornecer um local (endereço) externo ao qual a aplicação irá se conectar. | 2 | +| **13.1.2** | Verifique se, para cada serviço que a aplicação utiliza, a documentação define o número máximo de conexões concorrentes (ex., limites do pool de conexões) e como a aplicação se comporta quando o limite for atingido, incluindo qualquer mecanismo de contingência ou de recuperação, para evitar as condições de negação de serviço. | 3 | +| **13.1.3** | Verifique se a documentação da aplicação define estratégias de gestão de recursos para todos os sistemas externos ou serviços que utilizar (ex., banco de dados, manipuladores de arquivos (file handles), threads, conexões HTTP). Isso deve incluir os procedimentos de liberação de recursos, configurações do timeout, as formas de tratamento das falhas, e, onde existir lógica de repetição implementada, especificar os limites de repetição, atrasos (delays) e os algoritmos back-off. Para operações de request–response síncronas usando HTTP isso deve obrigar o uso de pequenos timeouts (limites de tempo) e proibir as repetições (retries), ou impô-las usando fortes limitações para prevenir as cascatas de atrasos e a exaustão de recursos. | 3 | +| **13.1.4** | Verifique se a documentação da aplicação define quais segredos são críticos para a segurança da aplicação e estabelece um cronograma de rotação para eles, baseado no modelo de ameaças da organização e nos requisitos de negócio. | 3 | -## V13.2 Backend Communication Configuration +## V13.2 Configuração da Comunicação Backend -Applications interact with multiple services, including APIs, databases, or other components. These may be considered internal to the application but not included in the application's standard access control mechanisms, or they may be entirely external. In either case, it is necessary to configure the application to interact securely with these components and, if required, protect that configuration. +As aplicações interagem com vários serviços, que incluem as APIs, os bancos de dados ou outros componentes. Estes podem ser vistos como parte do interior da aplicação mas não foram inclusos nos mecanismos padrões para controles do acesso dela, ou podem ser componentes completamente externos. Em cada caso, torna-se necessário configurar a aplicação para que a interação se realize de maneira segura com esses componentes e, se assim for solicitado, deve-se também garantir a proteção sobre essa própria configuração. -Note: The "Secure Communication" chapter provides guidance for encryption in transit. +Nota: O capítulo "Comunicação Segura" estabelece orientações gerais de encriptação em trânsito. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **13.2.1** | Verify that communications between backend application components that don't support the application's standard user session mechanism, including APIs, middleware, and data layers, are authenticated. Authentication must use individual service accounts, short-term tokens, or certificate-based authentication and not unchanging credentials such as passwords, API keys, or shared accounts with privileged access. | 2 | -| **13.2.2** | Verify that communications between backend application components, including local or operating system services, APIs, middleware, and data layers, are performed with accounts assigned the least necessary privileges. | 2 | -| **13.2.3** | Verify that if a credential has to be used for service authentication, the credential being used by the consumer is not a default credential (e.g., root/root or admin/admin). | 2 | -| **13.2.4** | Verify that an allowlist is used to define the external resources or systems with which the application is permitted to communicate (e.g., for outbound requests, data loads, or file access). This allowlist can be implemented at the application layer, web server, firewall, or a combination of different layers. | 2 | -| **13.2.5** | Verify that the web or application server is configured with an allowlist of resources or systems to which the server can send requests or load data or files from. | 2 | -| **13.2.6** | Verify that where the application connects to separate services, it follows the documented configuration for each connection, such as maximum parallel connections, behavior when maximum allowed connections is reached, connection timeouts, and retry strategies. | 3 | +| **13.2.1** | Verifique se as comunicações entre os componentes de backend da aplicação, os quais não suportam mecanismos padrões relativos as sessões com usuários, estão autenticadas. Isto engloba as APIs, camadas de dados e middlewares. A autenticação necessita operar com o uso de contas individuais dos serviços, tokens temporários, e métodos de autenticações baseadas com o emprego de certificados ao invés do emprego inalterável (estático) nas credenciais usadas como, por exemplo: senhas, chaves das APIs, compartilhamento das contas e privilégios que foram outorgados de acessos contínuos. | 2 | +| **13.2.2** | Verifique se a comunicação entre componentes das aplicações que rodam como aplicações tipo de servidor final (backend) entre os que figuram a execução de camadas relativas a operação de sistema em si do computador (SO - serviços do operating system local), APIs, middlewares e níveis referentes à dados e transações, ocorrem adotando as configurações das contas empregando a norma da utilização do princípio do menor privilégio, correspondente ao necessário para operar normalmente. | 2 | +| **13.2.3** | Verifique se, sempre no evento que requer utilização ou submissão com credenciais relativas a qualquer prestação e aceitação relativas aos serviços (autenticação de sistema), o valor enviado para e processado referente na conta de um "consumidor", de maneira e formas alguma for a credencial fornecida a de configuração de tipo padronizada de instalação sem mudanças anteriores (por ex: raiz/raiz ou, seja root/root admin/admin). | 2 | +| **13.2.4** | Verifique se ocorre utilização formal por lista explícita das definições aceitáveis para permitir com restrição positiva de aprovação para definir listas normais (allowlists) o apontamento referente de forma exata de e/ou apontando todos/todos os domínios referentes (e sistemas ou fontes de acessos) do qual o processo externo foi configurado por regras permitindo a aprovação contínua sobre as ações na rede as quais são tratadas internamente e autorizadas a enviar ligações diretas do processamento inicial provenientes delas mesmas originárias (isto é para conexões geradas internamente indo pra fora: "outbounds requests"). Isto tem de cobrir chamadas relacionadas para os transportes relativas transferências com fluxos (data loads, APIs) ou para requisição aos usos dos arquivos externos. A técnica dessa lista aceita poderá ocorrer no nível próprio restrito por programa através da aplicação, na estrutura através do próprio HTTP-Server (webserver de fronteira/camadas de roteamento), pelo nível lógico nas interfaces relativas as portas da rede/firewalls e também com junções complexas contendo intersecção entre múltiplos métodos em variadas divisões de processamento. | 2 | +| **13.2.5** | Verifique se as configurações referentes as normas para acesso a servidor central com suporte à rede da camada web possuam estritamente o emprego por de intersecção da adoção para que todos/todos componentes operando a comunicação operem uma estrita validação baseados em lista que contenham os mapeamentos definidos que possam aceitar a efetuação (aprovadas/allowlisted) quanto para as ordens relativas originadas pelas requisições como também aceitar trâmites provindos à carga referida relativas de documentos externos ou outros suportes referentes. | 2 | +| **13.2.6** | Verifique se, para onde as rotinas referentes à transações operacionais do programa façam conectividade apontada para fontes terceiras a outros subsistemas alheios, o projeto observe com obediência de todas definições expostas publicamente nos termos já acordados referidos no manual sobre conexões para configuração padronizada referente. Estas obrigações impõem, que obedeçam: os parâmetros com máxima cota dos volumes aceitos e as paralizações conjuntas em chamadas aceitáveis para concorrência de múltiplos clientes; adoções operacionais referente no sentido ao atingir no qual limite de carga se aproxima; comportamentos adotados em limites operantes com base restritiva ao atrasos impostos com tempo máximo na qual uma espera será encerrada em timeout com resposta final com falha (connection timeouts); adoção finalizada referentes às adoções dos mecanismos perante tentativas extras posteriores contidas referentes nos processos nas definições aplicadas das lógicas e tratamentos à contínuas repetições com base sobre de rotinas da "estratégias nos retries". | 3 | -## V13.3 Secret Management +## V13.3 Gerenciamento de Segredos -Secret management is an essential configuration task to ensure the protection of data used in the application. Specific requirements for cryptography can be found in the "Cryptography" chapter, but this section focuses on the management and handling aspects of secrets. +O gerenciamento de segredos é uma tarefa vital no planejamento para salvaguardar com proteções operacionais os dados durante todo e cada acesso do processamento dos usos do programa. Certos requisitos específicos no qual diz respeito diretamente e unicamente a criptografia de forma detalhada poderão ser lidos internamente perante informações da própria seção específica no capítulo "Criptografia". Esta ramificação, contudo tem ênfase especial, focando restrita na questão da configuração do modelo gerencial relativas, dos cuidados à administração dos fluxos relativas as chaves sensíveis ao serviço. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **13.3.1** | Verify that a secrets management solution, such as a key vault, is used to securely create, store, control access to, and destroy backend secrets. These could include passwords, key material, integrations with databases and third-party systems, keys and seeds for time-based tokens, other internal secrets, and API keys. Secrets must not be included in application source code or included in build artifacts. For an L3 application, this must involve a hardware-backed solution such as an HSM. | 2 | -| **13.3.2** | Verify that access to secret assets adheres to the principle of least privilege. | 2 | -| **13.3.3** | Verify that all cryptographic operations are performed using an isolated security module (such as a vault or hardware security module) to securely manage and protect key material from exposure outside of the security module. | 3 | -| **13.3.4** | Verify that secrets are configured to expire and be rotated based on the application's documentation. | 3 | +| **13.3.1** | Verifique se um sistema e procedimentos criados pra fazer guarda referidas das soluções perante os controles referentes as regras de acesso seguras para operar as chaves como as relativas e exemplificadas por meio aos sistemas para cofres a chaves operacionais e a controle as restrições ao acessos de criação são executados nos serviços na gestão relativas sobre proteção e manuseios controlados para assegurar a construção e guarda de segredos no processamento no servidor local das chamadas e de processos referidos do lado-backend da programação contendo segredos com proteções e salvaguardas nos destrancamentos. Entre esses dados incluem: as bases sensíveis com acesso sob formato tipo em senha codificadas restritas; os chaves de algoritmos; os componentes essenciais com as ligações com parâmetros às baseadas transacionadas para servidores no exterior alheios; senhas dinâmicas criadas em processos de seeds de código-aleatório das formas usadas pela validade nos testes do modo do tempo das chamadas nos TOTPS. A verificação impõe: Em situações nas quais dados são vitais, segredos deverão continuar omitidos na adoção dos locais perante arquivos abertos durante manipulações operacionais feitas referidas a bases nos próprios projetos no repasse as operações à nível de desenvolvimento como em bibliotecas no controle centralizados, no que se estenda até os conteúdos formados em pacotes e entregues criados nos "builds/artifact". Um projeto, ao atingir as especificações relativas em padrão final de enquadro no grau para nível da matriz em certificação na base L3 precisará por de padrão empregar referidos aparelhos exclusivos a execução dos suportes em "aparelhos criados sob níveis das estruturas fisicamente separados por peças isoladas e fechadas via hardware" da forma a qual define uma categoria e classes das configurações nos "Modelos Físicos Em Hardwares Seguros- HSM - hardware Security Modules" | 2 | +| **13.3.2** | Verifique se todos modelos e configurações nas ações com permissões referidas às leituras das rotinas nas proteções aos registros mantidos referenciando chaves sensíveis sigam obrigatoriamente a adoção as restrições com a normatização fundamentadas ao padrão contido pelas diretrizes baseadas nas doutrinas referente ao Princípio Dos Menores e Mínimos Privilégios (least privilege). | 2 | +| **13.3.3** | Verifique se, perante a necessidade e momento os quais todas atuações as quais utilizem de bases referentes de lógica de uso por códigos-aleatórios (criptográficas) serão transacionadas exclusivamente, sempre sendo iniciadas rodando através unicamente do meio isolado pelas zonas e setores restritos, através módulos referidos por meio seguro, utilizando os suportes referentes para as execuções (de modos tais através do qual referimos à uso referidos ao "Vault" / cofres na nuvem e modelos físicos como aos "hardware security modules/ HSM"), cuja obrigação do seu controle nas diretrizes nos processos deverão operar na coordenação perante os registros sigilosos ao resguardo do formato sigiloso sob proteções a vazamentos, aos acessos com intenção quebra e ou acesso de perdas operacionais relativas os dados das senhas e chaves que ocorram aos âmbitos os quais transacionam no mundo "exterior", além fronteiras perante estas as barreiras de módulo das garantias as manutenções contidas nas seguranças. | 3 | +| **13.3.4** | Verifique se as orientações para adoção referente do registro ao armazenamento perante códigos chaves (segredos) possuam em si no momento da elaboração em sistema com datas as quais estipulem regras referentes os quais as senhas de sistema embutidas se perderão valor de validações através regras com tempo limitador final expostos e cujas validações operacionais farão as manutenções gerando as atualizações cíclicas operantes (rotating) da mesma maneira referidas e impostas de formato ao obedecer fielmente as bases com exigências apontadas publicamente referenciadas nos meios disponíveis nos guias formais e regulamentos operacionais pela as bases referentes as políticas internas referentes através as documentações contidas na aplicação respectiva. | 3 | -## V13.4 Unintended Information Leakage +## V13.4 Vazamento de Informações Não Intencionais (Unintended Information Leakage) -Production configurations should be hardened to avoid disclosing unnecessary data. Many of these issues are rarely rated as significant risks but are often chained with other vulnerabilities. If these issues are not present by default, it raises the bar for attacking an application. +Configurações que estão baseadas perante os perfis aos sistemas dos processos no momento os quais as rotinas referentes da programação estejam executando e em serviço público online, por conseguinte a níveis sob condições em modo-de-produção deverão estar blindadas pelas bases operantes das seguranças em modos-hardened e fortes; isto visa em suma a contenção relativas, das fugas provindas pela extração relativas sobre exposição do ambiente referente com detalhes e configurações sensíveis de metadados não operantes que geram desnecessidades a níveis de usabilidade a funções com publicações na divulgação aberta de relativas bases dos sistemas expostos. No âmbito das detecções nas vulnerabilidades da exploração e nos ataques provindos de exterior, o processo das análises apontadas da quebra de informações dos componentes a níveis da aplicação e vazamentos referidos não acarretarão um sinal isolado e direto e, ou exclusivo, como uma porta de aberturas na rede os quais por norma relativas por sistemas a classificação as classifiquem através bases de alertas com risco principal as ameaças como níveis expressivos (sig. risks); contudo as falhas a respeito das regras referentes a este processo a níveis práticos serão combinadas as brechas expostas originadas a respeito à outras falhas (charmed exploits). Se esse tipo específico com relativas ausências das seguranças do exposto anteriormente (issues) já não houver sido exposto a níveis originais por padrões através o projeto em si mesmo e não operar na base padrão padrão na operação inicial da publicação a níveis padrão pela as defesas das regras criadas: esta atitude inicial sem as publicações referidas nas fraquezas elevará ao processo uma camada a qual estipulará as elevações baseadas as dificuldades dos ataques provenientes nos processos referidos das proteções pelas ações nas camadas nas relativas estruturas que contem base os muros aos quais cobrem da aplicação o a um patamar forte na tentativa do qual exigirão, as defesas com melhor barreiras a respeito de um cibercrime apontado (raises the bar para ataques). -For example, hiding the version of server-side components does not eliminate the need to patch all components, and disabling folder listing does not remove the need to use authorization controls or keep files away from the public folder, but it raises the bar. +À guisa da ilustração: uma tática operada por referidas diretrizes como a ocultação dos níveis dos códigos referentes contendo a versão a respeito, e embutido pelas das aplicações ou referidos servidores em camadas do backend perante este processo da mesma não anulará e a as ausências e também obrigações das necessidades provindas a que atualizem através manutenções referentes a níveis e aplicações das atualizações por uso a níveis de patch pra manter perante ao código base sem fraquezas (vulnerabilities); em similaridade e analogia das configurações referidas de proibições e desligamentos as referentes publicações em respostas com as listagens automáticas criadas apontadas ao formato diretório as referentes funções base (folders-listing) do uso contido por servidor este feito inicial da mesma forma em si ao processo também assim referida no processo inicial sem cancelamentos relativas da ausência da eliminação das necessidades para uso no projeto através os serviços usando dos processos relativos a controles na autorização com a blindagens baseadas em segurança relativas para que impeça ao uso e manter arquivos sensíveis ausente a respeito na permanência perante o locais base através os diretórios na internet; ou em nível de arquivos de dados, mas este processo a mesma medida das ações efetuadas impulsionarão as exigências as relativas formas a que os ataques cibernéticos atuantes a respeito deste problema efetuados tenham restrições provindas operadas através a fortificação do acesso original através processos para dificultar o trabalho com maiores complexidades geradas na execução perante as rotinas base no qual é imposta (it raises the bar). -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **13.4.1** | Verify that the application is deployed either without any source control metadata, including the .git or .svn folders, or in a way that these folders are inaccessible both externally and to the application itself. | 1 | -| **13.4.2** | Verify that debug modes are disabled for all components in production environments to prevent exposure of debugging features and information leakage. | 2 | -| **13.4.3** | Verify that web servers do not expose directory listings to clients unless explicitly intended. | 2 | -| **13.4.4** | Verify that using the HTTP TRACE method is not supported in production environments, to avoid potential information leakage. | 2 | -| **13.4.5** | Verify that documentation (such as for internal APIs) and monitoring endpoints are not exposed unless explicitly intended. | 2 | -| **13.4.6** | Verify that the application does not expose detailed version information of backend components. | 3 | -| **13.4.7** | Verify that the web tier is configured to only serve files with specific file extensions to prevent unintentional information, configuration, and source code leakage. | 3 | +| **13.4.1** | Verifique se a aplicação opera na inicialização e contínuo serviço operacional (deployed) perante bases com condições das publicações originadas e isentas de processos contendo as transferências nos acompanhamentos gerados nas cópias sobre qualquer e relativas, provindas na sua extensão de todo base referida nas estruturas operantes em conjunto contendo embutidos aos originais metadados da engenharia que suportam o software a partir do processo de originais e bases que compões do controle da codificação primária da versões com referidas formas que englobam repositório contidos embutidas através do repasses as cópias do servidor por diretórios com arquivos através do padrão.git as quais através uso pelas extensões as de tipo das bases operacionais.svn ou na falha referente que esta falha se faça embutir; na obrigações das presenças a qual estas informações a que estiverem publicadas: na configuração com publicações estas presenças devem operar através configurações as quais elas farão bases cujas restrições referidas a formas em publicações inalcançáveis com proibições as formas abertas pra redes referidas exteriores como nas proibições diretas de processamentos referentes através do formato base da estrutura de programação e a aplicação contidas de forma em bases na mesma através o próprio servidor operante (à si mesmo). | 1 | +| **13.4.2** | Verifique se configurações perante aos testes e também nas investigações os processos de correções internas as quais em ambientes através do desenvolvedores referentes através a rotinas referentes relativas o processos no "modo debug" do sistema de componentes a que constituem referidos a todos dos locais a programação em todo processo de servidores as qual já se fazem através dos meios nos quais de execução pública e também ativa do sistema em operações contínuas relativas de base a processos perante a "modo e local no servidores-produções" estão sendo desligados da atuação do sistema das opções de referidas aplicações (disabled): essa imposição da técnica visa o combate no contínuo dos acompanhamentos abertos as falhas e relativas ações em exposições não aceitas através aos detalhes dos módulos operacionais contidas gerados provindo referidas características a processos relativas os modos investigações operantes (debugging resources and feature) e das publicações operacionais dos fluxos do processo com extração através detalhes abertos através perante das vazões do sigilo a nível embutidos os quais produzem falhas por fluxos das lógicas de vazamento sobre vazões aos dados os relativas da "information-leakage". | 2 | +| **13.4.3** | Verifique se estruturas a respeito do nível através as operações no uso com processadores perante publicadores baseados aos provedores online relativas a provedores base web (web-servers), aos mesmos na prestação contínua operacionais referentes dos usuários acessando (clients), não repassam as devoluções relativas as ordens provindas na abertura de informações contendo repasses embutidas referentes aos catálogos ou de visualização relativas as aberturas sobre e das listagens do estrutura base através as navegações sobre árvores aos contendo aos respectivos ao uso nos diretório (direcory-listing) com a exceção aos processo relativas por ordens referidas a definições explícitas contidas através com bases pelas intenções documentadas e planejadas a níveis a aplicações (unless explicitly intended). | 2 | +| **13.4.4** | Verifique se através as atuações das regras provindas no protocolo padrão da base perante requisições do processador web o emprego as definições usando do tipo do modo HTTP apontado no estilo da comunicação TRACE estão proibidas através recusas a qual eles não possuem o uso em formatos suportado provindo ao níveis das aplicações através do processador central ativo os que no níveis a operação contínua com ambiente público em fase na versão de operações no ambientes de formato modo produtivo-produção para os sistemas. Esta exigência em ação fará proteções contidas a níveis às intenções provindas contra aos ataques a qual produzem vazões do sigilo da níveis e aberturas ao fluxos no referidos baseadas através por vazamentos dos dados que produzem sobre processos das "information-leakage". | 2 | +| **13.4.5** | Verifique se os componentes relativas dos relatórios referentes à publicações por usos dos repositórios contendo bases os quais fornecem, referidas através os quais detalham dos métodos os repasses no detalhamento a nível aos comandos dos manuais referentes sobre guias a referidos do emprego nos módulos referentes de "documentações" do serviços do projetos a processos contidos das operações como através e no exemplos operacionais com chamadas às API baseadas nos setores com atuações restrita do uso relativas ao meio de comunicação do nível local das referidas conexões com a camada por sistemas aos ambientes referentes às redes internas locais -e também relativas aos endereços e também dos nós da estrutura apontadas nas referidas como as terminações de acesso a processos operacionais apontadas nas requisições referidas com o emprego baseados à estrutura referidas a "pontos de contato à análises de métrica operacional - endpoints de observações ou monitoring (monitoring endpoints) das requisições- continuem contidos na segurança a blindadas ao formatos restritos aos quais não operarão baseados as devoluções relativas na exibição por meio e formas ao formatos não expostos nas redes públicas, baseadas as exceções apenas dos processos em rotinas relativas referidas as ordens intencionalmente e, criadas, expressamente de uso provindo explícita de e formal intencionalmente. | 2 | +| **13.4.6** | Verifique se a aplicação não faz divulgações sobre detalhes que fornecem baseadas de acesso nas versões contidas ao nível aos referidos sobre informações das edições ou atualizações no suporte através as instalações sobre números referidos às datas nas informações precisas baseadas na relativas aos componente no processo interno nos que atuem nos sistemas e processos os quais trabalham na camadas a bases operantes das atuações relativas aos fundos do projetos (backend). | 3 | +| **13.4.7** | Verifique se a estrutura os quais controlam aos setores da camadas os processadores relativas contidos ao referidos aos ambientes por servidores com emprego do padrão da linguagem nos protocolos das provedoras web (web tier) operem baseados através das regras contendo parametrização de configurações que os estipulam as relativas normas cuja função atuará por processos no fornecimentos a serviços contendo a aceitações restritas apenas para entrega relativas as permissões contidas, em processos de serviços contendo em arquivos referidas de um modo a base específica relativas as regras às correspondentes restritas e restrições apenas com aceitações correspondentes e de uso relativas de terminações por sufixos no final a processos específicos referentes, com as as extensões com a função em arquivos permitidos definidos para proibir ao processo e devolução provindas e não repassar devolução indesejadas que em perdas sem que tenham a níveis e formato da forma de processos relativas com falhas em informações vazadas; falhas provindas do código aos originais arquivos a que contenham código fontes e perdas das aberturas por configurações internas do local no servidores. | 3 | -## References +## Referências -For more information, see also: +Para mais informações, veja também: -* [OWASP Web Security Testing Guide: Configuration and Deployment Management Testing](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing) +* [OWASP Web Security Testing Guide: Configuration and Deployment Management Testing](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing) \ No newline at end of file diff --git a/5.0/pt/0x23-V14-Data-Protection.md b/5.0/pt/0x23-V14-Data-Protection.md index 1d56e04835..37a4e23e47 100644 --- a/5.0/pt/0x23-V14-Data-Protection.md +++ b/5.0/pt/0x23-V14-Data-Protection.md @@ -1,52 +1,52 @@ -# V14 Data Protection +# V14 Proteção de Dados -## Control Objective +## Objetivo de Controle -Applications cannot account for all usage patterns and user behaviors, and should therefore implement controls to limit unauthorized access to sensitive data on client devices. +As aplicações não conseguem contabilizar todos os padrões de uso e comportamentos dos usuários e devem, portanto, implementar controles para limitar o acesso não autorizado a dados sensíveis nos dispositivos dos clientes. -This chapter includes requirements related to defining what data needs to be protected, how it should be protected, and specific mechanisms to implement or pitfalls to avoid. +Este capítulo inclui requisitos relacionados a definir quais dados precisam ser protegidos, como eles devem ser protegidos e mecanismos específicos a serem implementados ou armadilhas a serem evitadas. -Another consideration for data protection is bulk extraction, modification, or excessive usage. Each system's requirements are likely to be very different, so determining what is "abnormal" must consider the threat model and business risk. From an ASVS perspective, detecting these issues is handled in the "Security Logging and Error Handling" chapter, and setting limits is handled in the "Validation and Business Logic" chapter. +Outra consideração para a proteção de dados é a extração em massa, modificação ou uso excessivo. Os requisitos de cada sistema provavelmente serão muito diferentes, de modo que determinar o que é "anormal" deve levar em consideração o modelo de ameaças e o risco de negócios. Do ponto de vista do ASVS, a detecção desses problemas é tratada no capítulo "Registro de Segurança e Tratamento de Erros" e o estabelecimento de limites é tratado no capítulo "Validação e Lógica de Negócios". -## V14.1 Data Protection Documentation +## V14.1 Documentação de Proteção de Dados -A key prerequisite for being able to protect data is to categorize what data should be considered sensitive. There are likely to be several different levels of sensitivity, and for each level, the controls required to protect data at that level will be different. +Um pré-requisito essencial para conseguir proteger os dados é categorizar quais dados devem ser considerados sensíveis. Provavelmente haverá diferentes níveis de sensibilidade e, para cada nível, os controles necessários para proteger os dados nesse nível serão diferentes. -There are various privacy regulations and laws that affect how applications must approach the storage, use, and transmission of sensitive personal information. This section no longer tries to duplicate these types of data protection or privacy legislation, but rather focuses on key technical considerations for protecting sensitive data. Please consult local laws and regulations, and consult a qualified privacy specialist or lawyer as required. +Existem vários regulamentos e leis de privacidade que afetam a forma como as aplicações devem abordar o armazenamento, uso e transmissão de informações pessoais sensíveis. Esta seção não tenta mais duplicar esses tipos de proteção de dados ou legislação de privacidade, mas foca em considerações técnicas chave para proteger dados sensíveis. Por favor, consulte as leis e regulamentos locais, e consulte um especialista em privacidade qualificado ou um advogado, conforme necessário. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **14.1.1** | Verify that all sensitive data created and processed by the application has been identified and classified into protection levels. This includes data that is only encoded and therefore easily decoded, such as Base64 strings or the plaintext payload inside a JWT. Protection levels need to take into account any data protection and privacy regulations and standards which the application is required to comply with. | 2 | -| **14.1.2** | Verify that all sensitive data protection levels have a documented set of protection requirements. This must include (but not be limited to) requirements related to general encryption, integrity verification, retention, how the data is to be logged, access controls around sensitive data in logs, database-level encryption, privacy and privacy-enhancing technologies to be used, and other confidentiality requirements. | 2 | +| **14.1.1** | Verifique se todos os dados sensíveis criados e processados pela aplicação foram identificados e classificados em níveis de proteção. Isso inclui dados que são apenas codificados e, portanto, facilmente decodificados, como strings Base64 ou a carga (payload) em texto simples (plaintext) dentro de um JWT. Os níveis de proteção precisam levar em consideração quaisquer regulamentações e normas de proteção de dados e privacidade com os quais a aplicação é obrigada a cumprir. | 2 | +| **14.1.2** | Verifique se todos os níveis de proteção de dados sensíveis têm um conjunto documentado de requisitos de proteção. Isso deve incluir (mas não se limitar a) requisitos relacionados a criptografia geral, verificação de integridade, retenção, como os dados devem ser registrados (logged), controles de acesso a dados sensíveis em registros, criptografia em nível de banco de dados, tecnologias de privacidade e melhoria de privacidade a serem usadas e outros requisitos de confidencialidade. | 2 | -## V14.2 General Data Protection +## V14.2 Proteção Geral de Dados -This section contains various practical requirements related to the protection of data. Most are specific to particular issues such as unintended data leakage, but there is also a general requirement to implement protection controls based on the protection level required for each data item. +Esta seção contém vários requisitos práticos relacionados à proteção de dados. A maioria é específica a problemas particulares, como o vazamento de dados não intencional, mas há também um requisito geral para implementar controles de proteção baseados no nível de proteção exigido para cada item de dados. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **14.2.1** | Verify that sensitive data is only sent to the server in the HTTP message body or header fields, and that the URL and query string do not contain sensitive information, such as an API key or session token. | 1 | -| **14.2.2** | Verify that the application prevents sensitive data from being cached in server components, such as load balancers and application caches, or ensures that the data is securely purged after use. | 2 | -| **14.2.3** | Verify that defined sensitive data is not sent to untrusted parties (e.g., user trackers) to prevent unwanted collection of data outside of the application's control. | 2 | -| **14.2.4** | Verify that controls around sensitive data related to encryption, integrity verification, retention, how the data is to be logged, access controls around sensitive data in logs, privacy and privacy-enhancing technologies, are implemented as defined in the documentation for the specific data's protection level. | 2 | -| **14.2.5** | Verify that caching mechanisms are configured to only cache responses which have the expected content type for that resource and do not contain sensitive, dynamic content. The web server should return a 404 or 302 response when a non-existent file is accessed rather than returning a different, valid file. This should prevent Web Cache Deception attacks. | 3 | -| **14.2.6** | Verify that the application only returns the minimum required sensitive data for the application's functionality. For example, only returning some of the digits of a credit card number and not the full number. If the complete data is required, it should be masked in the user interface unless the user specifically views it. | 3 | -| **14.2.7** | Verify that sensitive information is subject to data retention classification, ensuring that outdated or unnecessary data is deleted automatically, on a defined schedule, or as the situation requires. | 3 | -| **14.2.8** | Verify that sensitive information is removed from the metadata of user-submitted files unless storage is consented to by the user. | 3 | +| **14.2.1** | Verifique se dados sensíveis são enviados ao servidor apenas no corpo da mensagem HTTP ou em campos de cabeçalho, e que a URL e a query string (string de consulta) não contenham informações sensíveis, como uma chave de API ou um token de sessão. | 1 | +| **14.2.2** | Verifique se a aplicação evita que dados sensíveis sejam armazenados em cache em componentes do servidor, como balanceadores de carga e caches de aplicação, ou garante que os dados sejam eliminados com segurança após o uso. | 2 | +| **14.2.3** | Verifique se dados sensíveis definidos não são enviados a partes não confiáveis (por exemplo, rastreadores de usuário/user trackers) para prevenir a coleta indesejada de dados fora do controle da aplicação. | 2 | +| **14.2.4** | Verifique se os controles em torno de dados sensíveis relacionados à criptografia, verificação de integridade, retenção, como os dados devem ser registrados (logged), controles de acesso em torno de dados sensíveis em logs, tecnologias de privacidade e melhoria de privacidade, são implementados conforme definido na documentação para o nível de proteção de dados específico. | 2 | +| **14.2.5** | Verifique se os mecanismos de cache são configurados para armazenar em cache apenas respostas que possuam o content type (tipo de conteúdo) esperado para aquele recurso e não contenham conteúdo dinâmico e sensível. O servidor web deve retornar uma resposta 404 ou 302 quando um arquivo inexistente for acessado, em vez de retornar um arquivo válido diferente. Isso deve evitar ataques de Engano de Cache Web (Web Cache Deception attacks). | 3 | +| **14.2.6** | Verifique se a aplicação retorna apenas os dados sensíveis mínimos necessários para a funcionalidade da aplicação. Por exemplo, retornar apenas alguns dos dígitos de um número de cartão de crédito e não o número completo. Se os dados completos forem exigidos, eles deverão ser mascarados na interface do usuário a menos que o usuário os visualize especificamente. | 3 | +| **14.2.7** | Verifique se as informações sensíveis estão sujeitas à classificação de retenção de dados, garantindo que os dados desatualizados ou desnecessários sejam excluídos automaticamente, em um cronograma definido ou conforme a situação exigir. | 3 | +| **14.2.8** | Verifique se as informações sensíveis são removidas dos metadados de arquivos enviados por usuários, a menos que o usuário tenha consentido com o armazenamento. | 3 | -## V14.3 Client-side Data Protection +## V14.3 Proteção de Dados no Lado do Cliente (Client-side) -This section contains requirements preventing data from leaking in specific ways at the client or user agent side of an application. +Esta seção contém requisitos para prevenir que dados vazem de maneiras específicas no lado do cliente ou agente do usuário (user agent) de uma aplicação. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **14.3.1** | Verify that authenticated data is cleared from client storage, such as the browser DOM, after the client or session is terminated. The 'Clear-Site-Data' HTTP response header field may be able to help with this but the client-side should also be able to clear up if the server connection is not available when the session is terminated. | 1 | -| **14.3.2** | Verify that the application sets sufficient anti-caching HTTP response header fields (i.e., Cache-Control: no-store) so that sensitive data is not cached in browsers. | 2 | -| **14.3.3** | Verify that data stored in browser storage (such as localStorage, sessionStorage, IndexedDB, or cookies) does not contain sensitive data, with the exception of session tokens. | 2 | +| **14.3.1** | Verifique se os dados autenticados são apagados do armazenamento do cliente, como o DOM do navegador, após o cliente ou a sessão ser finalizada. O campo de cabeçalho de resposta HTTP 'Clear-Site-Data' pode ajudar com isso, mas o lado do cliente também deve conseguir limpar os dados se a conexão com o servidor não estiver disponível quando a sessão for encerrada. | 1 | +| **14.3.2** | Verifique se a aplicação define campos de cabeçalho de resposta HTTP anticanche adequados (ex., Cache-Control: no-store) para que dados sensíveis não sejam cacheados em navegadores. | 2 | +| **14.3.3** | Verifique se os dados armazenados no armazenamento do navegador (como localStorage, sessionStorage, IndexedDB ou cookies) não contêm dados sensíveis, com exceção de tokens de sessão. | 2 | -## References +## Referências -For more information, see also: +Para mais informações, veja também: * [Consider using the Security Headers website to check security and anti-caching header fields](https://securityheaders.com/) * [Documentation about anti-caching headers by Mozilla](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching) @@ -57,4 +57,4 @@ For more information, see also: * [European Union General Data Protection Regulation (GDPR) overview](https://www.edps.europa.eu/data-protection_en) * [European Union Data Protection Supervisor - Internet Privacy Engineering Network](https://www.edps.europa.eu/data-protection/ipen-internet-privacy-engineering-network_en) * [Information on the "Clear-Site-Data" header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Clear-Site-Data) -* [White paper on Web Cache Deception](https://www.blackhat.com/docs/us-17/wednesday/us-17-Gil-Web-Cache-Deception-Attack-wp.pdf) +* [White paper on Web Cache Deception](https://www.blackhat.com/docs/us-17/wednesday/us-17-Gil-Web-Cache-Deception-Attack-wp.pdf) \ No newline at end of file diff --git a/5.0/pt/0x24-V15-Secure-Coding-and-Architecture.md b/5.0/pt/0x24-V15-Secure-Coding-and-Architecture.md index 4f8ee500f3..3c9f63c682 100644 --- a/5.0/pt/0x24-V15-Secure-Coding-and-Architecture.md +++ b/5.0/pt/0x24-V15-Secure-Coding-and-Architecture.md @@ -1,77 +1,77 @@ -# V15 Secure Coding and Architecture +# V15 Codificação e Arquitetura Seguras -## Control Objective +## Objetivo de Controle -Many ASVS requirements either relate to a particular area of security, such as authentication or authorization, or pertain to a particular type of application functionality, such as logging or file handling. +Muitos requisitos do ASVS se relacionam a uma área particular da segurança, como autenticação ou autorização, ou dizem respeito a um tipo particular de funcionalidade de aplicação, como o registro (logging) ou manipulação de arquivos. -This chapter provides general security requirements to consider when designing and developing applications. These requirements focus not only on clean architecture and code quality but also on specific architecture and coding practices necessary for application security. +Este capítulo fornece requisitos gerais de segurança a serem considerados ao projetar e desenvolver aplicações. Esses requisitos não focam apenas na arquitetura limpa (clean architecture) e qualidade de código, mas também em práticas de arquitetura e codificação específicas necessárias para a segurança da aplicação. -## V15.1 Secure Coding and Architecture Documentation +## V15.1 Documentação de Codificação e Arquitetura Seguras -Many requirements for establishing a secure and defensible architecture depend on clear documentation of decisions made regarding the implementation of specific security controls and the components used within the application. +Muitos requisitos para o estabelecimento de uma arquitetura segura e defensável dependem da documentação clara de decisões feitas a respeito da implementação de controles de segurança específicos e os componentes usados dentro da aplicação. -This section outlines the documentation requirements, including identifying components considered to contain "dangerous functionality" or to be "risky components." +Esta seção descreve os requisitos de documentação, incluindo a identificação de componentes que se considera conter "funcionalidade perigosa" ou ser um "componente de risco". -A component with "dangerous functionality" may be an internally developed or third-party component that performs operations such as deserialization of untrusted data, raw file or binary data parsing, dynamic code execution, or direct memory manipulation. Vulnerabilities in these types of operations pose a high risk of compromising the application and potentially exposing its underlying infrastructure. +Um componente com "funcionalidade perigosa" (dangerous functionality) pode ser um componente desenvolvido internamente ou de terceiros que realiza operações como desserialização de dados não confiáveis, parsing de arquivos raw ou de dados binários, execução dinâmica de código ou manipulação direta de memória. As vulnerabilidades nesses tipos de operações apresentam alto risco de comprometer a aplicação e, potencialmente, de expor a infraestrutura subjacente. -A "risky component" is a 3rd party library (i.e., not internally developed) with missing or poorly implemented security controls around its development processes or functionality. Examples include components that are poorly maintained, unsupported, at the end-of-life stage, or have a history of significant vulnerabilities. +Um "componente de risco" (risky component) é uma biblioteca de terceiros (ou seja, não desenvolvida internamente) onde há falta de controles de segurança, ou estão mal implementados, ao redor dos seus processos de desenvolvimento ou sua funcionalidade. Exemplos incluem os componentes de manutenção deficiente, sem suporte formal, os que se encontram no estágio de ciclo de vida final (end-of-life) e ou possuem histórico atestado referidas em casos notórios relativos no padrão na fraquezas de extrema relevância no descobrimento falhas provindas pelas (significant vulnerabilities). -This section also emphasizes the importance of defining appropriate timeframes for addressing vulnerabilities in third-party components. +Esta seção também enfatiza a importância de se definir prazos de tempo apropriados para lidar com vulnerabilidades em componentes terceiros. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **15.1.1** | Verify that application documentation defines risk based remediation time frames for 3rd party component versions with vulnerabilities and for updating libraries in general, to minimize the risk from these components. | 1 | -| **15.1.2** | Verify that an inventory catalog, such as software bill of materials (SBOM), is maintained of all third-party libraries in use, including verifying that components come from pre-defined, trusted, and continually maintained repositories. | 2 | -| **15.1.3** | Verify that the application documentation identifies functionality which is time-consuming or resource-demanding. This must include how to prevent a loss of availability due to overusing this functionality and how to avoid a situation where building a response takes longer than the consumer's timeout. Potential defenses may include asynchronous processing, using queues, and limiting parallel processes per user and per application. | 2 | -| **15.1.4** | Verify that application documentation highlights third-party libraries which are considered to be "risky components". | 3 | -| **15.1.5** | Verify that application documentation highlights parts of the application where "dangerous functionality" is being used. | 3 | +| **15.1.1** | Verifique se a documentação da aplicação define janelas de tempo de remediação baseadas em risco referentes nas atuações nas as versões baseadas a vulnerabilidades e na forma do controle da documentação relativas provindas nos arquivos em atualizações pelas quais afetam bibliotecas e os usos no geral e também provindas em e relativas em componente terceiro as que contenham referências perante vulnerabilidades, isto visando o ato em e relativas mitigações as relativas aos quais visam as mitigações com redução através minimização provindos nas consequências base aos usos dessas e na forma do processo através aos riscos com danos e perdas aos oriundos no processo e componentes as bases dos processos referentes. | 1 | +| **15.1.2** | Verifique se há processos referidos do qual baseiam no catálogo do tipo em inventário como em sistemas com listas através as referências operacionais base com listagens em arquivos de e materiais com bases referidas as do projeto das bibliotecas contendo aos códigos ou base das relativas dos uso nas listagens através ao (Software Bill of Materials - SBOM), as quais operem a gestão e manutenção a e e aos com o e o controle no registro sob todas referidas bibliotecas (de terceiro) as quais são transacionadas no fluxo referentes por utilidades na uso das ações correntes, isso referenciando o conjunto nas as confirmações aos processos com verificação a que as origens dessas ferramentas a componentes tenham o repasses aos através as origens na de depósitos do padrão referidos base (repositories) operadas confiavelmente sob prévias e de definições as referentes bases de confiáveis manutenções as atuações contínuas (continually maintained). | 2 | +| **15.1.3** | Verifique se a documentação da aplicação identifica funcionalidades que consomem tempo ou exigem muitos recursos. Isso deve incluir maneiras de evitar a perda de disponibilidade devido ao uso excessivo dessa funcionalidade e evitar uma situação em que construir uma resposta leve mais tempo do que o tempo limite (timeout) de resposta ao consumidor. As defesas possíveis podem incluir o processamento assíncrono, uso de filas e imposição nos limites sobre os processos executados no formato os processos ocorrem paralelos (parallel processes) e sob cota em processos definidos por a um processo e níveis referentes a e no máximo limitadas referida "por usuários" por cliente e níveis as taxas totais através o funcionamento e referentes de "aplicações inteiras globais (per application)". | 2 | +| **15.1.4** | Verifique se a documentação da aplicação destaca bibliotecas terceiras a quais com avaliação da gestão de processo operem a serem classificadas a apontamentos com riscos de componentes aos referidos na classe no grupo ao nível "componentes de riscos". | 3 | +| **15.1.5** | Verifique se a documentação da aplicação destaca partes do sistema a aplicação na que a uso no modelo na que atua com o operações através o uso dos processos perante base aos de modelos com as "funcionalidades perigosas (dangerous functionality)" são estarem referidas. | 3 | -## V15.2 Security Architecture and Dependencies +## V15.2 Arquitetura de Segurança e Dependências -This section includes requirements for handling risky, outdated, or insecure dependencies and components through dependency management. +Esta seção inclui requisitos em manuseios referentes por rotinas com processos perante uso através bases às exigência nos sistemas as atuações ao manuseio relativos as atuações contra bases e componentes defasados as, sem suporte, que contém riscos ao atuações referidas de a um processo na ou o formato do processamento referentes ao "manuseio por controle as gestão sob e das e com sobre os acompanhamentos a base relativas às dependências do de códigos (dependency management)". -It also includes using architectural-level techniques such as sandboxing, encapsulation, containerization, and network isolation to reduce the impact of using "dangerous operations" or "risky components" (as defined in the previous section) and prevent loss of availability due to overusing resource-demanding functionality. +Também engloba a adoção referentes as rotinas a através do a respeito na através nas bases provindas aos e com atuações de arquitetura a com as técnicas sobre do do sistema e referentes a como nas execuções sob encapsulamento e isolamento de contêineres e isolamento das em nível de atuações na redes operacionais isto operando visando às com ações atuações referidas em formas reducionais sobre no ao tamanho com atuações de mitigar dos danos causados com e do reflexos nos repasses causados na de usos referentes com relativas bases perante sobre às no a base do modelos das e às na atuações perigosas em o as bases às com formas do perigo na "dangerous operations" nas atuações nas sobre os componentes base ou também no os da bases operantes com processos a riscos de aos os que definimos base do referidos em e como a nas "risky components" nos modelos já na conforme as de e contidas na e a os de referidas nas no formato do contidas os de com formas em na base das referidas definições contidas em e provindas da na base as definições na seção do e na de prévia na base e e do de referentes a prevenção nos de formas referidas as falhas que acarretem e os de aos das perdas provindas às no formas a exaustão às do das nas disponibilidade com bases as originais nas e dos com de das do a em devido nas super os em ou os super os com formas os uso no referidas a com os excessivo sobre funcionalidades com de os a exigência sobre do processamentos ou formas ao grande formas na dos e ou o a do do de do peso e as sobre com da relativas à do processador e de e na com os do consumo em processos. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **15.2.1** | Verify that the application only contains components which have not breached the documented update and remediation time frames. | 1 | -| **15.2.2** | Verify that the application has implemented defenses against loss of availability due to functionality which is time-consuming or resource-demanding, based on the documented security decisions and strategies for this. | 2 | -| **15.2.3** | Verify that the production environment only includes functionality that is required for the application to function, and does not expose extraneous functionality such as test code, sample snippets, and development functionality. | 2 | -| **15.2.4** | Verify that third-party components and all of their transitive dependencies are included from the expected repository, whether internally owned or an external source, and that there is no risk of a dependency confusion attack. | 3 | -| **15.2.5** | Verify that the application implements additional protections around parts of the application which are documented as containing "dangerous functionality" or using third-party libraries considered to be "risky components". This could include techniques such as sandboxing, encapsulation, containerization or network level isolation to delay and deter attackers who compromise one part of an application from pivoting elsewhere in the application. | 3 | +| **15.2.1** | Verifique se a aplicação a apenas a a nas com de nas contém dos os e componentes nas na formas em com que a não a de e de o violaram os limites estipulados e as métricas o do no a os que do sobre contidas a nas do relativas as o das relativas os cronograma do e e as no prazos do na documentação nas sobre relativas no atualizações de bases nas na nos em atualizações com e da com formas em remediação. | 1 | +| **15.2.2** | Verifique se a aplicação implementou relativas a o do e com formas de a nas do da proteções e a sobre defesas da em as no as contidas contra a o com perdas aos relativas nas no a da provindas de da de da perdas as em nas do formas e de as na das perdas os de de na disponibilidade e as a provindas devido ao a uso a da em na em relativas a à e as na na forma com uso com das as funcionalidades a qual com operam o no atuações a consumam de grandes proporções da de e do tempo a na ou a no ou as e que exijam das os a em formas em grandes os na os com e e no da e e as de exigentes grandes em de em consumo de formas de com na nas consumo nas sobre recursos e do a na de e relativas aos de os o da na ao de a e a e de o uso os decisões o da as a os com do das em de da em sobre nas a da em relativas na com base relativas na em das em a os documentadas a as e na formas em no das sobre de na e em a na a na documentadas as nas do do as de as com da em as a na a de no com os de das e a de a no e do a na da e e a na em de as em sobre o e com estratégias com e de e e a na a e e e. | 2 | +| **15.2.3** | Verifique se o de as em ambiente a a da no do em produção a e do de e contém da nas apenas as a da o de e com a na de nas de a com a no funcionalidades de com a na as que de e e em nas em são de e com a e do e da a a e exigidas na nas com e e nas e para do de que do a a a na e o em com de as da em a em do e a da nas de a a a na a e na aplicação a e a da a a nas com e nas a a funcionar de a a e as a com o em com e não e de na de na de de expõe e nas a de e a de e funcionalidades com de e a do as a o de em com na a as a a nas do e e as em e estranhas a a e do e a a de e do as e do e a as e a as do e de o a e (extraneous a a a a functionality) de e na da a o como a na as as e nas e códigos a de a a teste as nas a a e e a e a e e a as e e as e o e a (test a e de code) e nas a na as com em a trechos as a as a e nas as as as na de na e de a a de exemplo a na de a (sample as do a a snippets) e a as as e a nas e o a e e de a e a as de do funcionalidades do e de de a e de a desenvolvimento a de a a. | 2 | +| **15.2.4** | Verifique se na e de os na a de componentes de na de e terceiros na as na e e de na as todas as de as a na de a a de a na as na a as suas dependências do a da a a a transitivas na as são as e de a na na a nas incluídas na as a do na a de repositório da da a de de de a e de esperado na a a as de as seja de a a de a de de e e de ele e de as da as da da internamente de na da a da a na a de e e de a na na de propriedade a e da as da a da as ou a a da na uma da da a e a fonte na a de externa a e as e que a não do a de da há da as as da as e a na na as do as as de a a de risco da a as de a da a da de de de a um as a da as a a ataque as a as de da da a de a e de as da confusão a de a de a da da de a dependência a as de a. | 3 | +| **15.2.5** | Verifique se da as da a da as aplicação de de as e as de implementa da de as da de a de as as proteções do de da de adicionais da em da a da as a torno da a de as da de as a da partes as as da de as as da as da a a a de aplicação a da que de de a a as as as de as a da a são a a de de as as as a a documentadas de a a as como as a da as a as as contendo da de da a de de a a as as a as "funcionalidade as as as as perigosa" a as as de a de a ou as a a as de usando a a a as bibliotecas as as as de as a a de de de terceiros da as de as as as as as consideradas as de as de a as as "componentes a as de a de a de risco". a da as as as de as de Isso da as as a pode de as as a as da incluir as a as as técnicas as as de a a as de a como da as as a a sandboxing, da as a a a da encapsulamento, a as a as as conteinerização da a as as da as da as a as a as ou as da a a a as as a a isolamento as a as a a de de de de nível de da as a a rede as as de de as da a da a para da as de as de a a a as de as da atrasar as de de da a a as e as da a da de a de da a deter da as a a de de de da a atacantes a de de a da de de a de de que a a a a da as de de a a as as de da da comprometem a as de de da as da a de da da uma de da a da de da da de a de de da de parte da de as as da as da da a de de as as da as a uma as as da de a de da de as aplicação da a da da a de de de de a pivotar de de a de da as da as da da as de para as a as as a a de a as outro a as as a da as de de as lugar de da de a da as da a de a as a da a de da da da a as as a na a de de da as de de de da de de da de de da da a aplicação da da a de as a as de as da de de da a as. | 3 | -## V15.3 Defensive Coding +## V15.3 Codificação Defensiva -This section covers vulnerability types, including type juggling, prototype pollution, and others, which result from using insecure coding patterns in a particular language. Some may not be relevant to all languages, whereas others will have language-specific fixes or may relate to how a particular language or framework handles a feature such as HTTP parameters. It also considers the risk of not cryptographically validating application updates. +Esta da da seção as a as de da abrange de da da de de os a de a a da da de da da de a da de de tipos a da as de da de as as de de vulnerabilidade da as da de da de as as da as a de a as da as de as da a (vulnerability da da a types) da as de a da as de a as, de as da de as de as a as da as de da da de as incluindo da a da as de a as da a type as da a a as da a juggling, de da de da da prototype de a as as a a pollution de as de e a da a a de de da da de de as a da de a de a outros da da a as da a da da as a de da, a da a que a as as resultam a de da a a do da de as da de de uso da as as a de a de as as a a padrões as de de de a as de as da a a codificação as as as da de as as a da inseguros de as de de de em as da a da uma da da da as da as de da de de as de da linguagem de de as de de da de as a da as de da particular da as de a a as as as as da as. da de as as de de da a as Alguns da as a de a da as as de podem da da de de a não de a as de ser de a de a de da relevantes de de a para as as de de as todas da as a as de as da linguagens a as da as a de, da a de as da de enquanto da a de a de da a outros a de de de as de a a a a de as da de a de de de terão a a a da de a da da as de as correções de as da de as de de de a de de de as da a específicas de de de a as da da de da de a da da a de a linguagem de a da da as da da ou da a de da da as a de as podem da da as de da de se a de as de as a da relacionar as a a as de de a da a da como da da as de da de da a a da a as de uma de as as as da linguagem a as da de ou as as de da da as a framework a da de a da a a em da a as as particular da a da de de da as a da de as a as as a a lida de de a com da da as da a de a um da as a as a recurso de da as a as a, as de as da de como a da de a as as parâmetros da de a de HTTP a de. da as a a a de de Ele a da de a a de da a da a as as a de de também da de as a de as as de as a de as considera da as a da de o de da da as a a de de a risco a a da de a as de não as as as validar da de as as as a a da as da a de criptograficamente de da a de de as de as atualizações da da a de da as da aplicação. -It also considers the risks associated with using objects to represent data items and accepting and returning these via external APIs. In this case, the application must ensure that data fields that should not be writable are not modified by user input (mass assignment) and that the API is selective about what data fields get returned. Where field access depends on a user's permissions, this should be considered in the context of the field-level access control requirement in the Authorization chapter. +Também da a da as de a a de a a a a considera de as de a os de as as a da de de de a riscos da da de da as associados da da da as a as as a da as a da ao a da da as da de uso de a a de da de as objetos da de de de a para de de da as da de da representar de a de de a as da a da da de da da a de a as a da as da de a de as itens as de as a a a as as de da da dados as a a e de as a da as as de aceitar de as as de a a da da de as a e a da de da as retornar de de a da da de a as as a estes da da a de de as as de através a as a a a da de APIs as da da da as a externas de a de as da a de a a. da as de Neste de de a caso de a de da as a, a a de a as da a a de de da as aplicação da a da da as de a as de deve da as de da de as de de garantir da da de a as que a as a de os da de de de da a campos a da a da de da as da a a as as de da da dados as as as a de de a que de as a da não de as da a a devem a as de ser de as a de as as de da de as a as as a as as graváveis a as a as da (writable) as a da as de a não de de a a as sejam da de de as a a de as modificados as a de as por da a da de as a de a de de as as entrada da as de do da de da usuário de as da as da da as de da de da a de a (mass a as de a a de a as a assignment) de da a a e a a as que de da a a as de da de de da a API de da da seja de da as seletiva da da da sobre de a da de quais a as da a da a de da a a de campos a da de da as de as da as de da as as dados a as de as são as as a da de as retornados as as de. Onde a as da a a a a o as a de acesso as a de a da a da de as a da a a ao da de da campo de da as de de da de de de as depende a da as da as de de da as de de da da as permissões da da da de as as de as as a de um as da da de as da de as usuário de da da as as da as as as de da, a as isso da da de de a de de deve de as a as de da as as de as as as as de de as da a de ser as da de de de da as considerado as as da da da a as a as a de as as a as de as da no de a a a a as contexto a da de as de do da as da de as requisito a a da as de de de a as da a de a a as controle da a de de as as da a as a a as de as as acesso as a da da de em as da a da a nível as a as a da da a a as de da da de da a de de as as as campo as da da a as as as de da as da no da a as da as de as a da as da de as as capítulo de de de da de as as as a as Autorização de. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **15.3.1** | Verify that the application only returns the required subset of fields from a data object. For example, it should not return an entire data object, as some individual fields should not be accessible to users. | 1 | -| **15.3.2** | Verify that where the application backend makes calls to external URLs, it is configured to not follow redirects unless it is intended functionality. | 2 | -| **15.3.3** | Verify that the application has countermeasures to protect against mass assignment attacks by limiting allowed fields per controller and action, e.g., it is not possible to insert or update a field value when it was not intended to be part of that action. | 2 | -| **15.3.4** | Verify that all proxying and middleware components transfer the user's original IP address correctly using trusted data fields that cannot be manipulated by the end user, and the application and web server use this correct value for logging and security decisions such as rate limiting, taking into account that even the original IP address may not be reliable due to dynamic IPs, VPNs, or corporate firewalls. | 2 | -| **15.3.5** | Verify that the application explicitly ensures that variables are of the correct type and performs strict equality and comparator operations. This is to avoid type juggling or type confusion vulnerabilities caused by the application code making an assumption about a variable type. | 2 | -| **15.3.6** | Verify that JavaScript code is written in a way that prevents prototype pollution, for example, by using Set() or Map() instead of object literals. | 2 | -| **15.3.7** | Verify that the application has defenses against HTTP parameter pollution attacks, particularly if the application framework makes no distinction about the source of request parameters (query string, body parameters, cookies, or header fields). | 2 | +| **15.3.1** | Verifique se a aplicação retorna apenas o subconjunto necessário de campos de um objeto de dados. Por exemplo, ela não deve retornar um objeto de dados inteiro, pois alguns campos individuais não devem estar acessíveis aos usuários. | 1 | +| **15.3.2** | Verifique se, nos casos em que o backend da aplicação faz chamadas a URLs externas, ele esteja configurado para não seguir redirecionamentos, a menos que isso seja uma funcionalidade intencional. | 2 | +| **15.3.3** | Verifique se a aplicação possui contramedidas para se proteger contra ataques de atribuição em massa (mass assignment) limitando os campos permitidos por controlador (controller) e ação, por ex., não é possível inserir ou atualizar o valor de um campo quando isso não foi projetado para fazer parte daquela ação. | 2 | +| **15.3.4** | Verifique se todos os componentes de proxy e middleware transferem o endereço IP original do usuário corretamente usando campos de dados confiáveis que não possam ser manipulados pelo usuário final, e a aplicação e o servidor web usam este valor correto para decisões de logging e de segurança como limitação de taxa (rate limiting), levando em conta que mesmo o endereço IP original pode não ser confiável devido a IPs dinâmicos, VPNs ou firewalls corporativos. | 2 | +| **15.3.5** | Verifique se a aplicação garante explicitamente que as variáveis são do tipo correto e realiza operações de comparação e de igualdade estritas (strict equality and comparator operations). Isso é para evitar vulnerabilidades de confusão de tipos (type confusion) ou type juggling causadas pelo código da aplicação fazer uma suposição sobre um tipo de variável. | 2 | +| **15.3.6** | Verifique se o código JavaScript é escrito de uma forma que evita a poluição de protótipo (prototype pollution), por exemplo, usando Set() ou Map() em vez de objetos literais. | 2 | +| **15.3.7** | Verifique se a aplicação possui defesas contra ataques de poluição de parâmetros HTTP (HTTP parameter pollution attacks), particularmente se o framework da aplicação não faz distinção sobre a fonte (source) dos parâmetros de requisição (query string, body parameters, cookies ou campos de cabeçalho). | 2 | -## V15.4 Safe Concurrency +## V15.4 Concorrência Segura -Concurrency issues such as race conditions, time-of-check to time-of-use (TOCTOU) vulnerabilities, deadlocks, livelocks, thread starvation, and improper synchronization can lead to unpredictable behavior and security risks. This section includes various techniques and strategies to help mitigate these risks. +Problemas de concorrência (concurrency) tais como as condições de corrida (race conditions), vulnerabilidades do tipo de tempo-de-verificação-para-o-tempo-de-uso (time-of-check to time-of-use - TOCTOU), deadlocks (bloqueios), livelocks, thread starvation e sincronização inadequada podem levar a comportamento imprevisível e riscos de segurança. Esta seção inclui várias técnicas e estratégias para ajudar a mitigar esses riscos. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **15.4.1** | Verify that shared objects in multi-threaded code (such as caches, files, or in-memory objects accessed by multiple threads) are accessed safely by using thread-safe types and synchronization mechanisms like locks or semaphores to avoid race conditions and data corruption. | 3 | -| **15.4.2** | Verify that checks on a resource's state, such as its existence or permissions, and the actions that depend on them are performed as a single atomic operation to prevent time-of-check to time-of-use (TOCTOU) race conditions. For example, checking if a file exists before opening it, or verifying a user’s access before granting it. | 3 | -| **15.4.3** | Verify that locks are used consistently to avoid threads getting stuck, whether by waiting on each other or retrying endlessly, and that locking logic stays within the code responsible for managing the resource to ensure locks cannot be inadvertently or maliciously modified by external classes or code. | 3 | -| **15.4.4** | Verify that resource allocation policies prevent thread starvation by ensuring fair access to resources, such as by leveraging thread pools, allowing lower-priority threads to proceed within a reasonable timeframe. | 3 | +| **15.4.1** | Verifique se objetos compartilhados em códigos multi-thread (como caches, arquivos ou objetos na memória acessados por várias threads) são acessados ​​de forma segura usando tipos thread-safe e mecanismos de sincronização como locks (travas) ou semáforos para evitar condições de corrida e corrupção de dados. | 3 | +| **15.4.2** | Verifique se as checagens no estado de um recurso, como sua existência ou permissões, e as ações que dependem delas são executadas como uma operação atômica única para evitar as condições de corrida do tipo time-of-check to time-of-use (TOCTOU). Por exemplo, checando se um arquivo existe antes de abri-lo, ou verificando o acesso de um usuário antes de concedê-lo. | 3 | +| **15.4.3** | Verifique se bloqueios (locks) são usados ​​consistentemente para evitar que as threads fiquem presas, seja esperando umas pelas outras ou tentando novamente (retrying) sem parar, e se a lógica de travamento permanece dentro do código responsável por gerenciar o recurso para garantir que os bloqueios não possam ser modificados inadvertidamente ou maliciosamente por classes ou código externo. | 3 | +| **15.4.4** | Verifique se as políticas de alocação de recursos previnem o thread starvation ao garantir o acesso justo (fair access) aos recursos, como, por exemplo, pelo aproveitamento de pools de threads, permitindo que as threads de menor prioridade procedam dentro de um tempo razoável. | 3 | -## References +## Referências -For more information, see also: +Para mais informações, veja também: * [OWASP Prototype Pollution Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Prototype_Pollution_Prevention_Cheat_Sheet.html) * [OWASP Mass Assignment Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Mass_Assignment_Cheat_Sheet.html) * [OWASP CycloneDX Bill of Materials Specification](https://owasp.org/www-project-cyclonedx/) -* [OWASP Web Security Testing Guide: Testing for HTTP Parameter Pollution](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/07-Input_Validation_Testing/04-Testing_for_HTTP_Parameter_Pollution) +* [OWASP Web Security Testing Guide: Testing for HTTP Parameter Pollution](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/07-Input_Validation_Testing/04-Testing_for_HTTP_Parameter_Pollution) \ No newline at end of file diff --git a/5.0/pt/0x25-V16-Security-Logging-and-Error-Handling.md b/5.0/pt/0x25-V16-Security-Logging-and-Error-Handling.md index 4c55c9c4e7..2514941397 100644 --- a/5.0/pt/0x25-V16-Security-Logging-and-Error-Handling.md +++ b/5.0/pt/0x25-V16-Security-Logging-and-Error-Handling.md @@ -1,84 +1,84 @@ -# V16 Security Logging and Error Handling +# V16 Registro de Segurança e Tratamento de Erros -## Control Objective +## Objetivo de Controle -Security logs are distinct from error or performance logs and are used to record security-relevant events such as authentication decisions, access control decisions, and attempts to bypass security controls, such as input validation or business logic validation. Their purpose is to support detection, response, and investigation by providing high-signal, structured data for analysis tools like SIEMs. +Os logs (registros) de segurança são distintos de logs de erro ou de desempenho e são usados para registrar eventos relevantes para a segurança, como decisões de autenticação, decisões de controle de acesso e tentativas de burlar os controles de segurança, como a validação de entrada ou a validação da lógica de negócios. O seu propósito é o de apoiar a detecção, resposta e investigação, fornecendo dados estruturados e de alto sinal (high-signal) para ferramentas de análise, como SIEMs. -Logs should not include sensitive personal data unless legally required, and any logged data must be protected as a high-value asset. Logging must not compromise privacy or system security. Applications must also fail securely, avoiding unnecessary disclosure or disruption. +Os logs não devem incluir dados pessoais sensíveis a menos que exigido legalmente, e quaisquer dados registrados devem ser protegidos como um ativo de alto valor. O registro (logging) não deve comprometer a privacidade ou a segurança do sistema. As aplicações também devem falhar de forma segura (fail securely), evitando divulgação ou interrupção desnecessária. -For detailed implementation guidance, refer to the OWASP Cheat Sheets in the references section. +Para orientações detalhadas de implementação, consulte as OWASP Cheat Sheets na seção de referências. -## V16.1 Security Logging Documentation +## V16.1 Documentação de Registros de Segurança (Security Logging) -This section ensures a clear and complete inventory of logging across the application stack. This is essential for effective security monitoring, incident response, and compliance. +Esta seção garante um inventário claro e completo dos logs em toda a pilha da aplicação (application stack). Isso é essencial para o monitoramento eficaz da segurança, para a resposta a incidentes e a conformidade. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **16.1.1** | Verify that an inventory exists documenting the logging performed at each layer of the application's technology stack, what events are being logged, log formats, where that logging is stored, how it is used, how access to it is controlled, and for how long logs are kept. | 2 | +| **16.1.1** | Verifique se existe um inventário documentando o registro (logging) realizado em cada camada da pilha de tecnologia da aplicação, quais eventos estão sendo registrados, os formatos dos logs, onde esse log é armazenado, como é utilizado, como o acesso a ele é controlado, e por quanto tempo os logs são mantidos. | 2 | -## V16.2 General Logging +## V16.2 Registro (Logging) Geral -This section provides requirements to ensure that security logs are consistently structured and contain the expected metadata. The goal is to make logs machine-readable and analyzable across distributed systems and tools. +Esta seção fornece requisitos para garantir que os logs de segurança sejam estruturados de forma consistente e contenham os metadados esperados. O objetivo é tornar os logs legíveis por máquina e analisáveis em sistemas e ferramentas distribuídas. -Naturally, security events often involve sensitive data. If such data is logged without consideration, the logs themselves become classified and therefore subject to encryption requirements, stricter retention policies, and potential disclosure during audits. +Naturalmente, os eventos de segurança envolvem frequentemente dados sensíveis. Se tais dados forem registrados sem consideração, os próprios logs se tornam classificados e, portanto, sujeitos a requisitos de criptografia, políticas de retenção mais rigorosas e potencial divulgação durante as auditorias. -Therefore, it is critical to log only what is necessary and to treat log data with the same care as other sensitive assets. +Portanto, é crítico registrar apenas o que é necessário e tratar os dados de log com o mesmo cuidado com outros ativos sensíveis. -The requirements below establish foundational requirements for logging metadata, synchronization, format, and control. +Os requisitos abaixo estabelecem os requisitos fundamentais para os metadados de logs, para a sincronização, para o formato e seu controle. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **16.2.1** | Verify that each log entry includes necessary metadata (such as when, where, who, what) that would allow for a detailed investigation of the timeline when an event happens. | 2 | -| **16.2.2** | Verify that time sources for all logging components are synchronized, and that timestamps in security event metadata use UTC or include an explicit time zone offset. UTC is recommended to ensure consistency across distributed systems and to prevent confusion during daylight saving time transitions. | 2 | -| **16.2.3** | Verify that the application only stores or broadcasts logs to the files and services that are documented in the log inventory. | 2 | -| **16.2.4** | Verify that logs can be read and correlated by the log processor that is in use, preferably by using a common logging format. | 2 | -| **16.2.5** | Verify that when logging sensitive data, the application enforces logging based on the data's protection level. For example, it may not be allowed to log certain data, such as credentials or payment details. Other data, such as session tokens, may only be logged by being hashed or masked, either in full or partially. | 2 | +| **16.2.1** | Verifique se cada entrada de log (log entry) inclui os metadados necessários (como quando, onde, quem, o que) que permitiriam uma investigação detalhada da linha do tempo quando um evento acontecer. | 2 | +| **16.2.2** | Verifique se as fontes de tempo para todos os componentes de registro estão sincronizadas, e que os carimbos de data/hora (timestamps) nos metadados do evento de segurança usem UTC ou incluam o deslocamento explícito (offset) do fuso horário. O UTC é recomendado para garantir a consistência através de sistemas distribuídos e para prevenir confusões durante as transições do horário de verão. | 2 | +| **16.2.3** | Verifique se a aplicação apenas armazena ou transmite os logs para os arquivos e serviços que estejam documentados no inventário de logs. | 2 | +| **16.2.4** | Verifique se os logs podem ser lidos e correlacionados pelo processador de log que está em uso, preferencialmente usando um formato de log comum. | 2 | +| **16.2.5** | Verifique se, ao registrar os dados sensíveis, a aplicação impõe o logging baseado no nível de proteção daquele dado. Por exemplo, pode não ser permitido logar determinados dados, como credenciais ou detalhes de pagamento. Outros dados, como os tokens de sessão, podem ser logados apenas ao estarem em hash ou mascarados, de forma total ou parcial. | 2 | -## V16.3 Security Events +## V16.3 Eventos de Segurança -This section defines requirements for logging security-relevant events within the application. Capturing these events is critical for detecting suspicious behavior, supporting investigations, and fulfilling compliance obligations. +Esta seção define os requisitos para registrar os eventos de relevância de segurança dentro da aplicação. Capturar estes eventos é essencial para detectar comportamentos suspeitos, apoiar investigações e cumprir as obrigações de compliance. -This section outlines the types of events that should be logged but does not attempt to provide exhaustive detail. Each application has unique risk factors and operational context. +Esta seção descreve os tipos de eventos que devem ser registrados, mas não tenta fornecer detalhes exaustivos. Toda aplicação possui fatores de risco e o contexto operacional únicos. -Note that while ASVS includes logging of security events in scope, alerting and correlation (e.g., SIEM rules or monitoring infrastructure) are considered out of scope and are handled by operational and monitoring systems. +Observe que, embora o ASVS inclua o registro (logging) de eventos de segurança no escopo, o alerta (alerting) e a correlação (ex., regras de SIEM ou infraestrutura de monitoramento) são considerados fora do escopo e são tratados por sistemas operacionais e de monitoramento. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **16.3.1** | Verify that all authentication operations are logged, including successful and unsuccessful attempts. Additional metadata, such as the type of authentication or factors used, should also be collected. | 2 | -| **16.3.2** | Verify that failed authorization attempts are logged. For L3, this must include logging all authorization decisions, including logging when sensitive data is accessed (without logging the sensitive data itself). | 2 | -| **16.3.3** | Verify that the application logs the security events that are defined in the documentation and also logs attempts to bypass the security controls, such as input validation, business logic, and anti-automation. | 2 | -| **16.3.4** | Verify that the application logs unexpected errors and security control failures such as backend TLS failures. | 2 | +| **16.3.1** | Verifique se todas as operações de autenticação são registradas, incluindo as tentativas bem e malsucedidas. Metadados adicionais, como o tipo de autenticação ou os fatores usados, também deverão ser coletados. | 2 | +| **16.3.2** | Verifique se as tentativas falhas de autorização são registradas. Para o L3, isto deve incluir o registro de todas as decisões da autorização, incluindo o registro quando os dados sensíveis são acessados (sem registrar os dados sensíveis em si). | 2 | +| **16.3.3** | Verifique se a aplicação registra os eventos de segurança que foram definidos na documentação e que também registre as tentativas de ignorar (bypass) os controles de segurança, tais como a validação da entrada, a lógica de negócios e as medidas antiautomação. | 2 | +| **16.3.4** | Verifique se a aplicação registra os erros inesperados e as falhas dos controles de segurança, tais como falhas do TLS no backend. | 2 | -## V16.4 Log Protection +## V16.4 Proteção de Logs -Logs are valuable forensic artifacts and must be protected. If logs can be easily modified or deleted, they lose their integrity and become unreliable for incident investigations or legal proceedings. Logs may expose internal application behavior or sensitive metadata, making them an attractive target for attackers. +Os logs são artefatos forenses valiosos e devem ser protegidos. Se os logs puderem ser facilmente modificados ou excluídos, eles perdem a integridade e tornam-se não confiáveis para as investigações de incidentes ou procedimentos legais. Os logs podem expor o comportamento interno de aplicações ou metadados sensíveis, tornando-os um alvo atraente para os atacantes. -This section defines requirements to ensure that logs are protected from unauthorized access, tampering, and disclosure, and that they are safely transmitted and stored in secure, isolated systems. +Esta seção define os requisitos a fim de garantir que os logs estejam protegidos contra acessos não autorizados, adulterações e as suas divulgações, e que sejam transmitidos de forma segura e armazenados e sistemas seguros e isolados. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **16.4.1** | Verify that all logging components appropriately encode data to prevent log injection. | 2 | -| **16.4.2** | Verify that logs are protected from unauthorized access and cannot be modified. | 2 | -| **16.4.3** | Verify that logs are securely transmitted to a logically separate system for analysis, detection, alerting, and escalation. The aim is to ensure that if the application is breached, the logs are not compromised. | 2 | +| **16.4.1** | Verifique se todos os componentes de logging codificam os dados apropriadamente para evitar a injeção em logs (log injection). | 2 | +| **16.4.2** | Verifique se os logs estão protegidos contra o acesso não autorizado e não podem ser modificados. | 2 | +| **16.4.3** | Verifique se os logs são transmitidos de forma segura para um sistema logicamente isolado e separado para análise, detecção, alerta e encaminhamento (escalation). O objetivo é garantir que, caso a aplicação for invadida, os logs não sejam comprometidos. | 2 | -## V16.5 Error Handling +## V16.5 Tratamento de Erros -This section defines requirements to ensure that applications fail gracefully and securely without disclosing sensitive internal details. +Esta seção define os requisitos para garantir que as aplicações apresentem falhas em forma harmoniosa e contínua de modo seguro (fail gracefully and securely), sem divulgação dos detalhes internos e sensíveis. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **16.5.1** | Verify that a generic message is returned to the consumer when an unexpected or security-sensitive error occurs, ensuring no exposure of sensitive internal system data such as stack traces, queries, secret keys, and tokens. | 2 | -| **16.5.2** | Verify that the application continues to operate securely when external resource access fails, for example, by using patterns such as circuit breakers or graceful degradation. | 2 | -| **16.5.3** | Verify that the application fails gracefully and securely, including when an exception occurs, preventing fail-open conditions such as processing a transaction despite errors resulting from validation logic. | 2 | -| **16.5.4** | Verify that a "last resort" error handler is defined which will catch all unhandled exceptions. This is both to avoid losing error details that must go to log files and to ensure that an error does not take down the entire application process, leading to a loss of availability. | 3 | +| **16.5.1** | Verifique se uma mensagem genérica é retornada ao consumidor perante as falhas quando ocorre um erro inesperado e de impacto na segurança, garantindo assim nenhuma exposição nos dados sensíveis do sistema interno (ex: como stack traces, comandos em queries, senhas chaves dos sistemas de processos, e os tokens em aberto). | 2 | +| **16.5.2** | Verifique se a aplicação continuará a atuar e no processamento em modos segurança perante os eventos das falhas através os acessos na bases dos recursos os de formatos externo e/ou externos a, e no o através a exemplo das chamadas aos os na do dos de processos em do padrões na (patterns) nas das sobre de as os do e com as nos referidos de a no como os a em as os do de de do e "circuit a e a de do breakers" a e na (disjuntores de de da circuitos) as a ou de de em de a degradação e e a harmoniosa da do de (graceful o da degradation). | 2 | +| **16.5.3** | Verifique se a aplicação a a o falha o e a as e e de da da de da de forma as de da de a de de a harmoniosa a o de a de da a e a segura a de da as da (fails e as e as de gracefully da e a de and a as de de securely), as de a a o incluindo as a as o de quando a as e da a a ocorre o a a as uma a a as da a e de a exceção, o de e a da da da prevenindo da de a as a da condições de da as a da o a de da a da de da "fail-open" o da da (falhar a da de de de a de de e de aberto) e a de da as de de como da e a a o a da de processar a de a a as uma da a a a transação de as da a da as apesar a de as de as a da dos de a de da da erros o de de as as resultantes a e da as da a da a lógica de de a da as de de da a a validação da a da as. | 2 | +| **16.5.4** | Verifique se a a a um a a de da de manipulador o a de de a a da as de o as erro a e da as as "de a da as de da as da última o de a da da as de as da a instância" a de de de a as de as (last as a de de as as da as resort) de as de as as as a é as a de a da as de definido da o a a o o que a de de de as as as irá a da a as as capturar da de a a de da as as todas de da as de as a a de de as a da a exceções o a de as de as as de de as da a as não de de da a da de a tratadas. de as de a a de Isto a as da a é a a o as as a a da de a tanto a de de as as a de para as as a de a evitar a a a de de a de as as de a a de de da perder de o de a da da da a as da a detalhes da a a de a do de a a o de da de da a de de as da a as de erro o a da as as da as da que a as as as de as a as de da de devem a de a de de a ir da as da da da de de a de a as de de para da da da de de os o as de arquivos de da de da da de da log, de a de de o a de de e as as a quanto a as da da de as as para as de de de a a as a a de a as as de a garantir as de a as da a que as a da as da a de da da de a um de da a o erro da da da de as de de a a a as as as não de de as a a de o derrube as da a o de o de as as a da da de de todo de da da de de de o as da a de da da a de de de da a processo da a a as de de as da as a as as as a de aplicação, a de de da de o da a a as a a de levando da a da as a da de a de de de da uma da de a as a a de de perda a da de da a as de as a as da de de as disponibilidade a a as a a as da de as a. | 3 | -Note: Certain languages, (including Swift, Go, and through common design practice, many functional languages,) do not support exceptions or last-resort event handlers. In this case, architects and developers should use a pattern, language, or framework-friendly way to ensure that applications can securely handle exceptional, unexpected, or security-related events. +Nota: Determinadas a da as linguagens da da as as, as a as da as de as a (incluindo da de a o da a a Swift, da da da as Go e, a a as de da as da de da de através da da as as a as as a as as a de de de de de de a de as prática de de da de comum de da a as de as as de a as a de de as da as design, de a a as a da a as a muitas da a as de a de de da as a as as a as da as linguagens a de da a da da a de as a da de funcionais, da de da de) de as a a não a a as de de a suportam a de as as a as as de exceções a a a de a de de a de da a de de ou as as de da da a as da de da manipuladores a da da da as a de de de eventos as a da de de de as as da da a as as a de as a de as as última da a a as de as instância de da da de de da da de as as a de a as da da de de a a. as a Neste a de as de de de a caso de a as de a de a da, as da de da arquitetos a as de da da de de a as e a as a de a desenvolvedores de da da a as da as devem a de a da as da a as de a usar da as de a da de da as de de a de de a da da de um da a a da as de padrão a da as de a da as da as a as, as a a linguagem a de a as a da da ou a da as da de da a um da da a da da a a da de de a de da as da da de modo a a a a da a de a a da da de da a amigável as de a da da a a ao de as de as a framework as as as da de as as de a da da da a as de as a a de da para a de as as da as as da as as garantir a as de a da a as a a da as as a da a que a as as as aplicações de de de a a de da da as a as da possam de as as de a de as de de a as as a a a a de as a lidar da de as da de a de da a de a de as de de forma a as as da as a de da a de a de de as segura da a da as com as de as as a eventos as a da de excepcionais a a de a de a da de as as, a a a de a as de as inesperados a a de a a ou a as de da a a as a de de as a da relacionados as da a de da da de a da as da a segurança a da a. -## References +## Referências -For more information, see also: +Para mais informações, veja também: * [OWASP Web Security Testing Guide: Testing for Error Handling](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/README) * [OWASP Authentication Cheat Sheet section about error messages](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html#authentication-and-error-messages) * [OWASP Logging Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html) -* [OWASP Application Logging Vocabulary Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Vocabulary_Cheat_Sheet.html) +* [OWASP Application Logging Vocabulary Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Vocabulary_Cheat_Sheet.html) \ No newline at end of file diff --git a/5.0/pt/0x26-V17-WebRTC.md b/5.0/pt/0x26-V17-WebRTC.md index cf25614600..c7214b5b8f 100644 --- a/5.0/pt/0x26-V17-WebRTC.md +++ b/5.0/pt/0x26-V17-WebRTC.md @@ -1,69 +1,69 @@ # V17 WebRTC -## Control Objective +## Objetivo de Controle -Web Real-Time Communication (WebRTC) enables real-time voice, video, and data exchange in modern applications. As adoption increases, securing WebRTC infrastructure becomes critical. This section provides security requirements for stakeholders who develop, host, or integrate WebRTC systems. +A Comunicação em Tempo Real pela Web (Web Real-Time Communication - WebRTC) possibilita a troca de voz, vídeo e dados em tempo real em aplicações modernas. À medida que a adoção aumenta, a proteção da infraestrutura WebRTC torna-se crítica. Esta seção fornece os requisitos de segurança para as partes interessadas (stakeholders) que desenvolvem, hospedam ou integram os sistemas WebRTC. -The WebRTC market can be broadly categorized into three segments: +O mercado de WebRTC pode ser categorizado em geral em três segmentos: -1. Product Developers: Proprietary and open-source vendors that create and supply WebRTC products and solutions. Their focus is on developing robust and secure WebRTC technologies that can be used by others. +1. Desenvolvedores de Produtos (Product Developers): Fornecedores proprietários ou de código aberto que criam e fornecem soluções e produtos WebRTC. O foco principal é o desenvolvimento de tecnologias WebRTC robustas e seguras que possam ser utilizadas por outras partes. -2. Communication Platforms as a Service (CPaaS): Providers that offer APIs, SDKs, and the necessary infrastructure or platforms to enable WebRTC functionalities. CPaaS providers may use products from the first category or develop their own WebRTC software to offer these services. +2. Plataformas de Comunicação como Serviço (CPaaS): Provedores que ofertam APIs, SDKs e a infraestrutura ou as plataformas necessárias à viabilização de funcionalidades em WebRTC. Os provedores CPaaS poderão utilizar produtos vindos através de primeiro segmento (Desenvolvedores) ou mesmo o fazer na base criadora própria em software pro seu provimento (WebRTC software) e oferecer estes aos serviços (services). -3. Service Providers: Organizations that leverage products from product developers or CPaaS providers, or develop their own WebRTC solutions. They create and implement applications for online conferencing, healthcare, e-learning, and other domains where real-time communication is crucial. +3. Provedores de Serviço (Service Providers): As organizações as quais tiram vantagens de produtos e os integram vindos via desenvolvedores do produto e através CPaaS, ou mesmo realizam próprio seu desenvolvimentos da solução WebRTC. Eles desenvolvem as bases dos ambientes interligados nos quais implementarão a criação de uso, a base no sistema a programas online as salas/ambientes de conferências virtuais em telecomunicações/conferencing, setores em cuidado as redes de tratamento e atendimentos para as bases em saúde, plataformas educacionais de e-learning entre e para as demais demandas aos nichos da atuação de negócios cujo requisito na interconexão e transação por áudio e vídeo requeiram comunicações a meios a atuações em em meios os e usos em transações perante sistemas online operando no momento do processo no tipo de comunicações nos formatos ditos "em tempo real (real-time)". -The security requirements outlined here are primarily focused on Product Developers, CPaaS, and Service Providers who: +Os requisitos em termos às base perante segurança abordadas aqui referenciados estão com enfoque primário de atuação nas proteções aos que figuram nos papeis nas cadeias e nos processos dos Desenvolvedores dos Produto, do grupo no modelo através da CPaaS, além e os Provedores no Serviço a qual operem ao perfil e aos grupos nos quais: -* Utilize open-source solutions to build their WebRTC applications. -* Use commercial WebRTC products as part of their infrastructure. -* Use internally developed WebRTC solutions or integrate various components into a cohesive service offering. +* Façam uso aos componentes nas plataformas da tipo e do base nos modelos através softwares a bases da comunidade/públicos livres - as de código aberto (open-source) à o a o uso em construção em as da e sobre em suas da da aplicação de a em de em WebRTC. +* A de e da em baseiem-se em da produtos comerciais da a o as para e na da WebRTC a na a como nas na em parte no na em as da de o infraestrutura da da o na a de seu e de uso do de o a da a do sistema da a na. +* A em nas façam e as a e uso e da de nas do na de a soluções da da na de a WebRTC do desenvolvidas e a internamente da a do de a a e de as ou em de na de o a integram da de da a o na as em da e a os os vários do da os na da a em do de a a e do e a e na do do e de componentes a da e a em da a de em do de um o de da a do serviço de de a de de da na de a de o o a as da e da da o o coeso de a de do do da. -It is important to note that these security requirements do not apply to developers who exclusively use SDKs and APIs provided by CPaaS vendors. For such developers, the CPaaS providers are typically responsible for most of the underlying security concerns within their platforms, and a generic security standard like ASVS may not fully address their needs. +É a importante de as de o da notar o as do e da na a da de de de o a na e a que e de as da de a de de e de as a da o de e da o da e o a a de a na de a do esses o na e na e do de e da do e requisitos o a e de a na de da de e as na o segurança da e a o da da não da da na de se da a a as e do do a de a do de o do a da e aplicam na da na e de a a da da aos de do as do as e a de da as da de da de e de e a a as desenvolvedores o e e da que as a o e de da e na utilizam o as as o o as e exclusivamente o de e SDKs a da de as o a a as de de o do de da de as a da da a do a da e APIs do as de e fornecidas do e do as de de de a de as por e na do do de da as a fornecedores a de a o de as as a as da CPaaS do as o as de da de. as da de Para as e da na a e na a e do de tais o da a e as as da da a as da a e de a da as desenvolvedores, o da a a as os da de provedores a na a de da o as do as o a da de CPaaS a e na de as as da a as de são as e da do a e as de tipicamente a a as o de as e e de responsáveis da a o a as a de de de a o da de por de as as da as e o da do as de grande e do o as da as da da a as de de da a a as a a a da de parte as de e das da o da da as as do as a de de as as da de de de de a as as preocupações do de a as de as da e a o de e as e as subjacentes a de da de as da de a e o segurança de e a do as a de e as as o da de dentro do de de da de de da de suas as de da e as as o da as de e da de as as da plataformas, do a de de de de a a as e do da a de a e a e a o as um da a da da de a as as padrão as de as as as a de a a da da da as de as genérico o e as e as e de de o da de da de as de e a a as a as segurança a da a e as as a e as as da como as da de da a a as as as da a o da as de a da a a de da as de as de ASVS do da as as pode as de as as de de da a e de a não a as de a a de da as as de as a atender da da da as de as as as e de da da da as a da as da a da as totalmente da as a da da de às de a da a da de as de de da de de da de da a de de de suas as de da a as da da de da as as as as as as de necessidades de as de a as as. -## V17.1 TURN Server +## V17.1 Servidor TURN -This section defines security requirements for systems that operate their own TURN (Traversal Using Relays around NAT) servers. TURN servers assist in relaying media in restrictive network environments but can pose risks if misconfigured. These controls focus on secure address filtering and protection against resource exhaustion. +Esta seção define os requisitos de segurança para sistemas que operam seus próprios servidores TURN (Traversal Using Relays around NAT). Os servidores TURN auxiliam no retransmissão de mídia em ambientes de rede restritivos, mas podem representar riscos se configurados incorretamente. Esses controles se concentram na filtragem segura de endereços e na proteção contra o esgotamento de recursos. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **17.1.1** | Verify that the Traversal Using Relays around NAT (TURN) service only allows access to IP addresses that are not reserved for special purposes (e.g., internal networks, broadcast, loopback). Note that this applies to both IPv4 and IPv6 addresses. | 2 | -| **17.1.2** | Verify that the Traversal Using Relays around NAT (TURN) service is not susceptible to resource exhaustion when legitimate users attempt to open a large number of ports on the TURN server. | 3 | +| **17.1.1** | Verifique se o serviço Traversal Using Relays around NAT (TURN) permite acesso apenas aos endereços IP que não são reservados a propósitos especiais (por exemplo, redes internas, broadcast, loopback). Note que isso se aplica tanto aos endereços IPv4 quanto aos IPv6. | 2 | +| **17.1.2** | Verifique se o serviço Traversal Using Relays around NAT (TURN) não é suscetível ao esgotamento de recursos quando usuários legítimos tentam abrir um grande número de portas no servidor TURN. | 3 | -## V17.2 Media +## V17.2 Mídia -These requirements only apply to systems that host their own WebRTC media servers, such as Selective Forwarding Units (SFUs), Multipoint Control Units (MCUs), recording servers, or gateway servers. Media servers handle and distribute media streams, making their security critical to protect communication between peers. Safeguarding media streams is paramount in WebRTC applications to prevent eavesdropping, tampering, and denial-of-service attacks that could compromise user privacy and communication quality. +Esses requisitos se aplicam apenas aos sistemas que hospedam seus próprios servidores de mídia WebRTC, como Unidades de Encaminhamento Seletivo (Selective Forwarding Units - SFUs), Unidades de Controle Multiponto (Multipoint Control Units - MCUs), servidores de gravação ou servidores de gateway. Os servidores de mídia manipulam e distribuem os streams de mídia, tornando a segurança desses componentes crítica para a proteção da comunicação entre os pares. A salvaguarda dos streams de mídia é fundamental nas aplicações WebRTC para evitar espionagem (eavesdropping), adulteração e ataques de negação de serviço (denial-of-service) que podem comprometer a privacidade do usuário e a qualidade da comunicação. -In particular, it is necessary to implement protections against flood attacks such as rate limiting, validating timestamps, using synchronized clocks to match real-time intervals, and managing buffers to prevent overflow and maintain proper timing. If packets for a particular media session arrive too quickly, excess packets should be dropped. It is also important to protect the system from malformed packets by implementing input validation, safely handling integer overflows, preventing buffer overflows, and employing other robust error-handling techniques. +Em especial, é necessário implementar proteções contra ataques de inundação (flood attacks), tais como limitação de taxa (rate limiting), validação de registros de tempo (timestamps), uso de relógios sincronizados para equiparar intervalos em tempo real e o gerenciamento de buffers para evitar overflow (transbordamento) e manter a sincronia adequada. Se os pacotes de uma sessão de mídia específica chegarem muito rapidamente, os pacotes em excesso deverão ser descartados. Também é importante proteger o sistema de pacotes malformados implementando a validação de entrada, tratando falhas de integer overflow (estouro de número inteiro) de forma segura, impedindo ataques de buffer overflow e empregando outras técnicas robustas de tratamento de erros. -Systems that rely solely on peer-to-peer media communication between web browsers, without the involvement of intermediate media servers, are excluded from these specific media-related security requirements. +Sistemas que dependem puramente da comunicação de mídia peer-to-peer (ponto a ponto) entre navegadores web, sem o envolvimento ou mediação através de servidores de mídia intermediários, estão excluídos desses requisitos de segurança específicos de mídia. -This section refers to the use of Datagram Transport Layer Security (DTLS) in the context of WebRTC. A requirement related to having a documented policy for the management of cryptographic keys can be found in the "Cryptography" chapter. Information on approved cryptographic methods can be found either in the Cryptography Appendix of the ASVS or in documents such as NIST SP 800‑52 Rev. 2 or BSI TR‑02102‑2 (Version 2025‑01). +Esta seção refere-se ao uso de Datagram Transport Layer Security (DTLS) no contexto do WebRTC. Um requisito relacionado a possuir uma política documentada para o gerenciamento de chaves criptográficas pode ser encontrado no capítulo "Criptografia". Informações sobre métodos criptográficos aprovados podem ser encontradas no Apêndice de Criptografia do ASVS ou em documentos como o NIST SP 800‑52 Rev. 2 ou BSI TR‑02102‑2 (Versão 2025‑01). -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **17.2.1** | Verify that the key for the Datagram Transport Layer Security (DTLS) certificate is managed and protected based on the documented policy for management of cryptographic keys. | 2 | -| **17.2.2** | Verify that the media server is configured to use and support approved Datagram Transport Layer Security (DTLS) cipher suites and a secure protection profile for the DTLS Extension for establishing keys for the Secure Real-time Transport Protocol (DTLS-SRTP). | 2 | -| **17.2.3** | Verify that Secure Real-time Transport Protocol (SRTP) authentication is checked at the media server to prevent Real-time Transport Protocol (RTP) injection attacks from leading to either a Denial of Service condition or audio or video media insertion into media streams. | 2 | -| **17.2.4** | Verify that the media server is able to continue processing incoming media traffic when encountering malformed Secure Real-time Transport Protocol (SRTP) packets. | 2 | -| **17.2.5** | Verify that the media server is able to continue processing incoming media traffic during a flood of Secure Real-time Transport Protocol (SRTP) packets from legitimate users. | 3 | -| **17.2.6** | Verify that the media server is not susceptible to the "ClientHello" Race Condition vulnerability in Datagram Transport Layer Security (DTLS) by checking if the media server is publicly known to be vulnerable or by performing the race condition test. | 3 | -| **17.2.7** | Verify that any audio or video recording mechanisms associated with the media server are able to continue processing incoming media traffic during a flood of Secure Real-time Transport Protocol (SRTP) packets from legitimate users. | 3 | -| **17.2.8** | Verify that the Datagram Transport Layer Security (DTLS) certificate is checked against the Session Description Protocol (SDP) fingerprint attribute, terminating the media stream if the check fails, to ensure the authenticity of the media stream. | 3 | +| **17.2.1** | Verifique se a chave para o certificado Datagram Transport Layer Security (DTLS) é gerenciada e protegida com base na política documentada para o gerenciamento de chaves criptográficas. | 2 | +| **17.2.2** | Verifique se o servidor de mídia está configurado para utilizar e suportar as cipher suites aprovadas pelo Datagram Transport Layer Security (DTLS) e um perfil seguro de proteção para a Extensão DTLS a fim de estabelecer as chaves pro Secure Real-time Transport Protocol (DTLS-SRTP). | 2 | +| **17.2.3** | Verifique se a autenticação do Secure Real-time Transport Protocol (SRTP) é checada no servidor de mídia com objetivo de prevenir aos ataques com Injeção da Real-time Transport Protocol (RTP) resultem base perante à seja tanto no formato numa criação com situação relativa em Negações dos Serviços e nas inclusão maliciosa através das inserções referentes de conteúdos de mídias base vídeo ou de áudio dentro aos contínuos percursos provindas das transmissões operadas do sistema aos fluxos contínuos nas mídias originais e legitimas (media streams). | 2 | +| **17.2.4** | Verifique se o servidor de mídia consegue atuar e proceder processando nas execuções aos fluxos operantes com e perante tráfegos recebidos das chamadas através contínuas nas transmissões as mídias ao deparar os pacotes através os formatos inválidos através falhas malformados com proveniências usando Secure Real-time Transport Protocol (SRTP). | 2 | +| **17.2.5** | Verifique se o servidor de mídia tem base operacional operante as quais possibilitem as execuções processando a níveis aos fluxos e as atividades através tráfegos a chamadas contínuas recebidas perante e através ao ataques com eventos por baseados na contínuas envios sucessivos nas bases às inundações (flood) contendo formatos nos chamadas feitas operados contendo a níveis por pacotes usando pelo protocolo tipo e formato por meio do Secure Real-time Transport Protocol (SRTP) os mesmos, através remessas que atestam sendo provindos dos usuários classificados base legítimos. | 3 | +| **17.2.6** | Verifique se o servidor de mídia atua contendo com bases blindados no servidor onde ele não atue no estado ao formato através da vulnerabilidade em condições de vulnerabilidade em corrida "ClientHello" associados e com o tipo da falha das base operantes com atuações de Datagram Transport Layer Security (DTLS). E isso o fazendo referenciando a atuação através nas bases contendo confirmações o qual e caso através o banco dos conhecimento a onde constata com dados através referências publicamente com notório os quais ele opere através contendo as falhas ao ambiente, e através o modo onde façam atuações nas checagens testando através e executando com teste o modo da atuações no testes operando base com teste da a vulnerabilidade tipo Race condition (condição de corrida). | 3 | +| **17.2.7** | Verifique se o mecanismo atuando as quais em processos na forma nas execuções com gravações através vídeos ou na base contendo o uso na formato em do processo a nível contendo gravações de áudio através a embutidas relativas a atuações na base por sistemas do servidores a mídia contenha no formato contendo blindagens operantes a quais permitam a contínua processos em formato na processamentos das contínuas formas nos tráfegos recebidas os operados nas transmissões recebidas referentes as mídias perante atuação provindo sobre e referentes ao baseados nos de inundações em contínuas formas os eventos com contínuas (flood) aos pacotes na base e tipo operando pelo método contendo no pacotes ao através no uso e formato por transmissões a com através Secure Real-time Transport Protocol (SRTP) provindas no atuações vindas no formato perante chamadas ao nível contendo usuários base os formatado legitimados. | 3 | +| **17.2.8** | Verifique se o certificado através as base aos relativas de certificações do Datagram Transport Layer Security (DTLS) é submetido em atuações em checagens na através as comparações operando a formas de de avaliações em bases às relativas contra referidas de atributos nas propriedades das e através e aos atributo do padrão Session Description Protocol (SDP) referente com dados na nas em formato da impressão das a níveis ao das fingerprint, atuando com e ao processamento nas interrupções provindas nas atuações nas desliga contendo desativações às através no corte na formato nos no repasse da atuação no a o contínuos baseados operacionais contendo nos envio aos fluxo em transmissões perante chamadas por uso por nas relativas contidas relativas a caso nas checagens atuantes que contarem em as em através do nível referidos as as apontamentos nas falhas referidas, na formas relativas isso contendo o formato do base no objetivo a garantir e assegurar os dados da as atuações das relativas na autenticidades dos envios perante os fluxos relativas as e do transmissões base da contínua e as de mídia relativas do streams. | 3 | -## V17.3 Signaling +## V17.3 Sinalização -This section defines requirements for systems that operate their own WebRTC signaling servers. Signaling coordinates peer-to-peer communication and must be resilient against attacks that could disrupt session establishment or control. +Esta seção define os requisitos para sistemas que operam seus próprios servidores de sinalização WebRTC. A sinalização coordena a comunicação ponto a ponto (peer-to-peer) e deve ser resiliente contra ataques que podem interromper o estabelecimento ou o controle da sessão. -To ensure secure signaling, systems must handle malformed inputs gracefully and remain available under load. +Para garantir a sinalização segura, os sistemas devem tratar as entradas malformadas de forma harmoniosa e permanecer disponíveis sob carga. -| # | Description | Level | +| # | Descrição | Nível | | :---: | :--- | :---: | -| **17.3.1** | Verify that the signaling server is able to continue processing legitimate incoming signaling messages during a flood attack. This should be achieved by implementing rate limiting at the signaling level. | 2 | -| **17.3.2** | Verify that the signaling server is able to continue processing legitimate signaling messages when encountering malformed signaling message that could cause a denial of service condition. This could include implementing input validation, safely handling integer overflows, preventing buffer overflows, and employing other robust error-handling techniques. | 2 | +| **17.3.1** | Verifique se o servidor de sinalização consegue continuar o processamento de mensagens de sinalização de entrada legítimas durante um ataque de inundação (flood attack). Isso deve ser alcançado implementando a limitação de taxa (rate limiting) no nível de sinalização. | 2 | +| **17.3.2** | Verifique se o servidor de sinalização consegue continuar o processamento de mensagens de sinalização legítimas ao encontrar uma mensagem de sinalização malformada que poderia causar uma condição de negação de serviço. Isso poderia incluir a implementação da validação da entrada (input validation), do tratamento seguro contra estouros de número inteiro (integer overflows), prevenindo estouros de buffer (buffer overflows) e o uso de outras técnicas robustas de tratamento de erros. | 2 | -## References +## Referências -For more information, see also: +Para mais informações, veja também: * The WebRTC DTLS ClientHello DoS is best documented at [Enable Security's blog post aimed at security professionals](https://www.enablesecurity.com/blog/novel-dos-vulnerability-affecting-webrtc-media-servers/) and the associated [white paper aimed at WebRTC developers](https://www.enablesecurity.com/blog/webrtc-hello-race-conditions-paper/) * [RFC 3550 - RTP: A Transport Protocol for Real-Time Applications](https://www.rfc-editor.org/rfc/rfc3550) @@ -72,4 +72,4 @@ For more information, see also: * [RFC 8825 - Overview: Real-Time Protocols for Browser-Based Applications](https://www.rfc-editor.org/info/rfc8825) * [RFC 8826 - Security Considerations for WebRTC](https://www.rfc-editor.org/info/rfc8826) * [RFC 8827 - WebRTC Security Architecture](https://www.rfc-editor.org/info/rfc8827) -* [DTLS-SRTP Protection Profiles](https://www.iana.org/assignments/srtp-protection/srtp-protection.xhtml) +* [DTLS-SRTP Protection Profiles](https://www.iana.org/assignments/srtp-protection/srtp-protection.xhtml) \ No newline at end of file diff --git a/5.0/pt/0x90-Appendix-A_Glossary.md b/5.0/pt/0x90-Appendix-A_Glossary.md index 146baa7b95..f5f466d564 100644 --- a/5.0/pt/0x90-Appendix-A_Glossary.md +++ b/5.0/pt/0x90-Appendix-A_Glossary.md @@ -1,89 +1,89 @@ -# Appendix A: Glossary +# Apêndice A: Glossário -* **Absolute Maximum Session Lifetime** – Also referred to as "Overall Timeout" by NIST, this is the maximal amount of time a session can remain active following authentication regardless of user interaction. This is a component of session expiration. -* **Allowlist** – A list of permitted data or operations, for example, a list of characters that are allowed to perform input validation. -* **Anti-forgery token** – A mechanism by which one or more tokens are passed in a request and validated by the application server to ensure that the request has come from an expected endpoint. -* **Application Security** – Application-level security focuses on the analysis of components that comprise the application layer of the Open Systems Interconnection Reference Model (OSI Model), rather than focusing on for example the underlying operating system or connected networks. -* **Application Security Verification** – The technical assessment of an application against the OWASP ASVS. -* **Application Security Verification Report** – A report that documents the overall results and supporting analysis produced by the verifier for a particular application. -* **Authentication** – The verification of the claimed identity of an application user. -* **Automated Verification** – The use of automated tools (either dynamic analysis tools, static analysis tools, or both) that use vulnerability signatures to find problems. -* **Black box testing** – A method of software testing that examines the functionality of an application without peering into its internal structures or workings. -* **Common Weakness Enumeration** (CWE) – A community-developed list of common software security weaknesses. It serves as a common language, a measuring stick for software security tools, and a baseline for weakness identification, mitigation, and prevention efforts. -* **Component** – A self-contained unit of code, with associated disk and network interfaces that communicates with other components. -* **Credential Service Provider** (CSP) – Also called an Identity Provider (IdP). A source of user data which may be used as an authentication source by other applications. -* **Cross-Site Script Inclusion** (XSSI) - A variant of Cross-Site Scripting (XSS) attack in which a web application retrieves malicious code from an external resource and includes that code as part of its own content. -* **Cross-Site Scripting** (XSS) – A security vulnerability typically found in web applications allowing the injection of client-side scripts into content. -* **Cryptographic module** – Hardware, software, and/or firmware that implements cryptographic algorithms and/or generates cryptographic keys. -* **Cryptographically secure pseudo-random number generator** (CSPRNG) - A pseudorandom number generator with properties that make it suitable for use in cryptography, also referred to as a cryptographic random number generator (CRNG). -* **Datagram Transport Layer Security** (DTLS) – A cryptographic protocol which provides communication security over a network connection. It is based on the TLS protocol but adapted for protecting datagram-oriented protocols (usually over UDP). Defined in RFC 9147 for DTLS 1.3. -* **Datagram Transport Layer Security Extension to Establish Keys for the Secure Real-time Transport Protocol** (DTLS-SRTP) – A mechanism for using a DTLS handshake for establishing key material for a SRTP session. Defined in RFC 5764. -* **Design Verification** – The technical assessment of the security architecture of an application. -* **Dynamic Application Security Testing** (DAST) – Technologies are designed to detect conditions indicative of a security vulnerability in an application in its running state. -* **Dynamic Verification** – The use of automated tools that use vulnerability signatures to find problems during the execution of an application. -* **Fast IDentity Online** (FIDO) – A set of authentication standards that allow a variety of different authentication methods to be used including biometrics, Trusted Platform Modules (TPMs), USB security tokens, etc. -* **Hardware Security Module** (HSM) – Hardware component that stores cryptographic keys and other secrets in a protected manner. -* **Hibernate Query Language** (HQL) – A query language that is similar in appearance to SQL used by the Hibernate ORM library. -* **HTTP Strict Transport Security** (HSTS) – An policy which instructs the browser to only connect to the domain returning the header via TLS and when a valid certificate is presented. It is activated using the Strict-Transport-Security response header field. -* **HyperText Transfer Protocol** (HTTP) – An application protocol for distributed, collaborative, hypermedia information systems. It is the foundation of data communication for the World Wide Web. -* **HyperText Transfer Protocol over SSL/TLS** (HTTPS) – A method of securing HTTP communication by encrypting it using Transport Layer Security (TLS). -* **Identity Provider** (IdP) – Also called a Credential Service Provider (CSP) in NIST references. An entity that provides an authentication source for other applications. -* **Inactivity Timeout** – This is the length of time a session can remain active in the absence of user interaction with the application. This is a component of session expiration. -* **Input Validation** – The canonicalization and validation of untrusted user input. -* **JSON Web Token** (JWT) – RFC 7519 defines a standard for a JSON data object made up of a header section which explains how to validate the object, a body section containing a set of claims, and a signature section which contains a digital signature which can be used to validate the contents of the body section. It is a type of self-contained token. -* **Local File Inclusion** (LFI) - An attack that exploits vulnerable file inclusion procedures in an application, leading to the inclusion of local files already present on the server. -* **Malicious Code** – Code introduced into an application during its development unbeknownst to the application owner, which circumvents the application's intended security policy. Not the same as malware such as a virus or worm! -* **Malware** – Executable code that is introduced into an application during runtime without the knowledge of the application user or administrator. -* **Message authentication code** (MAC) - A cryptographic checksum on data, computed by a MAC generation algorithm, that is used to provide assurance on its integrity and authenticity. -* **Multi-factor authentication** (MFA) – Authentication which includes two or more of the single factors. -* **Mutual TLS** (mTLS) – See TLS client authentication. -* **Object-relational Mapping** (ORM) – A system used to allow a relational/table-based database to be referenced and queried within an application program using an application-compatible object model. -* **One-time Password** (OTP) – A password that is uniquely generated to be used on a single occasion. -* **Open Worldwide Application Security Project** (OWASP) – The Open Worldwide Application Security Project (OWASP) is a worldwide free and open community focused on improving the security of application software. Our mission is to make application security "visible," so that people and organizations can make informed decisions about application security risks. See: [https://www.owasp.org/](https://www.owasp.org/). -* **Password-Based Key Derivation Function 2** (PBKDF2) – A special one-way algorithm used to create a strong cryptographic key from an input text (such as a password) and an additional random salt value and can therefore be used to make it harder to crack a password offline if the resulting value is stored instead of the original password. -* **Public Key Infrastructure** (PKI) – An arrangement that binds public keys with respective identities of entities. The binding is established through a process of registration and issuance of certificates at and by a certificate authority (CA). -* **Public Switched Telephone Network** (PSTN) – The traditional telephone network that includes both fixed-line telephones and mobile telephones. -* **Real-time Transport Protocol** (RTP) and **Real-time Transport Control Protocol** (RTCP) – Two protocols used in association for transporting multimedia streams. Used by the WebRTC stack. Defined in RFC 3550. -* **Reference Token** – A type of token that acts as a pointer or identifier to state or metadata stored on a server, sometimes referred to as random tokens or opaque tokens. Unlike self-contained tokens, which embed some of their relevant data within the token itself, reference tokens contain no intrinsic information, instead relying on the server for context. The reference token will either be or contain a session identifier. -* **Relying Party** (RP) – Generally an application which is relying on a user having authenticated against a separate authentication provider. The application relies on some sort of token or set of signed assertions provided by that authentication provider to trust that the user is who they say they are. -* **Remote File Inclusion** (RFI) - An attack that exploits vulnerable inclusion procedures in the application, resulting in the inclusion of remote files. -* **Scalable Vector Graphics** (SVG) – An XML-based markup language for describing two-dimensional based vector graphics. -* **Secure Real-time Transport Protocol** (SRTP) and **Secure Real-time Transport Control Protocol** (SRTCP) – A profile of the RTP and RTCP protocols providing support for message encryption, authentication and integrity protection. Defined in RFC 3711. -* **Security Architecture** – An abstraction of an application's design that identifies and describes where and how security controls are used, and also identifies and describes the location and sensitivity of both user and application data. -* **Security Assertion Markup Language** (SAML) – An open standard for single sign-on authentication based on passing signed assertions (usually XML objects) between the identity provider and the relying party. -* **Security Configuration** – The runtime configuration of an application that affects how security controls are used. -* **Security Control** – A function or component that performs a security check (e.g., an authorization check) or when called results in a security effect (e.g., generating an audit record). -* **Security information and event management** (SIEM) - A system for threat detection, compliance and security incident management through the collection and analysis of security-related data from various sources within an organization's IT infrastructure. -* **Self-Contained Token** – A token that encapsulates one or more attributes that do not rely on server-side state or other external storage. These tokens ensure the authenticity and integrity of their contained attributes, enabling secure, "stateless" information exchange across systems. Self-contained tokens are generally secured using cryptographic techniques, such as digital signatures or message authentication codes (MACs), to ensure the authenticity, integrity, and in some cases the confidentiality of its data. Common examples include SAML Assertions and JWTs. -* **Server-side Request Forgery** (SSRF) – An attack that abuses functionality on the server to read or update internal resources. The attacker supplies or modifies a URL, which the code running on the server will read or submit data to. -* **Session Description Protocol** (SDP) – A message format for setting up multimedia session (used for example in WebRTC). Defined in RFC 4566. -* **Session Identifier** or **Session ID** – A key which identifies a stateful session stored at the back end. Will be transfered to and from the client either as or inside a "Reference Token". -* **Session Token** – A "catch-all" phrase used in this standard to refer to the token or value used in either stateless session mechanisms (which use a self-contained token) or stateful session mechanisms (which use a reference token). -* **Session Traversal Utilities for NAT** (STUN) – A protocol used to assist NAT traversal in order to establish peer-to-peer communications. Defined in RFC 3489. -* **Single-factor authenticator** – A mechanism to check that a user is authenticated. It should either be something you know (memorized secrets, passwords, passphrases, PINs), something you are (biometrics, fingerprint, face scans), or something you have (OTP tokens, a cryptographic device such as a smart card). -* **Single Sign-on Authentication** (SSO) – This occurs when a user logs into one application and is then automatically logged into other applications without having to re-authenticate. For example, when logging into Google, the user will be automatically logged into other Google services such as YouTube, Google Docs, and Gmail. -* **Software bill of materials** (SBOM) - A structured, comprehensive list of all components, modules, libraries, frameworks and other resources required to build or assemble a software application. -* **Software Composition Analysis** (SCA) – A set of technologies designed to analyze application composition, dependencies, libraries and packages for security vulnerabilities of specific component versions in use. This is not to be confused with source-code analysis which is now commonly referred to as SAST. -* **Software development lifecycle** (SDLC) – The step-by-step process by which software is developed going from the initial requirements to deployment and maintenance. -* **SQL Injection** (SQLi) – A code injection technique used to attack data-driven applications, in which malicious SQL statements are inserted into an entry point. -* **Stateful Session Mechanism** – In a stateful session mechanism, the application retains session state at the backend which typically corresponds to a session token, generated using a cryptographically secure pseudo-random number generator (CSPRNG), which is issued to the end user. -* **Stateless Session Mechanism** – A stateless session mechanism will use a self-contained token which is passed to clients, and contains session information that is not necessarily stored within the service which then receives and validates the token. In reality, a service will need to have access to some session information (such as a JWT revocation list) in order to be able to enforce required security controls. -* **Static application security testing** (SAST) – A set of technologies designed to analyze application source code, byte code and binaries for coding and design conditions that are indicative of security vulnerabilities. SAST solutions analyze an application from the “inside out” in a nonrunning state. -* **Threat Modeling** – A technique consisting of developing increasingly refined security architectures to identify threat agents, security zones, security controls, and important technical and business assets. -* **Time-of-check to time-of-use** (TOCTOU) – A situation where an application checks the state of a resource before using that resource, but the resource's state can be changed between the check and the use. This can invalidate the results of the check and cause a situation where the application performs invalid actions due to this state mismatch. -* **Time based One-time Passwords** (TOTPs) - A method of generating an OTP where the current time acts as part of the algorithm to generate the password. -* **TLS client authentication**, also called **Mutual TLS** (mTLS) – In a standard TLS connection, a client can use the certificate provided by the server to validate the server's identity. Where TLS client authentication is used, the client also uses its own private key and certificate to allow the server to also validate the client's identity. -* **Transport Layer Security** (TLS) – Cryptographic protocols that provide communication security over a network connection. -* **Traversal Using Relays around NAT** (TURN) – An extension of the STUN protocol using a TURN server as a relay when direct peer-to-peer connections cannot be established. Defined in RFC 8656. -* **Trusted execution environment** (TEE) - An isolated processing environment in which applications can be securely executed irrespective of the rest of the system. -* **Trusted Platform Module** (TPM) – A type of HSM that is usually attached to a larger hardware component such as a motherboard and acts as the "root of trust" for that system. -* **Trusted Service Layer** – Any trusted control enforcement point, such as a microservice, serverless API, server-side, a trusted API on a client device that has secure boot, partner or external APIs, and so on. Trusted means that there is no concern that an untrusted user will be able to bypass or skip the layer or controls implemented at that layer. -* **Uniform Resource Identifier** (URI)- A unique string of characters that identifies a resource, such as webpage, mail address, places. -* **Uniform Resource Locator** (URL) – A string that specifies the location of resource on the Internet. -* **Universally Unique Identifier** (UUID) – A unique reference number used as an identifier in software. -* **Verifier** – The person or team that is reviewing an application against the OWASP ASVS requirements. -* **Web Real-Time Communication** (WebRTC) – A protocol stack and associated web API used for the transport of multimedia streams in web applications, usually in the context of teleconferencing. Based on SRTP, SRTCP, DTLS, SDP and STUN/TURN. -* **WebSocket over TLS** (WSS) – A practice of securing WebSocket communication by layering WebSocket over TLS protocol. -* **What You See Is What You Get** (WYSIWYG) – A type of rich content editor that shows how the content will actually look when rendered rather than showing the coding used to govern the rendering. -* **X.509 Certificate** – An X.509 certificate is a digital certificate that uses the widely accepted international X.509 public key infrastructure (PKI) standard to verify that a public key belongs to the user, computer or service identity contained within the certificate. -* **XML eXternal Entity** (XXE) – A type of XML entity that can access local or remote content via a declared system identifier. This may lead to various injection attacks. +* **Absolute Maximum Session Lifetime (Tempo de Vida Máximo Absoluto da Sessão)** – Também referido como "Timeout Geral" pelo NIST, esta é a quantidade máxima de tempo que uma sessão pode permanecer ativa após a autenticação, independentemente da interação do usuário. Este é um componente da expiração da sessão. +* **Allowlist (Lista de Permissões)** – Uma lista de dados ou operações permitidas, por exemplo, uma lista de caracteres que têm permissão para realizar validação de entrada. +* **Anti-forgery token (Token Antifalsificação)** – Um mecanismo pelo qual um ou mais tokens são passados em uma solicitação e validados pelo servidor da aplicação para garantir que a solicitação veio de um endpoint esperado. +* **Application Security (Segurança de Aplicações)** – A segurança em nível de aplicação foca na análise dos componentes que compõem a camada de aplicação do Modelo de Referência de Interconexão de Sistemas Abertos (Modelo OSI), em vez de focar, por exemplo, no sistema operacional subjacente ou nas redes conectadas. +* **Application Security Verification (Verificação de Segurança de Aplicações)** – A avaliação técnica de uma aplicação em relação ao OWASP ASVS. +* **Application Security Verification Report (Relatório de Verificação de Segurança de Aplicações)** – Um relatório que documenta os resultados gerais e a análise de suporte produzida pelo verificador para uma aplicação específica. +* **Authentication (Autenticação)** – A verificação da identidade reivindicada de um usuário da aplicação. +* **Automated Verification (Verificação Automatizada)** – O uso de ferramentas automatizadas (sejam ferramentas de análise dinâmica, ferramentas de análise estática ou ambas) que usam assinaturas de vulnerabilidade para encontrar problemas. +* **Black box testing (Teste de Caixa Preta)** – Um método de teste de software que examina a funcionalidade de uma aplicação sem espiar suas estruturas ou funcionamentos internos. +* **Common Weakness Enumeration (CWE) (Enumeração de Fraquezas Comuns)** – Uma lista desenvolvida pela comunidade de fraquezas comuns de segurança de software. Serve como uma linguagem comum, uma régua de medição para ferramentas de segurança de software e uma linha de base (baseline) para esforços de identificação, mitigação e prevenção de fraquezas. +* **Component (Componente)** – Uma unidade autônoma de código, com interfaces de disco e rede associadas, que se comunica com outros componentes. +* **Credential Service Provider (CSP) (Provedor de Serviços de Credenciais)** – Também chamado de Provedor de Identidade (IdP). Uma fonte de dados de usuário que pode ser usada como fonte de autenticação por outras aplicações. +* **Cross-Site Script Inclusion (XSSI) (Inclusão de Script Entre Sites)** - Uma variante do ataque de Cross-Site Scripting (XSS) na qual uma aplicação web recupera código malicioso de um recurso externo e inclui esse código como parte de seu próprio conteúdo. +* **Cross-Site Scripting (XSS)** – Uma vulnerabilidade de segurança tipicamente encontrada em aplicações web que permite a injeção de scripts no lado do cliente (client-side) dentro do conteúdo. +* **Cryptographic module (Módulo Criptográfico)** – Hardware, software e/ou firmware que implementa algoritmos criptográficos e/ou gera chaves criptográficas. +* **Cryptographically secure pseudo-random number generator (CSPRNG) (Gerador de Números Pseudoaleatórios Criptograficamente Seguro)** - Um gerador de números pseudoaleatórios com propriedades que o tornam adequado para uso em criptografia, também referido como gerador de números aleatórios criptográficos (CRNG). +* **Datagram Transport Layer Security (DTLS)** – Um protocolo criptográfico que fornece segurança de comunicação em uma conexão de rede. É baseado no protocolo TLS, mas adaptado para proteger protocolos orientados a datagramas (geralmente sobre UDP). Definido na RFC 9147 para o DTLS 1.3. +* **Datagram Transport Layer Security Extension to Establish Keys for the Secure Real-time Transport Protocol (DTLS-SRTP)** – Um mecanismo para usar um handshake DTLS para estabelecer material criptográfico para uma sessão SRTP. Definido na RFC 5764. +* **Design Verification (Verificação de Design)** – A avaliação técnica da arquitetura de segurança de uma aplicação. +* **Dynamic Application Security Testing (DAST) (Teste Dinâmico de Segurança de Aplicações)** – Tecnologias projetadas para detectar condições indicativas de uma vulnerabilidade de segurança em uma aplicação em seu estado de execução. +* **Dynamic Verification (Verificação Dinâmica)** – O uso de ferramentas automatizadas que usam assinaturas de vulnerabilidades para encontrar problemas durante a execução de uma aplicação. +* **Fast IDentity Online (FIDO)** – Um conjunto de padrões de autenticação que permite o uso de uma variedade de métodos de autenticação diferentes, incluindo biometria, Trusted Platform Modules (TPMs), tokens de segurança USB, etc. +* **Hardware Security Module (HSM) (Módulo de Segurança de Hardware)** – Componente de hardware que armazena chaves criptográficas e outros segredos de maneira protegida. +* **Hibernate Query Language (HQL)** – Uma linguagem de consulta de aparência semelhante ao SQL usada pela biblioteca Hibernate ORM. +* **HTTP Strict Transport Security (HSTS)** – Uma política que instrui o navegador a conectar-se apenas ao domínio que retorna o cabeçalho via TLS e quando um certificado válido é apresentado. É ativada usando o campo de cabeçalho de resposta Strict-Transport-Security. +* **HyperText Transfer Protocol (HTTP) (Protocolo de Transferência de Hipertexto)** – Um protocolo de aplicação para sistemas de informação hipermídia, colaborativos e distribuídos. É a base da comunicação de dados para a World Wide Web. +* **HyperText Transfer Protocol over SSL/TLS (HTTPS)** – Um método de proteger a comunicação HTTP criptografando-a usando o Transport Layer Security (TLS). +* **Identity Provider (IdP) (Provedor de Identidade)** – Também chamado de Credential Service Provider (CSP) nas referências do NIST. Uma entidade que fornece uma fonte de autenticação para outras aplicações. +* **Inactivity Timeout (Tempo Limite de Inatividade)** – Este é o período de tempo que uma sessão pode permanecer ativa na ausência de interação do usuário com a aplicação. Este é um componente da expiração da sessão. +* **Input Validation (Validação de Entrada)** – A canonicalização e validação de entradas de usuários não confiáveis. +* **JSON Web Token (JWT)** – A RFC 7519 define um padrão para um objeto de dados JSON composto por uma seção de cabeçalho (header) que explica como validar o objeto, uma seção de corpo (body) contendo um conjunto de reivindicações (claims) e uma seção de assinatura (signature) que contém uma assinatura digital que pode ser usada para validar o conteúdo da seção do corpo. É um tipo de token autocontido. +* **Local File Inclusion (LFI) (Inclusão de Arquivo Local)** - Um ataque que explora procedimentos vulneráveis de inclusão de arquivos em uma aplicação, levando à inclusão de arquivos locais já presentes no servidor. +* **Malicious Code (Código Malicioso)** – Código introduzido em uma aplicação durante o seu desenvolvimento, sem o conhecimento do proprietário da aplicação, que burla (circumvents) a política de segurança pretendida para a aplicação. Não é o mesmo que malware, como um vírus ou worm! +* **Malware** – Código executável que é introduzido em uma aplicação durante a execução (runtime) sem o conhecimento do usuário ou administrador da aplicação. +* **Message authentication code (MAC) (Código de Autenticação de Mensagem)** - Um checksum criptográfico em dados, calculado por um algoritmo de geração de MAC, que é usado para fornecer garantia sobre sua integridade e autenticidade. +* **Multi-factor authentication (MFA) (Autenticação Multifator)** – Autenticação que inclui dois ou mais dos fatores únicos. +* **Mutual TLS (mTLS) (TLS Mútuo)** – Veja autenticação de cliente TLS. +* **Object-relational Mapping (ORM) (Mapeamento Objeto-Relacional)** – Um sistema usado para permitir que um banco de dados relacional/baseado em tabelas seja referenciado e consultado dentro de um programa de aplicação usando um modelo de objeto compatível com a aplicação. +* **One-time Password (OTP) (Senha de Uso Único)** – Uma senha que é gerada de forma única para ser usada em uma única ocasião. +* **Open Worldwide Application Security Project (OWASP)** – O Open Worldwide Application Security Project (OWASP) é uma comunidade mundial livre e aberta com foco em melhorar a segurança de softwares aplicativos. Nossa missão é tornar a segurança de aplicações "visível", para que pessoas e organizações possam tomar decisões informadas sobre os riscos de segurança de aplicações. Veja: [https://www.owasp.org/](https://www.owasp.org/). +* **Password-Based Key Derivation Function 2 (PBKDF2)** – Um algoritmo especial unidirecional usado para criar uma chave criptográfica forte a partir de um texto de entrada (como uma senha) e um valor aleatório adicional (salt), podendo, portanto, ser usado para dificultar a quebra (crack) de uma senha offline se o valor resultante for armazenado em vez da senha original. +* **Public Key Infrastructure (PKI) (Infraestrutura de Chave Pública)** – Um arranjo que vincula chaves públicas às respectivas identidades das entidades. O vínculo é estabelecido através de um processo de registro e emissão de certificados em e por uma autoridade de certificação (CA). +* **Public Switched Telephone Network (PSTN) (Rede Telefônica Pública Comutada)** – A rede telefônica tradicional que inclui tanto telefones fixos quanto telefones móveis. +* **Real-time Transport Protocol (RTP)** e **Real-time Transport Control Protocol (RTCP)** – Dois protocolos usados em associação para o transporte de streams multimídia. Usados pela pilha WebRTC. Definidos na RFC 3550. +* **Reference Token (Token de Referência)** – Um tipo de token que atua como um ponteiro ou identificador para estado ou metadados armazenados em um servidor, às vezes chamados de tokens aleatórios ou tokens opacos. Ao contrário dos tokens autocontidos, que embutem parte de seus dados relevantes dentro do próprio token, os tokens de referência não contêm informações intrínsecas, dependendo do servidor para obter o contexto. O token de referência será ou conterá um identificador de sessão. +* **Relying Party (RP) (Parte Confiável)** – Geralmente uma aplicação que confia em um usuário que se autenticou em um provedor de autenticação separado. A aplicação depende de algum tipo de token ou conjunto de asserções assinadas fornecidas por esse provedor de autenticação para confiar que o usuário é quem diz ser. +* **Remote File Inclusion (RFI) (Inclusão Remota de Arquivo)** - Um ataque que explora procedimentos de inclusão vulneráveis na aplicação, resultando na inclusão de arquivos remotos. +* **Scalable Vector Graphics (SVG)** – Uma linguagem de marcação baseada em XML para descrever gráficos vetoriais bidimensionais. +* **Secure Real-time Transport Protocol (SRTP)** e **Secure Real-time Transport Control Protocol (SRTCP)** – Um perfil dos protocolos RTP e RTCP fornecendo suporte para criptografia de mensagens, autenticação e proteção de integridade. Definido na RFC 3711. +* **Security Architecture (Arquitetura de Segurança)** – Uma abstração do design de uma aplicação que identifica e descreve onde e como os controles de segurança são usados, e também identifica e descreve a localização e a sensibilidade dos dados do usuário e da aplicação. +* **Security Assertion Markup Language (SAML)** – Um padrão aberto para autenticação de logon único (single sign-on) com base na passagem de asserções assinadas (geralmente objetos XML) entre o provedor de identidade e a relying party. +* **Security Configuration (Configuração de Segurança)** – A configuração de tempo de execução (runtime) de uma aplicação que afeta como os controles de segurança são usados. +* **Security Control (Controle de Segurança)** – Uma função ou componente que realiza uma verificação de segurança (por exemplo, uma verificação de autorização) ou que, quando chamado, resulta em um efeito de segurança (por exemplo, a geração de um registro de auditoria). +* **Security information and event management (SIEM) (Gerenciamento de Informações e Eventos de Segurança)** - Um sistema para detecção de ameaças, conformidade e gerenciamento de incidentes de segurança através da coleta e análise de dados relacionados à segurança de várias fontes dentro da infraestrutura de TI de uma organização. +* **Self-Contained Token (Token Autocontido)** – Um token que encapsula um ou mais atributos que não dependem do estado no lado do servidor (server-side state) ou de outro armazenamento externo. Esses tokens garantem a autenticidade e a integridade de seus atributos contidos, permitindo a troca segura e "sem estado" (stateless) de informações entre sistemas. Os tokens autocontidos geralmente são protegidos usando técnicas criptográficas, como assinaturas digitais ou códigos de autenticação de mensagens (MACs), para garantir a autenticidade, a integridade e, em alguns casos, a confidencialidade de seus dados. Exemplos comuns incluem as Asserções SAML e os JWTs. +* **Server-side Request Forgery (SSRF) (Falsificação de Solicitação do Lado do Servidor)** – Um ataque que abusa da funcionalidade no servidor para ler ou atualizar recursos internos. O atacante fornece ou modifica uma URL, da qual o código em execução no servidor lerá ou submeterá dados. +* **Session Description Protocol (SDP)** – Um formato de mensagem para configurar sessões multimídia (usado, por exemplo, no WebRTC). Definido na RFC 4566. +* **Session Identifier ou Session ID (Identificador de Sessão)** – Uma chave que identifica uma sessão stateful armazenada no backend. Será transferida de e para o cliente como um "Token de Referência" ou dentro dele. +* **Session Token (Token de Sessão)** – Uma frase genérica (catch-all) usada neste padrão para se referir ao token ou valor usado em mecanismos de sessão sem estado/stateless (que usam um token autocontido) ou em mecanismos de sessão stateful (que usam um token de referência). +* **Session Traversal Utilities for NAT (STUN)** – Um protocolo usado para auxiliar a travessia de NAT a fim de estabelecer comunicações ponto a ponto (peer-to-peer). Definido na RFC 3489. +* **Single-factor authenticator (Autenticador de fator único)** – Um mecanismo para verificar se um usuário está autenticado. Deve ser algo que você sabe (segredos memorizados, senhas, frases secretas, PINs), algo que você é (biometria, impressão digital, escaneamento facial) ou algo que você possui (tokens OTP, um dispositivo criptográfico como um smart card). +* **Single Sign-on Authentication (SSO) (Autenticação de Logon Único)** – Isso ocorre quando um usuário faz login em uma aplicação e, em seguida, é automaticamente logado em outras aplicações sem ter que se reautenticar. Por exemplo, ao fazer login no Google, o usuário será logado automaticamente em outros serviços do Google, como YouTube, Google Docs e Gmail. +* **Software bill of materials (SBOM) (Lista de Materiais de Software)** - Uma lista estruturada e abrangente de todos os componentes, módulos, bibliotecas, frameworks e outros recursos necessários para construir ou montar uma aplicação de software. +* **Software Composition Analysis (SCA) (Análise de Composição de Software)** – Um conjunto de tecnologias projetadas para analisar a composição de aplicações, dependências, bibliotecas e pacotes em busca de vulnerabilidades de segurança de versões de componentes específicos em uso. Isso não deve ser confundido com a análise de código-fonte, que agora é comumente referida como SAST. +* **Software development lifecycle (SDLC) (Ciclo de Vida de Desenvolvimento de Software)** – O processo passo a passo pelo qual o software é desenvolvido, indo desde os requisitos iniciais até a implantação e manutenção. +* **SQL Injection (SQLi) (Injeção de SQL)** – Uma técnica de injeção de código usada para atacar aplicações orientadas a dados, na qual instruções SQL maliciosas são inseridas em um ponto de entrada. +* **Stateful Session Mechanism (Mecanismo de Sessão Stateful)** – Em um mecanismo de sessão stateful, a aplicação retém o estado da sessão no backend, o qual normalmente corresponde a um token de sessão, gerado usando um gerador de números pseudoaleatórios criptograficamente seguro (CSPRNG), que é emitido para o usuário final. +* **Stateless Session Mechanism (Mecanismo de Sessão Sem Estado/Stateless)** – Um mecanismo de sessão sem estado usará um token autocontido que é passado aos clientes e contém informações de sessão que não são necessariamente armazenadas no serviço que, em seguida, recebe e valida o token. Na realidade, um serviço precisará ter acesso a algumas informações de sessão (como uma lista de revogação de JWT) para ser capaz de impor os controles de segurança exigidos. +* **Static application security testing (SAST) (Teste Estático de Segurança de Aplicações)** – Um conjunto de tecnologias projetadas para analisar o código-fonte da aplicação, byte code e binários em busca de condições de codificação e de design que sejam indicativas de vulnerabilidades de segurança. As soluções SAST analisam uma aplicação de "dentro para fora" em um estado não executável. +* **Threat Modeling (Modelagem de Ameaças)** – Uma técnica que consiste em desenvolver arquiteturas de segurança cada vez mais refinadas para identificar agentes de ameaça, zonas de segurança, controles de segurança e ativos técnicos e de negócios importantes. +* **Time-of-check to time-of-use (TOCTOU) (Tempo-de-verificação-para-o-tempo-de-uso)** – Uma situação em que uma aplicação verifica o estado de um recurso antes de usar esse recurso, mas o estado do recurso pode ser alterado entre a verificação e o uso. Isso pode invalidar os resultados da verificação e causar uma situação em que a aplicação realiza ações inválidas devido a essa incompatibilidade de estado. +* **Time based One-time Passwords (TOTPs) (Senhas de Uso Único Baseadas em Tempo)** - Um método de gerar uma OTP onde o tempo atual age como parte do algoritmo para gerar a senha. +* **TLS client authentication (Autenticação de Cliente TLS)**, também chamada de **Mutual TLS (mTLS) (TLS Mútuo)** – Em uma conexão TLS padrão, um cliente pode usar o certificado fornecido pelo servidor para validar a identidade do servidor. Onde a autenticação de cliente TLS é usada, o cliente também usa sua própria chave privada e certificado para permitir que o servidor também valide a identidade do cliente. +* **Transport Layer Security (TLS)** – Protocolos criptográficos que fornecem segurança de comunicação através de uma conexão de rede. +* **Traversal Using Relays around NAT (TURN)** – Uma extensão do protocolo STUN usando um servidor TURN como um retransmissor (relay) quando conexões diretas peer-to-peer não podem ser estabelecidas. Definido na RFC 8656. +* **Trusted execution environment (TEE) (Ambiente de Execução Confiável)** - Um ambiente de processamento isolado no qual aplicações podem ser executadas com segurança, independentemente do resto do sistema. +* **Trusted Platform Module (TPM) (Módulo de Plataforma Confiável)** – Um tipo de HSM que geralmente está anexado a um componente de hardware maior, como uma placa-mãe, e atua como a "raiz de confiança" (root of trust) daquele sistema. +* **Trusted Service Layer (Camada de Serviço Confiável)** – Qualquer ponto de imposição de controle confiável, como um microsserviço, API serverless, lado do servidor, uma API confiável em um dispositivo cliente que possua inicialização segura (secure boot), APIs de parceiros ou externas, e assim por diante. Confiável significa que não há preocupação de que um usuário não confiável será capaz de ignorar ou pular a camada ou os controles implementados naquela camada. +* **Uniform Resource Identifier (URI) (Identificador Uniforme de Recurso)**- Uma sequência única de caracteres que identifica um recurso, como página da web, endereço de correio, locais. +* **Uniform Resource Locator (URL) (Localizador Uniforme de Recursos)** – Uma string que especifica a localização do recurso na Internet. +* **Universally Unique Identifier (UUID) (Identificador Universalmente Único)** – Um número de referência único usado como identificador em software. +* **Verifier (Verificador)** – A pessoa ou equipe que está revisando uma aplicação em relação aos requisitos do OWASP ASVS. +* **Web Real-Time Communication (WebRTC) (Comunicação em Tempo Real pela Web)** – Uma pilha de protocolos e API da web associada usada para o transporte de fluxos multimídia em aplicações web, geralmente no contexto de teleconferências. Baseado em SRTP, SRTCP, DTLS, SDP e STUN/TURN. +* **WebSocket over TLS (WSS)** – A prática de proteger a comunicação de WebSocket embutindo (layering) o WebSocket sobre o protocolo TLS. +* **What You See Is What You Get (WYSIWYG) (O Que Você Vê É O Que Você Obtém)** – Um tipo de editor de conteúdo rico (rich content) que mostra como o conteúdo realmente parecerá ao ser renderizado, em vez de mostrar a codificação usada para governar a renderização. +* **X.509 Certificate (Certificado X.509)** – Um certificado X.509 é um certificado digital que usa o amplamente aceito padrão internacional de infraestrutura de chaves públicas (PKI) X.509 para verificar que uma chave pública pertence à identidade do usuário, computador ou serviço contida no certificado. +* **XML eXternal Entity (XXE) (Entidade Externa XML)** – Um tipo de entidade XML que pode acessar conteúdo local ou remoto por meio de um identificador de sistema declarado. Isso pode levar a vários ataques de injeção. \ No newline at end of file diff --git a/5.0/pt/0x91-Appendix-B_References.md b/5.0/pt/0x91-Appendix-B_References.md index a0fdd1babb..e84462feb4 100644 --- a/5.0/pt/0x91-Appendix-B_References.md +++ b/5.0/pt/0x91-Appendix-B_References.md @@ -1,8 +1,8 @@ -# Appendix B: References +# Apêndice B: Referências -The following OWASP projects are most likely to be useful to users/adopters of this standard: +Os seguintes projetos da OWASP provavelmente serão mais úteis aos usuários/adotantes deste padrão: -## OWASP Core Projects +## Projetos Principais da OWASP (Core Projects) 1. OWASP Top 10 Project: [https://owasp.org/www-project-top-ten/](https://owasp.org/www-project-top-ten/) 2. OWASP Web Security Testing Guide: [https://owasp.org/www-project-web-security-testing-guide/](https://owasp.org/www-project-web-security-testing-guide/) @@ -10,29 +10,29 @@ The following OWASP projects are most likely to be useful to users/adopters of t 4. OWASP Software Assurance Maturity Model (SAMM): [https://owasp.org/www-project-samm/](https://owasp.org/www-project-samm/) 5. OWASP Secure Headers Project: [https://owasp.org/www-project-secure-headers/](https://owasp.org/www-project-secure-headers/) -## OWASP Cheat Sheet Series project +## Projeto OWASP Cheat Sheet Series -[This project](https://owasp.org/www-project-cheat-sheets/) has several cheat sheets that will be relevant to different topics in the ASVS. +[Este projeto](https://owasp.org/www-project-cheat-sheets/) possui várias folhas de dicas (cheat sheets) que serão relevantes para diferentes tópicos no ASVS. -There is a mapping to the ASVS which can be found here: [https://cheatsheetseries.owasp.org/IndexASVS.html](https://cheatsheetseries.owasp.org/IndexASVS.html) +Existe um mapeamento para o ASVS que pode ser encontrado aqui: [https://cheatsheetseries.owasp.org/IndexASVS.html](https://cheatsheetseries.owasp.org/IndexASVS.html) -## Mobile Security Related Projects +## Projetos Relacionados à Segurança Mobile 1. OWASP Mobile Security Project: [https://owasp.org/www-project-mobile-security/](https://owasp.org/www-project-mobile-security/) 2. OWASP Mobile Top 10 Risks: [https://owasp.org/www-project-mobile-top-10/](https://owasp.org/www-project-mobile-top-10/) -3. OWASP Mobile Security Testing Guide and Mobile Application Security Verification Standard: [https://owasp.org/www-project-mobile-security-testing-guide/](https://owasp.org/www-project-mobile-security-testing-guide/) +3. OWASP Mobile Security Testing Guide e Mobile Application Security Verification Standard: [https://owasp.org/www-project-mobile-security-testing-guide/](https://owasp.org/www-project-mobile-security-testing-guide/) -## OWASP Internet of Things related projects +## Projetos Relacionados à Internet das Coisas (IoT) da OWASP 1. OWASP Internet of Things Project: [https://owasp.org/www-project-internet-of-things/](https://owasp.org/www-project-internet-of-things/) -## OWASP Serverless projects +## Projetos Serverless da OWASP 1. OWASP Serverless Project: [https://owasp.org/www-project-serverless-top-10/](https://owasp.org/www-project-serverless-top-10/) -## Others +## Outros -Similarly, the following websites are most likely to be useful to users/adopters of this standard +Da mesma forma, os seguintes sites provavelmente serão úteis aos usuários/adotantes deste padrão: 1. SecLists Github: [https://github.com/danielmiessler/SecLists](https://github.com/danielmiessler/SecLists) 2. MITRE Common Weakness Enumeration: [https://cwe.mitre.org/](https://cwe.mitre.org/) @@ -40,4 +40,4 @@ Similarly, the following websites are most likely to be useful to users/adopters 4. PCI Data Security Standard (DSS) v3.2.1 Requirements and Security Assessment Procedures: [https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf](https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf) 5. PCI Software Security Framework - Secure Software Requirements and Assessment Procedures: [https://www.pcisecuritystandards.org/documents/PCI-Secure-Software-Standard-v1_0.pdf](https://www.pcisecuritystandards.org/documents/PCI-Secure-Software-Standard-v1_0.pdf) 6. PCI Secure Software Lifecycle (Secure SLC) Requirements and Assessment Procedures: [https://www.pcisecuritystandards.org/documents/PCI-Secure-SLC-Standard-v1_0.pdf](https://www.pcisecuritystandards.org/documents/PCI-Secure-SLC-Standard-v1_0.pdf) -7. OWASP ASVS 4.0 Testing Guide [https://github.com/BlazingWind/OWASP-ASVS-4.0-testing-guide](https://github.com/BlazingWind/OWASP-ASVS-4.0-testing-guide) +7. OWASP ASVS 4.0 Testing Guide [https://github.com/BlazingWind/OWASP-ASVS-4.0-testing-guide](https://github.com/BlazingWind/OWASP-ASVS-4.0-testing-guide) \ No newline at end of file diff --git a/5.0/pt/0x92-Appendix-C_Cryptography.md b/5.0/pt/0x92-Appendix-C_Cryptography.md index 93f5cebec4..d3df036bc2 100644 --- a/5.0/pt/0x92-Appendix-C_Cryptography.md +++ b/5.0/pt/0x92-Appendix-C_Cryptography.md @@ -1,33 +1,33 @@ -# Appendix C: Cryptography Standards +# Apêndice C: Padrões de Criptografia -The "Cryptography" chapter goes beyond simply defining best practices. It aims to enhance understanding of cryptography principles and encourage the adoption of more resilient, modern security methods. This appendix provides detailed technical information regarding each requirement, complementing the overarching standards outlined in the "Cryptography" chapter. +O capítulo "Criptografia" vai além de simplesmente definir as melhores práticas. O seu objetivo é o de aprimorar a compreensão dos princípios de criptografia e incentivar a adoção de métodos de segurança modernos e mais resilientes. Este apêndice fornece informações técnicas detalhadas com relação a cada requisito, complementando os padrões abrangentes descritos no capítulo "Criptografia". -This appendix defines the level of approval for different cryptographic mechanisms: +Este apêndice define o nível de aprovação para diferentes mecanismos criptográficos: -* Approved (A) mechanisms can be used in applications. -* Legacy mechanisms (L) should not be used in applications but might still be used for compatibility with existing legacy applications or code onyly. While the usage of such these mechanisms is currently not considered to be a vulnerability in itself, they should be replaced by more secure and future-proof mechanisms as soon as possible. -* Disallowed mechanisms (D) must not be used because they are currently considered broken or do not provide sufficient security. +* Mecanismos Aprovados (Approved - A) podem ser usados em aplicações. +* Mecanismos Legados (Legacy mechanisms - L) não devem ser usados em aplicações, mas ainda podem ser usados apenas para compatibilidade com código ou aplicações legadas existentes. Embora o uso de tais mecanismos atualmente não seja considerado uma vulnerabilidade em si, eles devem ser substituídos por mecanismos mais seguros e à prova de futuro (future-proof) assim que possível. +* Mecanismos Não Permitidos (Disallowed mechanisms - D) não devem ser usados porque são atualmente considerados quebrados ou não fornecem segurança suficiente. -This list may be overridden in the context of a given application for various reasons including: +Esta lista pode ser anulada (overridden) no contexto de uma determinada aplicação por vários motivos, incluindo: -* new evolutions in the field of cryptography; -* compliance with regulation. +* novas evoluções no campo da criptografia; +* conformidade com regulamentação. -## Cryptographic Inventory and Documentation +## Inventário e Documentação Criptográfica -This section provides additional information -for V11.1 Cryptographic Inventory and Documentation. +Esta seção fornece informações adicionais +para V11.1 Inventário e Documentação Criptográfica. -It is important to ensure that all cryptographic assets, such as algorithms, keys, and certificates, are regularly discovered, inventoried, and assessed. For Level 3, this should include the use of static and dynamic scanning to discover the use of cryptography in an application. Tools such as SAST and DAST may help with this but it is possible that dedicated tools would be needed to get more comprehensive coverage. Freeware examples of tools include: +É importante garantir que todos os ativos criptográficos, como algoritmos, chaves e certificados, sejam descobertos, inventariados e avaliados regularmente. Para o Nível 3, isso deve incluir o uso de varredura (scanning) estática e dinâmica para descobrir o uso da criptografia em uma aplicação. Ferramentas como SAST e DAST podem ajudar com isso, mas é possível que ferramentas dedicadas sejam necessárias para obter uma cobertura mais abrangente. Exemplos gratuitos de ferramentas incluem: * [CryptoMon - Network Cryptography Monitor - using eBPF, written in python](https://github.com/Santandersecurityresearch/CryptoMon) * [Cryptobom Forge Tool: Generating Comprehensive CBOMs from CodeQL Outputs](https://github.com/Santandersecurityresearch/cryptobom-forge) -## Equivalent Strengths of Cryptographic Parameters +## Forças Equivalentes dos Parâmetros Criptográficos -The relative security strengths for various cryptographic systems are in this table (from [NIST SP 800-57 Part 1](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final), p.71): +As forças de segurança relativas para vários sistemas criptográficos estão nesta tabela (do [NIST SP 800-57 Part 1](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final), p.71): -| Security Strength | Symmetric Key Algorithms | Finite Field | Integer Factorisation | Elliptic Curve | +| Força de Segurança | Algoritmos de Chave Simétrica | Campo Finito | Fatoração de Inteiros | Curva Elíptica | |--|--|--|--|--| | <= 80 | 2TDEA | L = 1024
N = 160 | k = 1024 | f = 160-223 | | 112 | 3TDEA | L = 2048
N = 224 | k = 2048 | f = 224-255 | @@ -35,38 +35,38 @@ The relative security strengths for various cryptographic systems are in this ta | 192 | AES-192 | L = 7680
N = 384 | k = 7680 | f = 384-511 | | 256 | AES-256 | L = 15360
N = 512 | k = 15360 | f = 512+ | -Example of applications: +Exemplo de aplicações: -* Finite Field Cryptography: DSA, FFDH, MQV -* Integer Factorisation Cryptography: RSA -* Elliptic Curve Cryptography: ECDSA, EdDSA, ECDH, MQV +* Criptografia de Campo Finito: DSA, FFDH, MQV +* Criptografia de Fatoração de Inteiros: RSA +* Criptografia de Curva Elíptica: ECDSA, EdDSA, ECDH, MQV -Note: that this section assumes that no quantum computer exists; if such a computer would exist, the estimates for the last 3 columns would be no longer valid. +Nota: observe que esta seção pressupõe que não exista computador quântico; se tal computador existisse, as estimativas para as últimas 3 colunas não seriam mais válidas. -## Random Values +## Valores Aleatórios -This section provides additional information -for V11.5 Random Values. +Esta seção fornece informações adicionais +para V11.5 Valores Aleatórios. -| Name | Version/Reference | Notes | Status | +| Nome | Versão/Referência | Notas | Status | |:---|:----|:----|:-:| -| `/dev/random` | Linux 4.8+ [(Oct 2016)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=818e607b57c94ade9824dad63a96c2ea6b21baf3), also found in iOS, Android, and other Linux-based POSIX operating systems. Based on [RFC7539](https://datatracker.ietf.org/doc/html/rfc7539) | Utilizing ChaCha20 stream. Found in iOS [`SecRandomCopyBytes`](https://developer.apple.com/documentation/security/secrandomcopybytes(_:_:_:)?language=objc) and Android [`Secure Random`](https://developer.android.com/reference/java/security/SecureRandom) with the correct settings provided to each. | A | -| `/dev/urandom` | Linux kernel's special file for providing random data | Provides high-quality, entropy sources from hardware randomness | A | -| `AES-CTR-DRBG` | [NIST SP800-90A](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf) | As used in common implementations, such as [Windows CNG API `BCryptGenRandom`](https://learn.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptgenrandom) set by [`BCRYPT_RNG_ALGORITHM`](https://learn.microsoft.com/en-us/windows/win32/seccng/cng-algorithm-identifiers). | A | +| `/dev/random` | Linux 4.8+ [(Oct 2016)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=818e607b57c94ade9824dad63a96c2ea6b21baf3), também encontrado no iOS, Android e outros sistemas operacionais POSIX baseados em Linux. Baseado na [RFC7539](https://datatracker.ietf.org/doc/html/rfc7539) | Utilizando stream ChaCha20. Encontrado no iOS [`SecRandomCopyBytes`](https://developer.apple.com/documentation/security/secrandomcopybytes(_:_:_:)?language=objc) e Android [`Secure Random`](https://developer.android.com/reference/java/security/SecureRandom) com as configurações corretas fornecidas a cada um. | A | +| `/dev/urandom` | Arquivo especial do kernel do Linux para fornecer dados aleatórios | Fornece fontes de entropia de alta qualidade a partir de aleatoriedade de hardware | A | +| `AES-CTR-DRBG` | [NIST SP800-90A](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf) | Conforme usado em implementações comuns, como a [Windows CNG API `BCryptGenRandom`](https://learn.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptgenrandom) definida por [`BCRYPT_RNG_ALGORITHM`](https://learn.microsoft.com/en-us/windows/win32/seccng/cng-algorithm-identifiers). | A | | `HMAC-DRBG` | [NIST SP800-90A](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf) | | A | | `Hash-DRBG` | [NIST SP800-90A](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf) | | A | -| `getentropy()` | [OpenBSD](https://man.openbsd.org/getentropy.2), available in [Linux glibc 2.25+](https://man7.org/linux/man-pages/man3/getentropy.3.html) and [macOS 10.12+](https://support.apple.com/en-gb/guide/security/seca0c73a75b/web) | Provides secure random bytes directly from the kernel's entropy source with a straightforward and minimal API. It’s more modern and avoids pitfalls associated with older APIs. | A | +| `getentropy()` | [OpenBSD](https://man.openbsd.org/getentropy.2), disponível em [Linux glibc 2.25+](https://man7.org/linux/man-pages/man3/getentropy.3.html) e [macOS 10.12+](https://support.apple.com/en-gb/guide/security/seca0c73a75b/web) | Fornece bytes aleatórios seguros diretamente da fonte de entropia do kernel com uma API direta e mínima. É mais moderno e evita as armadilhas associadas às APIs mais antigas. | A | -The underlying hash function used with HMAC-DRBG or Hash-DRBG must be approved for this usage. +A função hash subjacente usada com o HMAC-DRBG ou Hash-DRBG deve ser aprovada para este uso. -## Cipher Algorithms +## Algoritmos de Cifra -This section provides additional information -for V11.3 Encryption Algorithms. +Esta seção fornece informações adicionais +para V11.3 Algoritmos de Criptografia. -Approved cipher algorithms are listed in order of preference. +Os algoritmos de cifra aprovados estão listados em ordem de preferência. -| Symmetric Key Algorithms | Reference | Status | +| Algoritmos de Chave Simétrica | Referência | Status | | ------ | ------ |:-:| | AES-256 | [FIPS 197](https://csrc.nist.gov/pubs/fips/197/final) | A | | Salsa20 | [Salsa 20 specification](https://cr.yp.to/snuffle/spec.pdf) | A | @@ -83,55 +83,55 @@ Approved cipher algorithms are listed in order of preference. | ARC4 | | D | | DES | | D | -### AES Cipher Modes +### Modos de Cifra AES -Block ciphers, such as AES, can be used with different modes of operations. Many modes of operations, such as Electronic codebook (ECB), are insecure and must not be used. The Galois/Counter Mode (GCM) and Counter with cipher block chaining message authentication code (CCM) modes of operations provide authenticated encryption and should be used in modern applications. +Cifras de bloco, como o AES, podem ser usadas com diferentes modos de operação. Muitos modos de operação, como o Electronic codebook (ECB), são inseguros e não devem ser usados. Os modos de operação Galois/Counter Mode (GCM) e Counter with cipher block chaining message authentication code (CCM) fornecem criptografia autenticada e devem ser usados em aplicações modernas. -Approved modes are listed in order of preference. +Os modos aprovados estão listados em ordem de preferência. -| Mode | Authenticated | Reference | Status | Restriction | +| Modo | Autenticado | Referência | Status | Restrição | |--|--|--|:-:|--| -| GCM | Yes | [NIST SP 800-38D](https://csrc.nist.gov/pubs/sp/800/38/d/final) | A | | -| CCM | Yes | [NIST SP 800-38C](https://csrc.nist.gov/pubs/sp/800/38/c/upd1/final) | A | | -| CBC | No | [NIST SP 800-38A](https://csrc.nist.gov/pubs/sp/800/38/a/final) | L | | -| CCM-8 | Yes | | D | | -| ECB | No | | D | | -| CFB | No | | D | | -| OFB | No | | D | | -| CTR | No | | D | | +| GCM | Sim | [NIST SP 800-38D](https://csrc.nist.gov/pubs/sp/800/38/d/final) | A | | +| CCM | Sim | [NIST SP 800-38C](https://csrc.nist.gov/pubs/sp/800/38/c/upd1/final) | A | | +| CBC | Não | [NIST SP 800-38A](https://csrc.nist.gov/pubs/sp/800/38/a/final) | L | | +| CCM-8 | Sim | | D | | +| ECB | Não | | D | | +| CFB | Não | | D | | +| OFB | Não | | D | | +| CTR | Não | | D | | -Notes: +Notas: -* All encrypted messages must be authenticated. For ANY use of CBC mode there MUST be an associated hashing MAC algorithm to validate the message. In general, this MUST be applied in the Encrypt-Then-Hash method (but TLS 1.2 uses Hash-Then-Encrypt instead). If this cannot be guaranteed, then CBC MUST NOT be used. The only application where encryption without a MAC algorithm is allowed is disk encryption. -* If CBC is used, it shall be guaranteed that the verification of the padding is performed in constant time. -* When using CCM-8, the MAC tag only has 64 bits of security. This does not conform to requirement 6.2.9 which requires at least 128 bits of security. -* Disk encryption is considered out of scope for the ASVS. Therefore this appendix does not list any approved method for disk encryption. For this usage, encryption without authentication is usually accepted and the XTS, XEX and LRW modes are typically used. +* Todas as mensagens criptografadas devem ser autenticadas. Para QUALQUER uso do modo CBC, DEVE haver um algoritmo MAC de hash associado para validar a mensagem. Em geral, isso DEVE ser aplicado no método Encrypt-Then-Hash (mas o TLS 1.2 usa Hash-Then-Encrypt em seu lugar). Se isso não puder ser garantido, o CBC NÃO DEVE ser usado. A única aplicação onde a criptografia sem um algoritmo MAC é permitida é a criptografia de disco. +* Se o CBC for usado, deve-se garantir que a verificação do preenchimento (padding) seja realizada em tempo constante (constant time). +* Ao usar CCM-8, a tag MAC possui apenas 64 bits de segurança. Isso não está em conformidade com o requisito 6.2.9, que exige pelo menos 128 bits de segurança. +* Criptografia de disco é considerada fora do escopo para o ASVS. Portanto, este apêndice não lista nenhum método aprovado para criptografia de disco. Para este uso, a criptografia sem autenticação é geralmente aceita e os modos XTS, XEX e LRW são tipicamente usados. -### Key Wrapping +### Empacotamento de Chaves (Key Wrapping) -Cryptographic key wrap (and corresponding key unwrap) is a method of protecting an existing key by encapsulating (i.e., wrapping) it by employing an additional encryption mechanism so that the original key is not obviously exposed, e.g., during a transfer. This additional key used to protect the original key is referred to as the wrap key. +O empacotamento de chave criptográfica (cryptographic key wrap) (e o correspondente desempacotamento de chave / key unwrap) é um método de proteger uma chave existente encapsulando-a (ou seja, empacotando-a) ao empregar um mecanismo de criptografia adicional, para que a chave original não seja exposta de forma óbvia, por exemplo, durante uma transferência. Esta chave adicional usada para proteger a chave original é referida como a chave de empacotamento (wrap key). -This operation may be performed when it is desirable to protect keys in places deemed untrustworthy, or to send sensitive keys over untrusted networks or within applications. -However, serious consideration should be given to understanding the nature (e.g., the identity and the purpose) of the original key prior to committing to a wrap/unwrap procedure as this may have repercussions for both source and target systems/applications in terms of security and especially compliance which may include audit trails of a key's function (e.g., signing) as well as appropriate key storage. +Essa operação pode ser realizada quando for desejável proteger chaves em locais considerados não confiáveis ou para enviar chaves sensíveis em redes não confiáveis ou dentro de aplicações. +No entanto, deve-se considerar seriamente a compreensão da natureza (ex., a identidade e o propósito) da chave original antes de se comprometer com um procedimento de empacotar/desempacotar (wrap/unwrap), pois isso pode ter repercussões tanto para os sistemas/aplicações de origem quanto de destino em termos de segurança e, especialmente, conformidade, o que pode incluir trilhas de auditoria da função de uma chave (ex., assinatura), bem como o armazenamento apropriado da chave. -Specifically, AES-256 MUST be used for key wrapping, following [NIST SP 800-38F](https://csrc.nist.gov/pubs/sp/800/38/f/final) and considering forward-looking provisions against the quantum threat. Cipher modes using AES are the following, in order of preference: +Especificamente, o AES-256 DEVE ser usado para o empacotamento de chaves, seguindo o [NIST SP 800-38F](https://csrc.nist.gov/pubs/sp/800/38/f/final) e considerando provisões voltadas para o futuro contra a ameaça quântica. Os modos de cifra usando AES são os seguintes, em ordem de preferência: -| Key Wrapping | Reference | Status | +| Empacotamento de Chave (Key Wrapping) | Referência | Status | |--|--|:-:| | KW | [NIST SP 800-38F](https://csrc.nist.gov/pubs/sp/800/38/f/final) | A | | KWP | [NIST SP 800-38F](https://csrc.nist.gov/pubs/sp/800/38/f/final) | A | -AES-192 and AES-128 MAY be used if the use case demands it, but its motivation MUST be documented in the entity's cryptography inventory. +AES-192 e AES-128 PODEM ser usados se o caso de uso exigir, mas sua motivação DEVE ser documentada no inventário de criptografia da entidade. -### Authenticated Encryption +### Criptografia Autenticada -With the exception of disk encryption, encrypted data must be protected against unauthorized modification using some form of authenticated encryption (AE) scheme, usually using an authenticated encryption with associated data (AEAD) scheme. +Com exceção da criptografia de disco, os dados criptografados devem ser protegidos contra modificação não autorizada utilizando alguma forma de esquema de criptografia autenticada (AE), geralmente usando um esquema de criptografia autenticada com dados associados (AEAD). -The application should preferably use an approved AEAD scheme. It might alternatively combine an approved cipher scheme and an approved MAC algorithm with a Encrypt-then-MAC construct. +A aplicação deve, de preferência, usar um esquema AEAD aprovado. Alternativamente, ela pode combinar um esquema de cifra aprovado e um algoritmo MAC aprovado com uma construção Encrypt-then-MAC. -MAC-then-encrypt is still allowed for compatibility with legacy applications. It is used in TLS v1.2 with old ciphers suites. +MAC-then-encrypt ainda é permitido para compatibilidade com aplicações legadas. É usado no TLS v1.2 com suítes de cifras (ciphers suites) antigas. -| AEAD mechanism | Reference | Status | +| Mecanismo AEAD | Referência | Status | |---|---------|:-:| |AES-GCM | [SP 800-38D](https://csrc.nist.gov/pubs/sp/800/38/d/final) | A | |AES-CCM | [SP 800-38C](https://csrc.nist.gov/pubs/sp/800/38/c/upd1/final) | A | @@ -142,20 +142,20 @@ MAC-then-encrypt is still allowed for compatibility with legacy applications. It |Encrypt-then-MAC | | A | |MAC-then-encrypt | | L | -## Hash Functions +## Funções Hash -This section provides additional information -for V11.4 Hashing and Hash-based Functions. +Esta seção fornece informações adicionais +para V11.4 Hashing e Funções Baseadas em Hash. -### Hash Functions for General Use Cases +### Funções Hash para Casos de Uso Gerais -The following table lists hash functions approved in general cryptographic use cases such as digital signatures: +A tabela a seguir lista as funções hash aprovadas em casos gerais de uso criptográfico, como assinaturas digitais: -* Approved hash functions provide strong collision resistance and are suitable for high-security applications. -* Some of these algorithms offer strong resistance to attacks when used with proper cryptographic key management, and so are additionally approved for HMAC, KDF, and RBG functions. -* Hash function with less than 254 bit of output have insufficient collision resistancea and must not be used for digital signature or other applications requiring collision resistance. For other usages, they might be used for compatibility and verification ONLY with legacy systems but must not be used in new designs. +* Funções hash aprovadas fornecem forte resistência à colisão e são adequadas para aplicações de alta segurança. +* Alguns desses algoritmos oferecem forte resistência a ataques quando usados com o gerenciamento adequado de chaves criptográficas, e por isso são adicionalmente aprovados para funções HMAC, KDF e RBG. +* Função hash com menos de 254 bits de saída possui resistência a colisão insuficiente e não deve ser usada para assinatura digital ou outras aplicações que requeiram resistência a colisão. Para outros usos, elas podem ser usadas para compatibilidade e verificação APENAS com sistemas legados, mas não devem ser usadas em novos designs. -| Hash function | Reference | Status | Restrictions | +| Função Hash | Referência | Status | Restrições | | ------ | ----------- |:-:| ---------- | | SHA3-512 |[FIPS 202](https://csrc.nist.gov/pubs/fips/202/final) | A | | | SHA-512 |[FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | A | | @@ -168,19 +168,19 @@ The following table lists hash functions approved in general cryptographic use c | BLAKE2s | [BLAKE2: simpler, smaller, fast as MD5](https://eprint.iacr.org/2013/322) | A | | | BLAKE2b | [BLAKE2: simpler, smaller, fast as MD5](https://eprint.iacr.org/2013/322) | A | | | BLAKE3 | [BLAKE3 one function, fast everywhere](https://github.com/BLAKE3-team/BLAKE3-specs/raw/master/blake3.pdf) | A | | -| SHA-224 | [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | L | Not suitable for HMAC, KDF, RBG, digital signatures | -| SHA-512/224 | [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | L | Not suitable for HMAC, KDF, RBG, digital signatures | -| SHA3-224 | [FIPS 202](https://csrc.nist.gov/pubs/fips/202/final) | L | Not suitable for HMAC, KDF, RBG, digital signatures | -| SHA-1 | [RFC 3174](https://www.rfc-editor.org/info/rfc3174) & [RFC 6194](https://www.rfc-editor.org/info/rfc6194) | L | Not suitable for HMAC, KDF, RBG, digital signatures | -| CRC (any length) | | D | | +| SHA-224 | [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | L | Não adequado para HMAC, KDF, RBG, assinaturas digitais | +| SHA-512/224 | [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | L | Não adequado para HMAC, KDF, RBG, assinaturas digitais | +| SHA3-224 | [FIPS 202](https://csrc.nist.gov/pubs/fips/202/final) | L | Não adequado para HMAC, KDF, RBG, assinaturas digitais | +| SHA-1 | [RFC 3174](https://www.rfc-editor.org/info/rfc3174) & [RFC 6194](https://www.rfc-editor.org/info/rfc6194) | L | Não adequado para HMAC, KDF, RBG, assinaturas digitais | +| CRC (qualquer comprimento) | | D | | | MD4 | [RFC 1320](https://www.rfc-editor.org/info/rfc1320) | D | | | MD5 | [RFC 1321](https://www.rfc-editor.org/info/rfc1321) | D | | -### Hash Functions for Password Storage +### Funções Hash para Armazenamento de Senhas -For secure password hashing, dedicated hash functions must be used. These slow-hashing algorithms mitigate brute-force and dictionary attacks by increasing the computational difficulty of password cracking. +Para o hashing seguro de senhas, funções hash dedicadas devem ser usadas. Estes algoritmos de hashing lento (slow-hashing) mitigam ataques de força bruta e de dicionário, aumentando a dificuldade computacional do crack de senhas. -| KDF | Reference | Required Parameters | Status | +| KDF | Referência | Parâmetros Obrigatórios | Status | | ---------- | --------- | ------------ |:-:| | argon2id | [RFC 9106](https://www.rfc-editor.org/info/rfc9106) | t = 1: m ≥ 47104 (46 MiB), p = 1 | A | | | | t = 2: m ≥ 19456 (19 MiB), p = 1 | A | @@ -189,64 +189,64 @@ For secure password hashing, dedicated hash functions must be used. These slow-h | | | p = 2: N ≥ 2^16 (64 MiB), r = 8 | A | | | | p ≥ 3: N ≥ 2^15 (32 MiB), r = 8 | A | | bcrypt | [A Future-Adaptable Password Scheme](https://www.researchgate.net/publication/2519476_A_Future-Adaptable_Password_Scheme) | cost ≥ 10 | A | -| PBKDF2-HMAC-SHA-512 | [NIST SP 800-132](https://csrc.nist.gov/pubs/sp/800/132/final), [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | iterations ≥ 210,000 | A | -| PBKDF2-HMAC-SHA-256 | [NIST SP 800-132](https://csrc.nist.gov/pubs/sp/800/132/final), [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | iterations ≥ 600,000 | A | -| PBKDF2-HMAC-SHA-1 | [NIST SP 800-132](https://csrc.nist.gov/pubs/sp/800/132/final), [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | iterations ≥ 1,300,000 | L | +| PBKDF2-HMAC-SHA-512 | [NIST SP 800-132](https://csrc.nist.gov/pubs/sp/800/132/final), [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | iterações ≥ 210,000 | A | +| PBKDF2-HMAC-SHA-256 | [NIST SP 800-132](https://csrc.nist.gov/pubs/sp/800/132/final), [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | iterações ≥ 600,000 | A | +| PBKDF2-HMAC-SHA-1 | [NIST SP 800-132](https://csrc.nist.gov/pubs/sp/800/132/final), [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | iterações ≥ 1,300,000 | L | -Approved password-based key derivations functions can be used for password storage. +As funções de derivação de chaves baseadas em senhas aprovadas podem ser usadas para armazenamento de senhas. -## Key Derivation Functions (KDFs) +## Funções de Derivação de Chaves (KDFs) -### General Key Derivation Functions +### Funções de Derivação de Chaves Gerais -| KDF | Reference | Status | +| KDF | Referência | Status | | ---------------- | -------- |:-:| | HKDF | [RFC 5869](https://www.rfc-editor.org/info/rfc5869) | A | | TLS 1.2 PRF | [RFC 5248](https://www.rfc-editor.org/info/rfc5248) | L | | MD5-based KDFs | [RFC 1321](https://www.rfc-editor.org/info/rfc1321) | D | | SHA-1-based KDFs | [RFC 3174](https://www.rfc-editor.org/info/rfc3174) & [RFC 6194](https://www.rfc-editor.org/info/rfc6194) | D | -### Password-based Key Derivation Functions +### Funções de Derivação de Chaves Baseadas em Senha -| KDF | Reference | Required Parameters | Status | +| KDF | Referência | Parâmetros Obrigatórios | Status | | ---------- | --------- | ------------ |:-:| | argon2id | [RFC 9106](https://www.rfc-editor.org/info/rfc9106) | t = 1: m ≥ 47104 (46 MiB), p = 1 | A | | | | t = 2: m ≥ 19456 (19 MiB), p = 1 | A | | scrypt | [RFC 7914](https://www.rfc-editor.org/info/rfc7914) | p = 1: N ≥ 2^17 (128 MiB), r = 8 | A | | | | p = 2: N ≥ 2^16 (64 MiB), r = 8 | A | | | | p ≥ 3: N ≥ 2^15 (32 MiB), r = 8 | A | -| PBKDF2-HMAC-SHA-512 | [NIST SP 800-132](https://csrc.nist.gov/pubs/sp/800/132/final), [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | iterations ≥ 210,000 | A | -| PBKDF2-HMAC-SHA-256 | [NIST SP 800-132](https://csrc.nist.gov/pubs/sp/800/132/final), [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | iterations ≥ 600,000 | A | -| PBKDF2-HMAC-SHA-1 | [NIST SP 800-132](https://csrc.nist.gov/pubs/sp/800/132/final), [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | iterations ≥ 1,300,000 | L | +| PBKDF2-HMAC-SHA-512 | [NIST SP 800-132](https://csrc.nist.gov/pubs/sp/800/132/final), [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | iterações ≥ 210,000 | A | +| PBKDF2-HMAC-SHA-256 | [NIST SP 800-132](https://csrc.nist.gov/pubs/sp/800/132/final), [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | iterações ≥ 600,000 | A | +| PBKDF2-HMAC-SHA-1 | [NIST SP 800-132](https://csrc.nist.gov/pubs/sp/800/132/final), [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | iterações ≥ 1,300,000 | L | -## Key Exchange Mechanisms +## Mecanismos de Troca de Chaves -This section provides additional information -for V11.6 Public Key Cryptography. +Esta seção fornece informações adicionais +para V11.6 Criptografia de Chave Pública. -### KEX Schemes +### Esquemas KEX -A security strength of 112 bits or above MUST be ensured for all Key Exchange schemes, and their implementation MUST follow the parameter choices in the following table. +Uma força de segurança de 112 bits ou superior DEVE ser garantida para todos os esquemas de Troca de Chaves, e sua implementação DEVE seguir as escolhas de parâmetros na tabela a seguir. -| Scheme | Domain Parameters | Forward Secrecy |Status | +| Esquema | Parâmetros de Domínio | Forward Secrecy |Status | |--|--|--|:-:| -| Finite Field Diffie-Hellman (FFDH) | L >= 3072 & N >= 256 | Yes | A | -| Elliptic Curve Diffie-Hellman (ECDH) | f >= 256-383 | Yes | A | -| Encrypted key transport with RSA-PKCS#1 v1.5 | | No | D | +| Diffie-Hellman de Campo Finito (FFDH) | L >= 3072 & N >= 256 | Sim | A | +| Diffie-Hellman de Curva Elíptica (ECDH) | f >= 256-383 | Sim | A | +| Transporte de chave criptografada com RSA-PKCS#1 v1.5 | | Não | D | -Where the following parameters are: +Onde os seguintes parâmetros são: -* k is the key size for RSA keys. -* L is the size of the public key and N is the size of the private key for finite field cryptography. -* f is the range of key sizes for ECC. +* k é o tamanho da chave para chaves RSA. +* L é o tamanho da chave pública e N é o tamanho da chave privada para criptografia de campo finito. +* f é o alcance (range) de tamanhos de chaves para ECC. -Any new implementation MUST NOT use any scheme that is NOT compliant with [NIST SP 800-56A](https://csrc.nist.gov/pubs/sp/800/56/a/r3/final) & [B](https://csrc.nist.gov/pubs/sp/800/56/b/r2/final) and [NIST SP 800-77](https://csrc.nist.gov/pubs/sp/800/77/r1/final). Specifically, IKEv1 MUST NOT be used in production. +Nenhuma nova implementação DEVE usar qualquer esquema que NÃO esteja em conformidade com as diretrizes [NIST SP 800-56A](https://csrc.nist.gov/pubs/sp/800/56/a/r3/final) & [B](https://csrc.nist.gov/pubs/sp/800/56/b/r2/final) e [NIST SP 800-77](https://csrc.nist.gov/pubs/sp/800/77/r1/final). Especificamente, o IKEv1 NÃO DEVE ser usado em produção. -### Diffie-Hellman groups +### Grupos Diffie-Hellman -The following groups are approved for implementations of Diffie-Hellman key exchange. Security strengths are documented in [NIST SP 800-56A](https://csrc.nist.gov/pubs/sp/800/56/a/r3/final), Appendix D, and [NIST SP 800-57 Part 1 Rev.5](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final). +Os seguintes grupos são aprovados para implementações de troca de chaves Diffie-Hellman. As forças de segurança estão documentadas no [NIST SP 800-56A](https://csrc.nist.gov/pubs/sp/800/56/a/r3/final), Apêndice D, e no [NIST SP 800-57 Part 1 Rev.5](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final). -| Group | Status | +| Grupo | Status | |------------------|:------:| | P-224, secp224r1 | A | | P-256, secp256r1 | A | @@ -273,39 +273,39 @@ The following groups are approved for implementations of Diffie-Hellman key exch | ffdhe6144 | A | | ffdhe8192 | A | -## Message Authentication Codes (MAC) +## Códigos de Autenticação de Mensagens (Message Authentication Codes - MAC) -Message Authentication Codes (MACs) are cryptographic constructs used to verify the integrity and authenticity of a message. A MAC takes a message and a secret key as inputs and produces a fixed-size tag (the MAC value). MACs are widely used in secure communication protocols (e.g., TLS/SSL) to ensure that messages exchanged between parties are authentic and intact. +Os Códigos de Autenticação de Mensagem (MACs) são constructos criptográficos usados para verificar a integridade e autenticidade de uma mensagem. Um MAC recebe uma mensagem e uma chave secreta como entradas (inputs) e produz uma tag de tamanho fixo (o valor MAC). Os MACs são amplamente utilizados em protocolos de comunicação segura (ex., TLS/SSL) para garantir que as mensagens trocadas entre as partes sejam autênticas e estejam intactas. -| MAC Algorithm | Reference | Status | +| Algoritmo MAC | Referência | Status | | ---------- | --------------- |:-:| | HMAC-SHA-256 | [RFC 2104](https://www.rfc-editor.org/info/rfc2104) & [FIPS 198-1](https://csrc.nist.gov/pubs/fips/198-1/final) | A | | HMAC-SHA-384 | [RFC 2104](https://www.rfc-editor.org/info/rfc2104) & [FIPS 198-1](https://csrc.nist.gov/pubs/fips/198-1/final) | A | | HMAC-SHA-512 | [RFC 2104](https://www.rfc-editor.org/info/rfc2104) & [FIPS 198-1](https://csrc.nist.gov/pubs/fips/198-1/final) | A | | KMAC128 | [NIST SP 800-185](https://csrc.nist.gov/pubs/sp/800/185/final) | A | | KMAC256 | [NIST SP 800-185](https://csrc.nist.gov/pubs/sp/800/185/final) | A | -| BLAKE3 (keyed_hash mode) | [BLAKE3 one function, fast everywhere](https://github.com/BLAKE3-team/BLAKE3-specs/raw/master/blake3.pdf) | A | +| BLAKE3 (modo keyed_hash) | [BLAKE3 one function, fast everywhere](https://github.com/BLAKE3-team/BLAKE3-specs/raw/master/blake3.pdf) | A | | AES-CMAC | [RFC 4493](https://datatracker.ietf.org/doc/html/rfc4493) & [NIST SP 800-38B](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38b.pdf) | A | | AES-GMAC | [NIST SP 800-38D](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf) | A | | Poly1305-AES | [The Poly1305-AES message-authentication code](https://cr.yp.to/mac/poly1305-20050329.pdf) | A | | HMAC-SHA-1 | [RFC 2104](https://www.rfc-editor.org/info/rfc2104) & [FIPS 198-1](https://csrc.nist.gov/pubs/fips/198-1/final) | L | | HMAC-MD5 | [RFC 1321](https://www.rfc-editor.org/info/rfc1321) | D | -## Digital Signatures +## Assinaturas Digitais -Signature schemes MUST use approved key sizes and parameters per [NIST SP 800-57 Part 1](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final). +Os esquemas de assinatura DEVEM usar parâmetros e tamanhos de chave aprovados de acordo com o [NIST SP 800-57 Part 1](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final). -| Signature Algorithm | Reference | Status | +| Algoritmo de Assinatura | Referência | Status | | ------------------------------ | --------------------------------------------- | :-: | | EdDSA (Ed25519, Ed448) | [RFC 8032](https://www.rfc-editor.org/info/rfc8032) | A | | XEdDSA (Curve25519, Curve448) | [XEdDSA](https://signal.org/docs/specifications/xeddsa/) | A | | ECDSA (P-256, P-384, P-521) | [FIPS 186-4](https://csrc.nist.gov/pubs/fips/186-5/final) | A | | RSA-RSSA-PSS | [RFC 8017](https://www.rfc-editor.org/info/rfc8017) | A | | RSA-SSA-PKCS#1 v1.5 | [RFC 8017](https://www.rfc-editor.org/info/rfc8017) | D | -| DSA (any key size) | [FIPS 186-4](https://csrc.nist.gov/pubs/fips/186-4/final) | D | +| DSA (qualquer tamanho de chave) | [FIPS 186-4](https://csrc.nist.gov/pubs/fips/186-4/final) | D | -## Post-Quantum Encryption Standards +## Padrões de Criptografia Pós-Quântica (Post-Quantum Encryption Standards) -PQC implementations must be in line with [FIPS-203](https://csrc.nist.gov/pubs/fips/203/ipd)/[204](https://csrc.nist.gov/pubs/fips/204/ipd)/[205](https://csrc.nist.gov/pubs/fips/205/ipd) as there is minimal hardened code nor implementation reference yet. https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards +As implementações de PQC devem estar em conformidade com [FIPS-203](https://csrc.nist.gov/pubs/fips/203/ipd)/[204](https://csrc.nist.gov/pubs/fips/204/ipd)/[205](https://csrc.nist.gov/pubs/fips/205/ipd), uma vez que há o mínimo de código fortalecido (hardened code) ou referência de implementação até o momento. https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards -The proposed [mlkem768x25519](https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-mlkem/03/) post-quantum hybrid TLS key agreement method is supported by major browsers such as [Firefox release 132](https://www.mozilla.org/en-US/firefox/132.0/releasenotes/) and [Chrome release 131](https://security.googleblog.com/2024/09/a-new-path-for-kyber-on-web.html). It may be used in cryptographic testing environments or when available within industry- or government-approved libraries. +O método de acordo de chaves TLS híbrido pós-quântico proposto [mlkem768x25519](https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-mlkem/03/) é suportado pelos principais navegadores, como a [versão 132 do Firefox](https://www.mozilla.org/en-US/firefox/132.0/releasenotes/) e a [versão 131 do Chrome](https://security.googleblog.com/2024/09/a-new-path-for-kyber-on-web.html). Ele pode ser usado em ambientes de teste criptográfico ou quando disponível em bibliotecas aprovadas pela indústria ou pelo governo. \ No newline at end of file diff --git a/5.0/pt/0x93-Appendix-D_Recommendations.md b/5.0/pt/0x93-Appendix-D_Recommendations.md index 496dd5ba61..55be7f0b6f 100644 --- a/5.0/pt/0x93-Appendix-D_Recommendations.md +++ b/5.0/pt/0x93-Appendix-D_Recommendations.md @@ -1,49 +1,49 @@ -# Appendix D: Recommendations +# Apêndice D: Recomendações -## Introduction +## Introdução -Whilst preparing version 5.0 of the Application Security Verification Standard (ASVS), it became clear that there were a number of existing and newly suggested items that shouldn't be included as requirements in 5.0. This may have been because they were not in scope for ASVS as per the definition for 5.0 or alternatively it was felt that while they were a good idea, they could not be made mandatory. +Durante a preparação da versão 5.0 do Application Security Verification Standard (ASVS), ficou claro que havia uma série de itens existentes e novos sugeridos que não deveriam ser incluídos como requisitos na versão 5.0. Isso pode ter ocorrido porque eles não estavam no escopo do ASVS de acordo com a definição da versão 5.0 ou, alternativamente, porque embora se sentisse que eram uma boa ideia, não poderiam ser tornados obrigatórios. -Not wanting to lose all these items entirely, some have been captured in this appendix. +Não querendo perder todos esses itens inteiramente, alguns foram capturados neste apêndice. -## Recommended, in-scope mechanisms +## Mecanismos recomendados, dentro do escopo -The following items are in-scope for ASVS. They should not be made mandatory but it is strongly recommended to consider them as part of a secure application. +Os itens a seguir estão no escopo do ASVS. Eles não devem ser tornados obrigatórios, mas é altamente recomendável considerá-los como parte de uma aplicação segura. -* A password strength meter should provided to help users set a stronger password. -* Create a publicly available security.txt file at the root or .well-known directory of the application that clearly defines a link or e-mail address for people to contact owners about security issues. -* Client-side input validation should be enforced in addition to validation at a trusted service layer as this provides a good opportunity to discover when someone has bypassed client-side controls in an attempt to attack the application. -* Prevent accidentally accessible and sensitive pages from appearing in search engines using a robots.txt file, the X-Robots-Tag response header or a robots html meta tag. -* When using GraphQL, implement authorization logic at the business logic layer instead of the GraphQL or resolver layer to avoid having to handle authorization on every separate interface. +* Um medidor de força de senha (password strength meter) deve ser fornecido para ajudar os usuários a definir uma senha mais forte. +* Crie um arquivo security.txt publicamente disponível na raiz ou diretório .well-known da aplicação que defina claramente um link ou endereço de e-mail para as pessoas entrarem em contato com os proprietários sobre problemas de segurança. +* A validação de entrada no lado do cliente (client-side) deve ser aplicada, além da validação em uma camada de serviço confiável, pois isso fornece uma boa oportunidade para descobrir quando alguém burlou os controles no lado do cliente na tentativa de atacar a aplicação. +* Evite que páginas acidentalmente acessíveis e sensíveis apareçam nos mecanismos de busca usando um arquivo robots.txt, o cabeçalho de resposta X-Robots-Tag ou uma meta tag html robots. +* Ao usar GraphQL, implemente a lógica de autorização na camada de lógica de negócios (business logic layer) em vez da camada do GraphQL ou do resolver para evitar a necessidade de tratar a autorização em cada interface separada. -References: +Referências: * [More information on security.txt including a link to the RFC](https://securitytxt.org/) -## Software Security principles +## Princípios de Segurança de Software -The following items were previously in ASVS but are not really requirements. Rather they are principles to consider when implementing security controls that when followed will lead to more robust controls. These include: +Os itens a seguir estavam anteriormente no ASVS, mas na verdade não são requisitos. Em vez disso, são princípios a serem considerados ao implementar controles de segurança que, quando seguidos, levarão a controles mais robustos. Eles incluem: -* Security controls should be centralized, simple (economy of design), verifiably secure, and reusable. This should avoid duplicate, missing, or ineffective controls. -* Wherever possible, use previously written and well-vetted security control implementations rather than relying on implementing controls from scratch. -* Ideally, a single access control mechanism should be used to access protected data and resources. All requests should pass through this single mechanism to avoid copy and paste or insecure alternative paths. -* Attribute or feature-based access control is a recommended pattern whereby the code checks the user's authorization for a feature or data item rather than just their role. Permissions should still be allocated using roles. +* Os controles de segurança devem ser centralizados, simples (economia de design), sabidamente seguros e reutilizáveis. Isso deve evitar controles duplicados, ausentes ou ineficazes. +* Sempre que possível, use implementações de controle de segurança previamente escritas e bem examinadas (well-vetted), em vez de depender da implementação de controles a partir do zero. +* Idealmente, um único mecanismo de controle de acesso deve ser usado para acessar dados e recursos protegidos. Todas as requisições devem passar por esse único mecanismo para evitar caminhos alternativos do tipo copiar e colar ou inseguros. +* O controle de acesso baseado em atributos ou recursos (feature-based) é um padrão recomendado pelo qual o código verifica a autorização do usuário para um recurso ou item de dados, em vez de apenas sua função (role). As permissões ainda devem ser alocadas usando as roles. -## Software Security processes +## Processos de Segurança de Software -There are a number of security processes which were removed from ASVS 5.0 but are still a good idea. The OWASP SAMM project may be a good source for how to effectively implement these processes. The items which were previously in ASVS include: +Existem vários processos de segurança que foram removidos do ASVS 5.0, mas ainda são uma boa ideia. O projeto OWASP SAMM pode ser uma boa fonte sobre como implementar efetivamente esses processos. Os itens que estavam anteriormente no ASVS incluem: -* Verify the use of a secure software development lifecycle that addresses security in all stages of development. -* Verify the use of threat modeling for every design change or sprint planning to identify threats, plan for countermeasures, facilitate appropriate risk responses, and guide security testing. -* Verify that all user stories and features contain functional security constraints, such as "As a user, I should be able to view and edit my profile. I should not be able to view or edit anyone else's profile" -* Verify availability of a secure coding checklist, security requirements, guideline, or policy to all developers and testers. -* Verify that an ongoing process exists to ensure that the application source code is free from backdoors, malicious code (e.g., salami attacks, logic bombs, time bombs), and undocumented or hidden features (e.g., Easter eggs, insecure debugging tools). Complying with this section is not possible without complete access to source code, including third-party libraries, and is therefore probably only suitable for applications requiring the very highest levels of security. -* Verify that mechanisms are in place to detect and respond to configuration drift in deployed environments. This may include using immutable infrastructure, automated redeployment from a secure baseline, or drift detection tools that compare current state against approved configurations. -* Verify that configuration hardening is performed on all third-party products, libraries, frameworks, and services as per their individual recommendations. +* Verifique o uso de um ciclo de vida de desenvolvimento de software seguro que aborde a segurança em todas as etapas do desenvolvimento. +* Verifique o uso de modelagem de ameaças (threat modeling) para cada mudança de design ou planejamento de sprint para identificar ameaças, planejar contramedidas, facilitar respostas apropriadas a riscos e guiar testes de segurança. +* Verifique se todas as histórias de usuários (user stories) e funcionalidades (features) contêm restrições funcionais de segurança, como "Como usuário, eu devo ser capaz de visualizar e editar meu perfil. Eu não devo ser capaz de visualizar ou editar o perfil de mais ninguém." +* Verifique a disponibilidade de uma lista de verificação de codificação segura, requisitos de segurança, diretrizes ou políticas para todos os desenvolvedores e testadores. +* Verifique se existe um processo contínuo para garantir que o código-fonte da aplicação esteja livre de backdoors, código malicioso (por exemplo, ataques salami, bombas lógicas, bombas-relógio) e recursos não documentados ou ocultos (por exemplo, Easter eggs, ferramentas de depuração inseguras). Estar em conformidade com esta seção não é possível sem acesso total ao código-fonte, incluindo bibliotecas de terceiros, e portanto, provavelmente é adequado apenas para aplicações que exigem os mais altos níveis de segurança. +* Verifique se existem mecanismos para detectar e responder ao desvio de configuração (configuration drift) em ambientes implantados. Isso pode incluir o uso de infraestrutura imutável (immutable infrastructure), reimplantação automatizada a partir de uma base segura (secure baseline) ou ferramentas de detecção de desvio que comparam o estado atual em relação a configurações aprovadas. +* Verifique se o fortalecimento de configurações (configuration hardening) é executado em todos os produtos de terceiros, bibliotecas, frameworks e serviços conforme suas recomendações individuais. -References: +Referências: * [OWASP Threat Modeling Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html) * [OWASP Threat modeling](https://owasp.org/www-community/Application_Threat_Modeling) * [OWASP Software Assurance Maturity Model Project](https://owasp.org/www-project-samm/) -* [Microsoft SDL](https://www.microsoft.com/en-us/securityengineering/sdl/) +* [Microsoft SDL](https://www.microsoft.com/en-us/securityengineering/sdl/) \ No newline at end of file diff --git a/5.0/pt/0x94-Appendix-E_Contributors.md b/5.0/pt/0x94-Appendix-E_Contributors.md index 88508b2fdc..a3e2e79909 100644 --- a/5.0/pt/0x94-Appendix-E_Contributors.md +++ b/5.0/pt/0x94-Appendix-E_Contributors.md @@ -1,8 +1,8 @@ -# Appendix E - Contributors +# Apêndice E - Contribuidores -We gratefully acknowledge the contributions of the following people who have commented or opened pull requests since the the release of ASVS 4.0.0. +Agradecemos imensamente as contribuições das seguintes pessoas que comentaram ou abriram pull requests desde o lançamento do ASVS 4.0.0. -If you are aware of any mistakes or would like your name to appear differently, please let us know. +Se você estiver ciente de quaisquer erros ou gostaria que seu nome aparecesse de forma diferente, por favor nos avise. | | | | | |---|---|---|---| @@ -68,4 +68,4 @@ If you are aware of any mistakes or would like your name to appear differently, | Lyz ([lyz-code](https://github.com/lyz-code)) | Martin Riedel ([mrtnrdl](https://github.com/mrtnrdl)) | KIM Jaesuck ([tcaesvk](https://github.com/tcaesvk)) | Barbara Schachner ([bschach](https://github.com/bschach)) | | René Reuter ([AresSec](https://github.com/AresSec)) | [carhackpils](https://github.com/carhackpils) | Tyler ([tyler2cr](https://github.com/tyler2cr)) | Hugo ([hasousa](https://github.com/hasousa)) | | Wouter Bloeyaert ([Someniak](https://github.com/Someniak)) | Mark de Rijk ([markderijkinfosec](https://github.com/markderijkinfosec)) | Ramin ([picohub](https://github.com/picohub)) | Philip D. Turner ([philipdturner](https://github.com/philipdturner)) | -| Will Chatham ([willc](https://github.com/willc)) | | | | +| Will Chatham ([willc](https://github.com/willc)) | | | | \ No newline at end of file