Problema de segurança sobre como tornar meu código público no GitHub

8

Estou desenvolvendo um grande site de comunidade / fórum e gostaria de enviar meu código para o GitHub para ter pelo menos algum tipo de controle de versão (porque não tenho nada além de um arquivo .rar como backup, nem mesmo SVN ), para permitir que outras pessoas contribuam para o projeto, e talvez também o utilize para permitir que meus futuros empregadores em potencial vejam parte do meu código como uma espécie de currículo.

Mas o que estou pensando agora, e estou surpreso por nunca ter visto alguém mencionar isso antes, é o aspecto de segurança. A publicação do código de um site não é uma enorme falha de segurança? É como dar a um hacker em potencial ou a alguém que gostaria de encontrar uma possível exploração possível, mesmo considerando que os arquivos críticos não foram carregados (senhas do banco de dados, scripts de autenticação etc.).

É claro que existem milhões de projetos enviados ao GitHub e ninguém encontrará o meu apenas 'por acaso'. Mas se eles procurarem, realmente estaria lá.

Bottomline: meu problema não é sobre direitos autorais ou licenças, mas outras pessoas descobrindo façanhas no meu site.

Estou faltando alguma coisa aqui?

open-source security github

— federico-t
fonte

4

A segurança pela obscuridade não funcionou bem para a maioria dos softwares até agora. O código fonte é apenas uma peça do quebra-cabeça!

— precisa

2

Use o BitBucket. Ele também suporta git.

— Jó

Portanto, não há explorações óbvias em seu site para as pessoas encontrarem? Por exemplo, se as pessoas puderem identificar no seu código-fonte onde estão as vulnerabilidades da injeção SQL, você também poderá.

— user16764

Como o @delnan aponta abaixo, o GitHub permite que você hospede acordos privados por um preço. Além dos milhões de projetos públicos (código aberto) que você pode ver, provavelmente existem milhões de projetos privados no GitHub que ninguém fora do proprietário / colaboradores do projeto jamais verá.

— Suman

1

Se nada mais criar um repositório git local. Dessa forma, você pode pelo menos reverter quando cometer um erro.

— Zachary K

24

Estou faltando alguma coisa aqui?

Sim. Confiar nas pessoas que não conhecem o seu código-fonte para impedir que encontrem explorações de segurança nele é conhecido como segurança através da obscuridade .

O problema: não funciona. Os hackers qualificados não precisam do código fonte para encontrar e explorar vulnerabilidades. Eles fazem algumas buscas para encontrar informações que causam problemas e, em seguida, usam seu conhecimento de como o sistema operacional / idioma / estrutura subjacente funciona para identificar uma vulnerabilidade.

É amplamente aceito que ter o código fonte público aumenta a segurança, permitindo que pessoas bem-intencionadas encontrem vulnerabilidades e as corrijam ou, pelo menos, digam ao desenvolvedor sobre elas. Há duas razões importantes pelas quais isso funciona:

Geralmente, há mais bem-intencionado que pessoas mal-intencionadas
Qualquer vulnerabilidade encontrada por uma pessoa bem-intencionada será corrigida para todos; hackers são muito menos propensos a colaborar

Obviamente, ele não funciona com projetos de animais de estimação que possuem poucos usuários ativos, mas também é extremamente improvável que eles sejam direcionados por um hacker.

— Michael Borgwardt
fonte

1

Não que eu concorde ou discorde, mas "amplamente aceito" por quem? Este não é um sentimento que realmente ouvi expressar.

— 9118 Steven Stevers

Obrigado pela resposta rápida, cara! E faz sentido quando penso nisso, é uma troca entre compartilhar algo que já teria sido encontrado por hackers qualificados e obter informações adequadas de programadores bem-intencionados. Claramente, eu não tinha pensado dessa maneira. Obrigado novamente!

— Federico-t

@SnOrfus: veja a Lei de Linus e o princípio de Kerckhoffs. É certo que "amplamente aceito" pode ser um exagero, mas eu apostaria que a maioria dos programadores experientes concordaria.

— 22612 Michael Borgwardt

@ MichaelBorgwardt, eu apostaria que a maioria dos programadores experientes discordaria . Os chamados "mais globos oculares = menos vulneráveis" não se baseiam em pesquisas apropriadas . Heartbleed não é o primeiro e não será o último. Veja também blog.codinghorror.com/given-enough-money-all-bugs-are-shallow

— Pacerier

@ Pacerier: Aceito essa aposta a qualquer momento. Observe que a afirmação é de que o código aberto aumenta a segurança, não que resulta em segurança perfeita. Você pode citar exemplos de bugs no OSS até que as vacas cheguem em casa e isso não prova absolutamente nada ao contrário. Há, na verdade, é uma investigação adequada: archive.wired.com/software/coolapps/news/2004/12/66022 - sim, é mais de 10 anos de idade, mas até que você pode encontrar algo concreto com resultados contrários, destaca.

— Michael Borgwardt

6

Primeiro, você pode usar o controle de versão (distribuído) sem tornar o repositório público. Você pode simplesmente criar um repositório em seu computador local e pressionar / puxar de outros computadores. Você também pode fazer upload do repositório (oferecendo mais backups e colaboração mais fácil) sem torná-lo público. O GitHub oferece repositórios privados por uma taxa, o Bitbucket faz o mesmo e torna pequenos (5 pessoas ou algo) repositórios particulares gratuitos. Obviamente, você não recebe os outros benefícios mencionados.

O aspecto da segurança é bastante pequeno. Existem muitos, muitos vetores de ataque que valem a pena testá-los facilmente sem consultar o código-fonte (do lado do servidor) (como estar atento aos parâmetros GET e POST, verificar cookies e manipulação de sessões, adicionar entradas que devem ser escapadas e verificar se estiverem, etc.). Se você é vulnerável a qualquer um deles, um invasor determinado pode explorá-los razoavelmente rapidamente, sem consultar o código-fonte. Erros mais obscuros e difíceis de explorar (provavelmente) também são mais difíceis de detectar no código-fonte; portanto, novamente, você não perde muito.

Por outro lado, torná-lo público e aceitar contribuições pode atrair pessoas que podem detectar façanhas, sem sentido impróprio, e falar sobre elas (ou até mesmo consertá-las). Isso vale duplamente se é realmente popular, mas você não é um especialista em segurança (sem ofensa, mas não soa como um; por exemplo, você não mencionou segurança por obscuridade e como sua preocupação não é um caso disso) .

Como eu disse a Michael Borgwardt, isso faz todo o sentido. Suponho que o benefício de publicar o código seja ainda maior quando mais pessoas souberem do projeto e fornecerem contribuições para corrigir explorações. E se não fosse popular, provavelmente os hackers em potencial também não se importariam o suficiente. Obrigado pela resposta!

— Federico-t

Até onde eu sei, o github não oferece repositórios privados gratuitos (uma correção menor, não um nitpick).

— scrwtp

@ scrwtp: 'mediante taxa' não é o mesmo que gratuito.

— precisa

Ah, verdade, eu interpretei errado.

— scrwtp

3

O BitBucket tem repositórios privados gratuitos e suporta git e mercurial.

— jiggy
fonte

2

Deixando de lado o problema de segurança e se tornar seu código público o aprimoraria ou não, você mesmo pode configurar um sistema de controle de origem em sua máquina. No caso do git, é trivial, basta inicializar um repositório local e pronto, mas definir um SVN também não é uma tarefa assustadora. Talvez uma ou duas horas após os tutoriais, se você tiver pouco conhecimento prévio sobre como configurar o SVN.

Portanto, você ainda pode se beneficiar do controle de origem, independentemente de acabar usando um serviço online ou não.

— scrwtp
fonte

0

A maioria dos hackers maliciosos é feita anonimamente. Alguém na Rússia executando um script que verifica os hosts em busca de portas abertas ou o que você tem. Ninguém vai derramar explicitamente seu código apenas para encontrar uma maneira de invadir e causar danos. A menos que você realmente irrite alguém.

— nbv4
fonte