Hacking seu próprio aplicativo

Question

Eu sou um desenvolvedor web que é muito consciente de segurança e tentar fazer minhas aplicações web mais seguro possível.

Como sempre eu comecei a escrever minhas próprias aplicações do Windows em C # e quando se trata de testar a segurança do meu aplicativo C #, eu sou realmente apenas um principiante.

Basta saber se alguém tem alguma bons tutoriais / dos leia-me sobre como cortar o seu próprio aplicativo de janelas e escrever código seguro.

Answer 1

Os livros de Michael Howard são um ponto de partida bem;

• 19 pecados Capitais de segurança de software (com exemplos em vários línguas)
• Escrevendo código seguro

Há montes de links e artigos interessantes do blog de Michael Howard aqui

Há uma apresentação powerpoint interessante da Microsoft sobre a avaliação da ameaça, riscos e ASP aqui .

Answer 2

Além de todas as respostas óbvias para evitar estouros de buffer, injeção de código, sessão sequestro et. al. você deve encontrar alguém para verificar o seu código / software, porque você só pode pensar em maneiras de cortar o seu software que você sabe como prevenir. Só porque você não pode encontrar uma maneira de cortar o seu próprio software que não significa que ninguém mais pode.

Answer 3

Isso é algo que é muito difícil para você fazer, e eu acho que você está se aproximando o problema a partir do ângulo errado. Se você estiver escrevendo um aplicativo de qualquer tamanho, em seguida, tentar lidar com a segurança no final, por procurando maneiras específicas de quebrar o seu próprio software, é quase impossível.

Isto é para um número de razões. Você já pensa sobre o seu software de uma determinada maneira. Você pensa em maneiras específicas de interagir com ele, e você sabe como tirar o melhor dele. Você não pensa sobre isso em termos de maneiras de explorá-lo, e isso é uma coisa difícil de fazer com o software que você está intimamente familiarizado.

Outro problema é que a tarefa por este ponto é grande demais para lidar com eles. Quaisquer problemas que você encontrar pode abrir qualquer número de outros problemas. A verificação do sistema de largura segurança é longe de ser suficiente granular.

O que você deve fazer é pensar sobre a segurança enquanto você escreve o software. Aprender as melhores práticas, e considerar cada método e classe que você escrever a partir de uma perspectiva de segurança. Isto vai de mãos dadas com o teste de unidade, tente considerar o que entradas poderia fazer esta parte específica da minha pausa programa. e depois lidar com eles nesse nível.

Depois que eu acho que sua matéria um de responder rapidamente a quaisquer preocupações de segurança que são feitas cientes.

Answer 4

Pequenas coisas que eu já vi na minha própria experiência.

• Não use SQL dinâmico, então você está vulnerável a injeção de SQL. Prefere usar consultas SQL com parâmetros.
• não tem incrementado ids como user_id = 1, 2, 3 etc etc e, em seguida, usar isso em um URL, something.aspx? User_id = 1, então eu posso adivinhar a próxima esperança id e sessão. Idênticas para contas e que nunca mais é sensível.
• Watch para fora para XSS (Cross Site Scripting). Se você aceitar a entrada do usuário e armazená-lo diretamente, se certificar de que eles não podem ir inserção de alerta () para o seu nome ou algo assim.

Esta é de nenhuma maneira uma lista completa. Apenas o material que eu ter executado em pouco tempo.

Answer 5

Você poderia fazer muito pior do que a leitura Engenharia de Segurança do Ross Anderson livro. A primeira edição está disponível para download como um arquivo PDF e é uma boa leitura. Eu não li a segunda edição, mas eu suspeito que é melhor e tem mais guloseimas nela.

Do nota é um livro que explica como a segurança construção em desde o início, não como quebrar a segurança, mas a exposição das falhas de segurança variados deve dar-lhe uma boa idéia para onde começar a procurar.

Answer 6

Para garantir a sua aplicação forma vitória abri-lo e tentar fazer tudo que o usuário lambda não deve fazer! Vou explicar:

Se você "dizer entrar yes ou no", tente com A-Z, 0-9, porque isso é o que alguns usuários fazer para tentar encontrar algum traço de pilha que poderia ser interessante. Então coloque validadores em todos os lugares.

Cuidado com ligação a bases de dados, mas se você vem de dev web você deve ser mais consciente do que eu:).

A parte mais difícil é que atente sobre vazamentos de memória ou coisas do tipo, mas isso é em grandes grandes aplicações ou em aplicações não bem desenvolvido.