O que todo programador deve saber sobre segurança? [fechadas]

427

Sou estudante de TI e agora estou no terceiro ano na universidade. Até agora, estudamos muitos assuntos relacionados a computadores em geral (programação, algoritmos, arquitetura de computadores, matemática etc.).

Tenho certeza de que ninguém pode aprender tudo sobre segurança, mas com certeza há um conhecimento "mínimo" que todo programador ou estudante de TI deve saber sobre isso e minha pergunta é: qual é esse conhecimento mínimo?

Você pode sugerir alguns e-books ou cursos ou qualquer coisa que possa ajudar a começar com esse caminho?

security 
— MH
fonte
6
— Thomas
118
Regra 1: nunca confie na entrada do usuário. Nem mesmo se é sua avó
— Anthony Forloney
2
..e esta discussão também tem a grande informação - stackoverflow.com/questions/72394/...
— Sripathi Krishnan
minha pergunta não é apenas cerca de programadores e seus erros, também sobre ele e ciência da computação estudantes
— Mohamad Alhamoud
1
Assista suas mensagens de erro. Embora você queira ser amigável, a diferença entre "Esta conta não existe" e "A senha é inválida" pode ser perigosa em alguns casos.
— Michael Mior

Respostas:

551

Princípios a serem lembrados se você deseja que seus aplicativos sejam seguros:

  • Nunca confie em nenhuma entrada!
  • Valide a entrada de todas as fontes não confiáveis ​​- use listas de permissões e não listas negras
  • Planeje a segurança desde o início - não é algo que você possa usar no final
  • Mantenha a simplicidade - a complexidade aumenta a probabilidade de falhas na segurança
  • Mantenha sua superfície de ataque no mínimo
  • Verifique se você falhou com segurança
  • Use a defesa em profundidade
  • Aderir ao princípio do menor privilégio
  • Usar modelagem de ameaças
  • Compartimentalizar - para que seu sistema não seja tudo ou nada
  • Ocultar segredos é difícil - e os segredos ocultos no código não permanecerão em segredo por muito tempo
  • Não escreva sua própria criptografia
  • Usar criptografia não significa que você está seguro (os invasores procurarão um link mais fraco)
  • Esteja ciente dos estouros de buffer e como se proteger contra eles

Existem alguns excelentes livros e artigos on-line sobre como proteger seus aplicativos:

Treine seus desenvolvedores nas melhores práticas de segurança de aplicativos

Codebashing (pago)

Inovação em segurança (paga)

Bússola de segurança (paga)

OWASP WebGoat (grátis)

— bignum
fonte
+1 "explorar software: como quebrar código" é um ótimo livro, no entanto, a apresentação de slides a que você está vinculado é horrível.
— rook
7
No entanto, infelizmente, é quase impossível instanciar o princípio do menor privilégio em qualquer sistema moderno. Por exemplo, o kernel do Linux (fonte que estou usando atualmente) contém mais de 9,4 milhões de linhas de código C e mais de 400 mil linhas de montagem, todas executadas em um contexto irrestrito. Um simples erro de cálculo (talvez intencional) em um desses milhões de linhas comprometerá todo o sistema. Talvez no próximo século ou dois surja uma solução, talvez não, pois ninguém realmente se preocupa em criar sistemas operacionais / idiomas / estruturas seguras.
— L̳o̳̳n̳̳g̳̳p̳o̳̳k̳̳e̳̳
1
Eu adicionaria "O Manual do hacker de aplicativos da Web" a essa lista.
— Outcassed
34
Substitua "Nunca confie na entrada do usuário!" para "Nunca confie em nenhuma entrada!". As entradas provenientes de outro software devem ser tratadas da mesma forma que as entradas do usuário - por exemplo, no registro de sites, a maioria das pessoas não pensaria no campo User-Agent / ID do navegador como 'entrada do usuário', mas também pode conter, digamos, um Injeção SQL.
— Peteris
2
@ L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳ Bem, existe o SO experimental da Microsoft Research (Singularity), construído em .NET, que visava a segurança como objetivo principal (nenhum buffer estourou, sim!). Nenhum compartilhamento de memória de processo, nenhuma modificação do código, até os drivers de dispositivo são apenas outro processo isolado de software no .NET. Um conceito bastante interessante, mas seria muito difícil enviar isso para as pessoas (o mais importante é que praticamente não é possível fazer compatibilidade com versões anteriores de software ou drivers existentes; um pouco como os primeiros 10 anos do Linux: D).
— Luaan
102

Regra nº 1 de segurança para programadores: não crie seu próprio

A menos que você seja um especialista em segurança e / ou criptografador, sempre use uma plataforma, estrutura ou biblioteca de segurança bem projetada, bem testada e madura para fazer o trabalho por você. Essas coisas passaram anos sendo pensadas, corrigidas, atualizadas e examinadas por especialistas e hackers. Você deseja obter essas vantagens, não descartá-las, tentando reinventar a roda.

Agora, isso não quer dizer que você não precise aprender nada sobre segurança. Você certamente precisa saber o suficiente para entender o que está fazendo e verificar se está usando as ferramentas corretamente. No entanto, se você estiver prestes a começar a escrever seu próprio algoritmo de criptografia, sistema de autenticação, desinfetante de entrada, etc., pare, dê um passo atrás e lembre-se da regra nº 1.

— Tyler McHenry
fonte
10
Esta é uma regra ruim na minha opinião. Você pode ser segmentado basicamente apenas por causa da plataforma selecionada, e não por qualquer interesse real em seus ativos. Pense em todas as brechas de segurança encontradas em plataformas de terceiros e em todos os produtos que são instantaneamente vulneráveis ​​apenas por serem usados. Eu não seria tão rápido em confiar minha segurança a terceiros.
— Fosco
9
Eu acho que essa é uma boa regra para o Crypto - rolar sua própria criptografia é uma receita para o desastre. Mas rodar seu próprio mecanismo de blog pode ser mais seguro, como Fosco aponta - se você rodar o seu próprio, é menos provável que seja pego por ataques automatizados com os quais as instalações do wordpress precisam lidar.
— James P McGrath
5
Quando se trata de criptografia, essa regra está absolutamente correta. Não escreva sua própria criptografia, ponto final. Quando se trata de usar plataformas de terceiros, isso depende. Algumas plataformas são inerentemente mais seguras, outras são inerentemente menos seguras e provavelmente fornecem alguns recursos de segurança, mas também alguns vetores de ataque conhecidos. Veja a recente vulnerabilidade do Rails que causou uma falha de segurança no github . Sem dúvida, o Rails fornece muitos recursos de segurança, mas também possui alguns recursos poderosos com padrões inseguros.
— Michael Kopinsky
7
Quando se trata de criptografia, não faça o seu próprio - mas entenda o que você está usando. Se você não entender por que usar a mesma chave de criptografia do RC4 para duas mensagens é uma ideia horrível, leia antes de usar qualquer cifra de fluxo, por exemplo.
— Christopher Creutzig
3
Mesmo após o bug do HeartBleed, é evidente que essa é uma boa regra. Imagine o quão difícil teria sido encontrar um bug semelhante ao calor em um projeto personalizado ou proprietário. Se você rodar sozinho, estará apenas se escondendo atrás da obscuridade e não saberá quais bugs poderiam estar sendo explorados.
— Sqeaky
71

Todo programador deve saber escrever código de exploração.

Sem saber como os sistemas são explorados, você acidentalmente interrompe as vulnerabilidades. Saber como corrigir o código não faz absolutamente sentido, a menos que você saiba como testar seus patches. A segurança não é apenas um monte de experimentos mentais, você deve ser científico e testar seus experimentos.

— torre
fonte
10
Eu diria que isso não é necessário. Apenas siga o princípio: se o invasor puder causar qualquer tipo de corrupção na memória, considere-se o dono. Não há necessidade de entrar em detalhes sobre realmente escrever (trabalhando) explorações.
— newgre 26/03
6
@newgre nem toda vulnerabilidade é um buffer overflow. Existem alguns milhares de vulnerabilidades cobertas pelo sistema Common Weakness Enumeration. Um programador precisa entender a mente do atacante ou ele, sem saber, cometerá erros.
— rook
1
Eu sei que nem todos eles são um estouro de buffer, mas qualquer coisa que é geralmente chamada de "exploração" é baseada em algum tipo de corrupção de memória: estouros de buffer, liberações duplas, estouros de heap, estouros relacionados a números inteiros, seqüências de caracteres de formato , etc. É claro que existem outras coisas, como erros de lógica, mas esse não era o tópico desta resposta para começar.
— newgre
5
@newgre Esse é um tipo de exploração, mas hoje mais explorações são criadas para aproveitar falhas de aplicativos da Web do que problemas de corrupção de memória. As explorações são gravadas utilizando a Injeção SQL, o Arquivo Local inclui, CSRF e XSS, esses são os problemas comuns. (Source: exploit-db.com )
— rook
1
Eu concordo com isso, se você mesmo pode escrever explorações, pode entender o que pode levar à mente dos hackers, no máximo!
— Linuxeasy 29/03/12
42

A segurança é um processo, não um produto.

Muitos parecem esquecer essa questão óbvia de fato.

— ericteubert
fonte
23

Sugiro revisar os 25 erros de programação mais perigosos do CWE / SANS . Foi atualizado para 2010 com a promessa de atualizações regulares no futuro. A revisão de 2009 também está disponível.

De http://cwe.mitre.org/top25/index.html

Os 25 erros de programação mais perigosos da CWE / SANS 2010 são uma lista dos erros de programação mais comuns e críticos que podem levar a sérias vulnerabilidades de software. Eles geralmente são fáceis de encontrar e fáceis de explorar. Eles são perigosos porque frequentemente permitem que os invasores assumam o controle do software, roubem dados ou impedam o funcionamento do software.

A lista das 25 principais é uma ferramenta de educação e conscientização para ajudar os programadores a evitar os tipos de vulnerabilidades que afetam a indústria de software, identificando e evitando erros muito comuns que ocorrem antes mesmo do envio do software. Os clientes de software podem usar a mesma lista para ajudá-los a solicitar um software mais seguro. Pesquisadores em segurança de software podem usar o Top 25 para se concentrar em um subconjunto restrito, mas importante, de todos os pontos fracos de segurança conhecidos. Por fim, os gerentes de software e os CIOs podem usar a lista das 25 principais como uma medida do progresso de seus esforços para proteger seu software.

— jschmier
fonte
1
Observe que os quatro principais erros nessa lista (e vários outros) também são os mesmos dados que confiam em erro.
— Chris Dodd
13

Um bom curso para iniciantes pode ser o curso do MIT em Redes e Segurança de Computadores . Uma coisa que eu sugeriria é não esquecer a privacidade. A privacidade, em alguns sentidos, é realmente fundamental para a segurança e geralmente não é abordada em cursos técnicos sobre segurança. Você pode encontrar algum material sobre privacidade neste curso sobre ética e direito no que se refere à Internet.

— tvanfosson
fonte
O link do curso do MIT não funciona
— AntonioCS
1
Links corrigidos (por enquanto). Obrigado.
— tvanfosson
10

A equipe de segurança da Web da Mozilla montou um ótimo guia , que respeitamos no desenvolvimento de nossos sites e serviços.

— Potch
fonte
8

A importância de padrões seguros em estruturas e APIs:

  • Muitas estruturas da Web anteriores não escapavam do html por padrão nos modelos e tinham problemas com o XSS por causa disso.
  • Muitas estruturas da Web anteriores tornaram mais fácil concatenar o SQL do que criar consultas parametrizadas, levando a muitos bugs de injeção de SQL.
  • Algumas versões do Erlang (R13B, talvez outras) não verificam certificados SSL por padrão e provavelmente há muito código erlang suscetível a ataques SSL MITM
  • O transformador XSLT de Java, por padrão, permite a execução de código java arbitrário. Houve muitos erros graves de segurança criados por isso.
  • As APIs de análise XML do Java, por padrão, permitem que o documento analisado leia arquivos arbitrários no sistema de arquivos. Mais divertido :)
— benmmurphy
fonte
5

Você deve saber sobre os três A's. Autenticação, Autorização, Auditoria. O erro clássico é autenticar um usuário, embora não verifique se o usuário está autorizado a executar alguma ação, para que um usuário possa ver fotos particulares de outros usuários, o erro da Diáspora. Muitas outras pessoas esquecem-se do Audit, é necessário, em um sistema seguro, poder saber quem fez o que e quando.

— rapadura
fonte
1
Nem toda autorização requer autenticação. "Do ABAC ao ZBAC" contrasta o controle de acesso NBAC (baseado em autenticação) com soluções que não exigem autenticação. "IBAC, RBAC, ABAC e até CBAC - Controle de Acesso Baseado em Reivindicações dependem da autenticação ... Por simplicidade, este documento os trata como uma solução única e ignora as versões que implementaram aspectos da arquitetura ZBAC. Elas são coletivamente chamadas de autenticação. Controle de acesso baseado em dados (NBAC). "
— Mike Samuel
4
  • Lembre-se de que você (o programador) precisa proteger todas as partes, mas o atacante precisa apenas encontrar uma torção na sua armadura.
  • A segurança é um exemplo de "incógnitas desconhecidas". Às vezes, você não saberá quais são as possíveis falhas de segurança (até depois).
  • A diferença entre um bug e uma falha de segurança depende da inteligência do atacante.
— Rory
fonte
4

Eu adicionaria o seguinte:

  • Como assinaturas digitais e certificados digitais funcionam
  • O que é sandbox

Entenda como diferentes vetores de ataque funcionam:

  • Buffer overflows / underflows / etc no código nativo
  • Engenharia social
  • Falsificação de DNS
  • Homem no meio
  • CSRF / XSS e cols.
  • injeção SQL
  • Ataques de criptografia (por exemplo: exploração de algoritmos de criptografia fracos, como DES)
  • Erros de programa / estrutura (por exemplo: falha de segurança mais recente do github )

Você pode facilmente pesquisar no google por tudo isso. Isso lhe dará uma boa base. Se você deseja ver as vulnerabilidades de aplicativos da web, existe um projeto chamado google gruyere que mostra como explorar um aplicativo da web em funcionamento.

— Miguel Ping
fonte
4

quando você está construindo uma empresa ou qualquer um de seu próprio software, deve pensar como um hacker. Como sabemos, os hackers também não são especialistas em tudo, mas quando encontram alguma vulnerabilidade, começam a investigar reunindo informações sobre todas as coisas. as coisas e, finalmente, atacar o nosso software. para impedir esses ataques, devemos seguir algumas regras bem conhecidas, como:

  • tente sempre quebrar seus códigos (use folhas de dicas e pesquise no google as coisas para obter mais informações).
  • ser atualizado para falhas de segurança em seu campo de programação.
  • e, como mencionado acima, nunca confie em nenhum tipo de usuário ou em entradas automatizadas.
  • use aplicativos de código aberto (suas falhas de segurança mais conhecidas e solucionadas).

você pode encontrar mais recursos de segurança nos seguintes links:

para obter mais informações, google sobre os fluxos de segurança do fornecedor do aplicativo.

— rahul_pratap
fonte
3
  1. Por que é importante.
  2. É tudo sobre trade-offs.
  3. A criptografia é basicamente uma distração da segurança.
— Richard
fonte
3

Verifique também a Lista das 10 principais da OWASP para obter uma categorização de todos os principais vetores / vulnerabilidades de ataque.

Essas coisas são fascinantes de se ler. Aprender a pensar como um invasor o treinará sobre o que pensar ao escrever seu próprio código.

— Michael Kopinsky
fonte
2

Sal e hash as senhas de seus usuários. Nunca salve-os em texto sem formatação no seu banco de dados.

— Abdull
fonte
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.