Existe uma maneira de impedir que o aplicativo que está sendo analisado ou injetado? (C #)

Question

Há um monte de profilers e analisadores de código estático lá fora, para montagens C #.

Apenas maravilha se houver qualquer métodos para evitar que está sendo analisado, porque me faz sentir um pouco nervoso ao ser despojado.

Eu tenho procurado em toda a Internet e stackoverflow. Não parece nada para o meu espanto.

O que eu tenho são apenas alguns títulos ainda mais assustador como estes (desculpe, novo usuário pode links não pós hiper, por favor google-los):

"Manipulação de montagem e C # / VB.NET Código Injection"

"Como injectar um Managed Assembly .NET (DLL) em outro processo"

É apenas me a ser demasiado preocupado ou o quê?

BTW, com C #, estamos construindo um novo cliente winform para os clientes de um banco fazer transações on-line. Não deveríamos fazer isso da maneira winform ou devemos usar alguma outra língua como Delphi, C ++? Atualmente, temos um cliente winform construído com C ++ Builder.

Answer 1

Apenas sobre qualquer aplicativo pode ser "analisados ??e injetados". Alguns mais que outros. É por isso que você NUNCA CONFIE entrada do usuário. Você validar totalmente os pedidos do seu usuário no lado do servidor, certificando-se de que você não é vulnerável a buffer derrapagens, injeção de SQL e outros vetores de ataque.

obfuscators pode fazer .NET montagens mais difícil de analisar. Usando uma chave segura para de nome forte vossas assembléias pode torná-lo muito mais difícil de alterar seu código. Mas, como tudo no mundo digital, alguém pode explorar uma vulnerabilidade e obter em torno de qualquer salvaguardas você colocar no lugar.

Answer 2

Se por você analisados ??alguém média Decompiling o código e olhar para ele, então o Dotfucstor que vem com o VS Pro e acima é uma simples (livre) ferramenta para ajudar aqui. Existe uma funcionalidade mais completa (mas pago) versão que pode fazer mais.

Para evitar que alguém mexendo com seus assmebliles implantado, use Nomes fortes .

Answer 3

Onde há uma vontade, há um caminho, se é o código gerenciado ou montagem nativa. A chave é manter as informações importantes na extremidade do servidor e manter o controle do que isso.

Answer 4

A primeira coisa que você precisa decidir contra o que você está tentando proteger? Obfuscators são úteis apenas para proteger algoritmos "molho secreto", mas o atacante pode simplesmente extrair o código e usá-lo como caixa-preta. Em 99% dos casos obfuscators são desperdício de dinheiro. Se o atacante tem acesso físico não há muito que você pode fazer.

Answer 5

Se o usuário final está sendo executado com privilégios administrativos em seguida, eles serão capazes de anexar um depurador, e modificar seu código, incluindo conta de destino detalhes. O meu banco local amigável deu-me um chip e pin leitor que eu tenho que digitar os últimos n dígitos da conta de destino, que hashes criptografa / com Chip do meu cartão de banco; Eu, então, introduzir o código do dispositivo para aplicação web do banco que pode verificar no final do banco também. Este "man in the middle" mitiga ataques do tipo ...

Answer 6

Segurança só é possível em sistemas que você controlar fisicamente o acesso a, e mesmo assim não garantida, apenas alcançável. Você deve assumir qualquer código não executar em um sistema que você controle pode e será comprometida. Como Rowland Shaw afirmou, a melhor aposta para uma instituição financeira é algum tipo de token físico que efetivamente acrescenta um componente único off-line para todas as operações que não podem ser (facilmente) conhecidos antes do tempo por um operacional atacante de um sistema comprometido. Mesmo assim, você deve estar ciente do fato de que, se o computador do usuário foi comprometida e ele faz login com o seu token seguro daquele ponto em diante até que a sessão termina o atacante está livre para executar quaisquer ações que o usuário tem permissão para, mas pelo menos nesse caso, o usuário é mais provável observar a atividade fraudulenta.