Wiki de código seguro: uma rede de boas práticas de codificação segura
Para o avanço de Conhecimento e EducaçãoE o Ciência e Tecnologia Em geral, sempre foi de extrema importância a implementação do ações melhores e mais eficazes, medidas ou recomendações (Boas práticas) para atingir o objetivo final de, trazer à fruição qualquer atividade ou processo.
E a programação ou Desenvolvimento de software Como qualquer outro profissional e atividade de TI, tem seu próprio "Boas práticas" associado a muitas esferas, especialmente aquelas relacionadas a cibersegurança dos produtos de software produzidos. E neste post apresentaremos alguns «Boas práticas de codificação segura », de um site interessante e útil chamado "Wiki de código seguro", muito sobre Plataformas de Desenvolvimento livre e aberto, como privado e fechado.
Licenças para o desenvolvimento de Software Livre e Aberto: Boas práticas
Antes de entrar no assunto, como de costume, deixaremos posteriormente alguns links para publicações anteriores relacionadas ao tema de «Boas práticas em programação ou desenvolvimento de software ».
"… Boas práticas concebidas e divulgadas pela "Código para Iniciativa de Desenvolvimento" do Banco Interamericano de Desenvolvimento, no âmbito do Licença de Software, que deve ser considerada no desenvolvimento de produtos de software (ferramentas digitais), principalmente livres e abertos." Licenças para o desenvolvimento de Software Livre e Aberto: Boas práticas
Índice
- 1 Wiki de código seguro: Boas práticas de codificação segura
- 1.1 O que é Secure Code Wiki?
- 1.2 Exemplos de boas práticas por tipos de linguagens de programação
- 1.2.1 Exemplo 1: .Net (A1- injeção)
- 1.2.2 Exemplo 2: Java (A2 - autenticação quebrada)
- 1.2.3 Exemplo 3: Java para Android (M3 - comunicação insegura)
- 1.2.4 Exemplo 4: Kotlin (M4 - autenticação insegura)
- 1.2.5 Exemplo 5: NodeJS (A5 - Controle de acesso ruim)
- 1.2.6 Exemplo 6: Objetivo C (M6 - Autorização insegura)
- 1.2.7 Exemplo 7: PHP (A7 - Cross Site Scripting)
- 1.2.8 Exemplo 8: Python (A8 - desserialização insegura)
- 1.2.9 Exemplo 9: Python (A9 - Usando componentes com vulnerabilidades conhecidas)
- 1.2.10 Exemplo 10: Swift (M10 - Funcionalidade estranha)
- 1.2.11 Exemplo 11: WordPress (Desativar XML-RPC)
- 2 Conclusão
Wiki de código seguro: Boas práticas de codificação segura
O que é Secure Code Wiki?
Como seu texto diz WebSite:
"O Secure Code Wiki é o resultado de práticas de codificação seguras para uma ampla variedade de idiomas."
E está boas práticas e o site de "Wiki de código seguro" foram criados e mantidos por uma organização indiana chamada Payatus.
Exemplos de boas práticas por tipos de linguagens de programação
Como o site está em inglês, mostraremos alguns exemplos de codificação segura sobre vários linguagens de programação, alguns gratuitos e abertos, e outros privados e fechados, oferecidos pelo referido site para explore o potencial e a qualidade do conteúdo carregado.
Além disso, é importante destacar que Boas práticas exibido no Plataformas de Desenvolvimento seguinte:
- . NET
- Java
- Java para Android
- Kotlin
- NodeJS
- Objetivo C
- PHP
- Python
- Rubi
- rápido
- WordPress
Eles são divididos nas seguintes categorias para Desktop Languages:
- A1 - Injeção (Injeção)
- A2 - Autenticação quebrada (Autenticação quebrada)
- A3 - Exposição de dados sensíveis (Exposição de dados sensíveis)
- A4 - Entidades Externas XML (Entidades externas XML / XXE)
- A5 - Controle de acesso defeituoso (Controle de acesso quebrado)
- A6 - Desconfiguração de segurança (Configuração incorreta de segurança)
- A7 - Cross Site Scripting (Cross Site Scripting/XSS)
- A8 - desserialização insegura (Desserialização insegura)
- A9 - Uso de componentes com vulnerabilidades conhecidas (Usando componentes com vulnerabilidades conhecidas)
- A10 - Insuficiente registro e supervisão (Registro e monitoramento insuficientes)
E também dividido nas seguintes categorias para idiomas móveis:
- M1 - Uso impróprio da plataforma (Uso impróprio da plataforma)
- M2 - Armazenamento de dados inseguro (Armazenamento de dados inseguro)
- M3 - Comunicação insegura (Comunicação Insegura)
- M4 - autenticação insegura (Autenticação insegura)
- M5 - criptografia insuficiente (Criptografia insuficiente)
- M6 - autorização insegura (Autorização Insegura)
- M7 - Qualidade do código do cliente (Qualidade do código do cliente)
- M8 - Manipulação de código (Adulteração de código)
- M9 - Engenharia Reversa (Engenharia reversa)
- M10 - Funcionalidade estranha (Funcionalidade estranha)
Exemplo 1: .Net (A1- injeção)
Usar um mapeador relacional de objeto (ORM) ou procedimentos armazenados é a maneira mais eficiente de combater a vulnerabilidade de injeção de SQL.
Exemplo 2: Java (A2 - autenticação quebrada)
Sempre que possível, implemente a autenticação multifatorial para evitar ataques automatizados de preenchimento de credenciais, força bruta e reutilização de credenciais roubadas.
Exemplo 3: Java para Android (M3 - comunicação insegura)
É imperativo aplicar SSL / TLS aos canais de transporte usados pelo aplicativo móvel para transmitir informações confidenciais, tokens de sessão ou outros dados confidenciais para uma API de back-end ou serviço da web.
Exemplo 4: Kotlin (M4 - autenticação insegura)
Evite padrões fracos
Exemplo 5: NodeJS (A5 - Controle de acesso ruim)
Os controles de acesso do modelo devem impor a propriedade dos registros, em vez de permitir que o usuário crie, leia, atualize ou exclua qualquer registro.
Exemplo 6: Objetivo C (M6 - Autorização insegura)
Os aplicativos devem evitar o uso de números adivinhados como referência de identificação.
Exemplo 7: PHP (A7 - Cross Site Scripting)
Codifique todos os caracteres especiais usando htmlspecialchars () ou htmlentities () [se estiver dentro de tags html].
Exemplo 8: Python (A8 - desserialização insegura)
O módulo pickle e jsonpickle não é seguro, nunca use-o para desserializar dados não confiáveis.
Exemplo 9: Python (A9 - Usando componentes com vulnerabilidades conhecidas)
Execute o aplicativo com o usuário menos privilegiado
Exemplo 10: Swift (M10 - Funcionalidade estranha)
Remova a funcionalidade de backdoor oculta ou outros controles internos de segurança de desenvolvimento que não devem ser lançados em um ambiente de produção.
Exemplo 11: WordPress (Desativar XML-RPC)
XML-RPC é um recurso do WordPress que permite a transferência de dados entre o WordPress e outros sistemas. Hoje, ele foi amplamente substituído pela API REST, mas ainda está incluído nas instalações para compatibilidade com versões anteriores. Se habilitado no WordPress, um atacante pode realizar ataques de força bruta, pingback (SSRF), entre outros.
Conclusão
Nós esperamos isso "postinho útil" sobre o site chamado «Secure Code Wiki»
, que oferece conteúdo valioso relacionado a «Boas práticas de codificação segura »; é de grande interesse e utilidade, para todo o «Comunidad de Software Libre y Código Abierto»
e de grande contribuição para a difusão do maravilhoso, gigantesco e crescente ecossistema de aplicações de «GNU/Linux»
.
Por enquanto, se você gostou disso publicación
, Não pare Compartilhe com outras pessoas, nos seus sites, canais, grupos ou comunidades de redes sociais ou sistemas de mensagens preferidos, de preferência gratuitos, abertos e / ou mais seguros como Telegram, Signal, Mastodonte ou outro de Fediverse, preferencialmente.
E lembre-se de visitar nossa página inicial em «FromLinux» para explorar mais novidades, bem como aderir ao nosso canal oficial de Telegrama do FromLinux. Embora, para obter mais informações, você pode visitar qualquer Biblioteca online como OpenLibra y jedit, para acessar e ler livros digitais (PDFs) sobre este assunto ou outros.
Um comentário deixe o seu
Artigo interessante, deve ser obrigatório para todo desenvolvedor.