Práticas ruins em segurança de produtos

No próprio produto

Linguagens sem segurança de memória (C, C++ etc.)

Sempre que possível, use linguagens com segurança de memória, e os programas legados que não as usam devem ser substituídos gradualmente até o fim de 2025.

Execução direta de comandos SQL

Use consultas parametrizadas, instruções preparadas ou ORM.

Execução direta de comandos do sistema operacional

A entrada do usuário não deve ser o próprio comando. Em vez de executar comandos diretamente, use funções de biblioteca embutidas ou permita na entrada apenas letras, números e sublinhado.

Uso de senhas conhecidas demais

Isso deve ser evitado, sempre que possível, com métodos como os abaixo.

• Fornecer senhas exclusivas desde o início.
• Exigir que o usuário crie uma senha forte durante a instalação.
• Definir um limite de tempo para a senha, como no MFA.
• Exigir acesso físico para obter credenciais confiáveis.
• Fazer campanhas ou migrar para formas de autenticação mais seguras do que as atuais.

Deixar vulnerabilidades conhecidas sem correção

As vulnerabilidades listadas nessa página devem ser evitadas em "todos" os casos. Quando novas vulnerabilidades forem reportadas, elas devem ser corrigidas em tempo hábil, e os usuários que não atualizarem para a versão corrigida devem ser avisados.

Bibliotecas open source com vulnerabilidades

É preciso comunicar isso de forma responsável e contribuir com as bibliotecas usadas. Isso também inclui medidas como as seguintes.

• Criar um SBOM: mostra quais bibliotecas o software usa.
• Itens a aplicar às bibliotecas open source das quais você depende
  • Realizar verificações de segurança.
  • Escolher projetos de qualidade, contínuos, bem protegidos e bem mantidos. Também é bom seguir princípios de segurança como estes.
  • Investigar continuamente se há vulnerabilidades bem conhecidas.
  • O fabricante deve manter uma cópia antecipadamente, e atualizações não devem vir de locais não verificados.
• É preciso considerar o custo de atualizar para uma nova versão principal ou receber patches de segurança.
  Se a vulnerabilidade não afetar o produto, deve-se informar publicamente por que ela não o afeta.

Algoritmos criptográficos vulneráveis ou desconhecidos (TLS 1.0/1.1, DES, MD5 etc.)

Devem ser usados algoritmos modernos. Além disso, também é preciso se preparar para algoritmos criptográficos quânticos padronizados, de acordo com as diretrizes do NIST.

Chaves secretas no código-fonte

É preciso usar um gerenciador de segredos (Secret Manager) para que o programa possa recuperar chaves secretas com segurança. Também é necessário verificar se há chaves secretas no código-fonte.

Em recursos de segurança

Sem suporte a MFA (incluindo suportar apenas passkeys)

Exceto em casos como equipamentos médicos de pronto-socorro, nos quais atrasos podem ser perigosos, o padrão deve ser implementar MFA diretamente ou permitir o uso de autenticadores externos. Isso deve ser exigido dos administradores, e os administradores devem exigi-lo dos usuários dentro da organização.

Não fornecer evidências de invasão

• Como funcionalidade muito básica, devem ser gerados logs relacionados a alterações ou consultas de configuração, histórico de login e acesso a informações.
• No caso de provedores de nuvem, esses logs devem ser mantidos por pelo menos 6 meses sem custo adicional e disponibilizados para visualização pelos usuários.

Em processos e políticas organizacionais

Não emitir CVE

Vulnerabilidades críticas ou de grande impacto devem ser divulgadas imediatamente.

Não divulgar a forma de divulgação de vulnerabilidades (VDP)

Políticas como as seguintes devem ser publicadas.

• Autorização para testes pelo público em geral
• Promessa de não tomar medidas legais contra quem agir de boa-fé
• Um canal claro para reportar
• Boas práticas de CVD (Coordinated Vulnerability Disclosure) e padrões internacionais
  As vulnerabilidades reportadas devem ser corrigidas em tempo hábil, em ordem de risco.

(No caso de on-premise) período de suporte pouco claro

O período de suporte deve ser comunicado com clareza, e atualizações de segurança devem ser fornecidas durante esse período.

---

• Exploit com um clique no KakaoTalk
• GN⁺: NIST (Instituto Nacional de Padrões e Tecnologia dos EUA), proíbe exigir composição específica de caracteres em senhas
• Casa Branca pede a desenvolvedores que evitem C e C++ e usem linguagens com "segurança de memória"
• Hackeando meu carro: Hyundai Ioniq: foi encontrado no código-fonte um texto cifrado RSA localizável pelo Google

[bbulbum]

Segurança é, no instante em que você vacila...! (acho que vi isso no exército)

[yolatengo]

Mantenha a calma e siga em frente!

[kandk]

Parece que voltou a rolar aquela conversa de não usar ORM...

[regentag]

Basta usar Prepared Statement em vez de ORM.

[roxie]

zzz

[ilikeall]

Todo mundo tem princípios, só que é difícil segui-los...

[felizgeek]

Concordo.
Exigir que o usuário crie uma senha forte != obrigar a incluir caracteres especiais, letras maiúsculas e minúsculas e números
Uma senha forte pode ser simplesmente uma senha com um comprimento razoavelmente grande.