CONCLUSAO SOBRE STRING DE CONEXAO EM DOT.NET

LUIS.HERRERA 04/04/2012 13:55:03
#399099
Boa tarde amigos. Desculpe voltar a este assunto, mas ao menos para mim é de fundamental importância. Assim se puder ajudar a alguém, já me dou por satisfeito pelo grande tempo que perdi com este estudo.

Após um mês pesquisando muito na web e fazendo todos os testes que estavam ao meu alcance, compartilho as conclusões que cheguei.

Não importa o que se faça num programa Dot.Net para proteger as string de conexão usadas nele, não há como proteger.

Podem usar:

- a criptografia nativa da MS para app.config,
- criar uma rotina própria de criptografia no próprio programa, dependências ou usar o framework,
- gravar externamente já criptografada e depois importando e descryptogranfando direto na passagem da conexão ex:
public static SqlConnection cn = new SqlConnection([Ô]server=Servidor\\SQLEXPRESS;database=SeuBanco;user=sa;pwd=qualquercoisa;Trusted_Connection=False;[Ô]);

- usar o melhor ofuscador, configurado ao máximo de segurança, [txt-color=#e80000](só protege contra o Reflector + Dll Disassembler. Testei na versão 2010)[/txt-color]
- Pode mudar a forma do builder no VS de (Debug para Release) que é o correto antes de gerar o MSIL
- Usar StrongNames [txt-color=#e80000](isso só impede que seu arquivo seja alterado e substituido nada mais), [/txt-color]ou
- Usar um Webservice para receber a string de conexão.

Não importa o que façamos, ao rodar a aplicação e realizar a abertura do banco ( cn.Open(); ), através da leitura da RAM é possível identificar facilmente o objeto conexão e acessar a sua string de conexão ex: cn.ConectionString. Pronto toda a string está exposta para quem quiser ver.

Com isso, a menos que alguém poste um exemplo que realmente impeça isso, posso assegurar que não há como proteger strings de conexão no Dot.Net.

Com isso concluo duas coisas:

1- Sempre usar autenticação windows na conexão com o banco de dados, para proteger Usuário e Senha, porém não sei se outros bancos, além do SQL server permite isso.
2- Acessar banco de dados externos (seja seu como desenvolvedor ou de outros empresas para acesso por terceiros), só via serviço Web ou páginas PHP, ASP, etc.. que a página faça o acesso e devolva as informações ao aplicativo, nunca direto pelo seu aplicativo.

OBS.: Sinceramente espero estar enganado, mas testei tudo acima e consegui recuperar a string, o único trabalho é localizar o objeto usado para conexão no código, mas há recurso de pesquisa no software que pode ajudar.
KERPLUNK 04/04/2012 14:05:12
#399100
Resposta escolhida
1 - O que você usou para a leitura da RAM?
2 - Você pode criar um webservice que contenha métodos de pesquisa, inclusão, exclusão... e retorne somente objetos já populados. Assim, a string de conexão, estaria no SERVER, portanto mais difícil de se pegar, à menos que o indivíduo mal-intencionado possua acesso direto ao server, mas daí a falha de segurança é bem maior.
LUIS.HERRERA 04/04/2012 15:35:27
#399113
Kerplunk vamos lá:

2- Sim o [Ô]lance[Ô] de usar todo acesso direto na Web, ok acho que é o úncio caminho e comentei isso no item ( 2 ) da minha conclusão (ao final do texto). O unico problema neste caso para mim, é que meu site é MySQL e PHP (sendo que conheço muito pouco de PHP) só um mínimo. Então peguei alguns scripts, e tutoriais e fiz os acessos que precisava, como área restrita, download, e alguns acessos ao banco para consulta. Agora criar toda uma ferramenta de gerenciamento do banco para receber solicitações e devolver dados a um aplicativo C#, nossa.

Já estou apanhando com o C#, SQL Server, Framework 3.5, ADO.NET, OOP, etc.. etc... A cada linguagem ou tecnologia que inicio, puxa outra, assim eu não consigo concluir nenhuma (risos).

1- Agora sobre o progrma, isso eu discuti muito em outros dois posts do ano passado. O último para quem quiser ler teve 650 acessos até hoje.
Clica aqui

Nele houve muita discussão e disseram que havia como resolver, só que ninguém disse efetivamente como. Então fui atrás. Os nomes dos programas foram informados naquele post e em outros onde o assunto surgiu aqui no fórum, mas segue novamente.

Para abrir qualquer programa em Dot.Net usam o Reflector (mais famoso, mas existem vários)
Para realizar a engenharia reversa, usa-se o DLL Disassembler ( que é um recurso acoplado ao Reflector)
Para ler tudo na memória RAM de um programa Dot.Net, usa-se o Crack.Net.

Este último tem duas etapas, a primeira abre um programa de monitoramento. Ao se executar algum programa Dot.Net ele imediatamente o identifica, mas se ao ser executado ja existir algum em execução ele também os identifica todos na hora. Se pode dar um refresh a qualquer momento. Depois se seleciona numa combo o aplicativo que se quer monitorar, entre os que estão em execução. E clica-se no botão logo abaixo.

Isso irá abrir o programa para bisbilhotar a seus objetos e variáveis na RAM, percorrer tudo dentro dele ou de qualquer namespace Dot.Net.

Inclusive, deste programa, se pode chamar diretamente o Reflector para abrir o seu aplicativo e também analisar as rotinas ou decompilar com o DLL Disassembler.

Agora como disse, o antídoto para o Reflector e DLL Disassembler é um Excelente ofuscador. Estou usando o Crypto Obfuscator For Net 2010. A versão 2012 parece ser muito melhor, mas não tenho. Com ele não se pode ver muita coisa do fonte original, ou reverter o EXE para fonte.

Agora esconder alguma coisas do Crack.Net, isso eu não consegui.

Nota: Ele tem muitos recursos, não consegui ver muita coisa ainda, só a navegação item a item do aplicativo, onde com alguns cliques se localiza qualquer string do programa. Foi assim que vasculhei e achei o objeto conexão da SQLCliente e peguei a propriedade Conection ( que nada mais é que uma string também). Nele se percorre todos os componentes do framework também ou se muda valores.

Eu até consegui [Ô]esconder[Ô] a string, incluíndo ela criptografada com algumas artimanhas, mas na hora que ela é descriptografada para associar ao objeto conection, aí já era.

Se alguém descobrir mais alguma coisa, compartilhem aqui. Estou a alguns meses correndo atrás de segurança e tudo que descubro eu posto aqui no VBM para conhecimento de todos.

KERPLUNK 04/04/2012 15:54:01
#399117
Tenho uma ferramenta que desenvolvi, que cria um [Ô]Framework[Ô] de aplicação à partir de um banco de dados(apenas SQL Server por enquanto). Muito parecido com o que o entity Framework faz, mas bem mais simplificado e muito mais fácil de acompanhar o que está sendo feito. Ainda tem algumas falhas, mas já pode ser usado.
O seu site, é muito grande? Porque se for pequeno(até umas 30 páginas de complexidade média) vale muito à pena migrar para ASP.NET e desfrutar de todas as vantagens do .NET.
Como seu site é PHP + MySQL, suponho que o server seja Linux, o que é bem comum, nesse caso, deixe como está.
Fazer o PHP consumir um webservice é bem fácil. Você cria as entidades e métodos que você precisa no seu webservice e consome no PHP.

Mas uma coisa é certa: Não existe absolutamente nada(em se tratando de informática) que seja 100% seguro, sempre tem um jeitinho de se burlar, não importa o que seja. Essa situação se agrava quando sua aplicação é Windows Forms, pois ela fica instalada na máquina do usuário e tudo que acontece, vai pra RAM, ou passa pela placa de rede, ou qualquer outra coisa assim. Por isso, aplicações Desktop, sempre estarão muito mais vulneráveis nesse sentido.
Claro, uma aplicação Web, não é a panacéia da segurança. Aplicações Web também têm suas vulnerabilidades, mas a coisa dificulta um pouco por que a aplicação roda no servidor onde o usuário geralmente não tem acesso. Mas é como falei, não existe nada 100% seguro. O que existem são maneiras de dificultar que seu sistema seja burlado.
LUIS.HERRERA 04/04/2012 15:56:01
#399118
Esqueci de um outro teste que fiz, a criptografia da RAM, ou seja encriptar o conteúdo da variável na RAM. Isso até deu um problema, que não fui atrás de resolver, que foi travar o programa no Windows e não consegui fechar nem desativar o serviço que ele alocou, só desligando o Windows na [Ô]Marra[Ô], mas acho que foi algo errado que fiz, na hora de fechar o programa e não liberar a criptografia da memória.

Porém esse recurso não vi como integrar ao objeto conection para encriptá-lo, pois talvez isso causasse Erro geral no Windows e SQL Server, pois encriptar a conexão aberta com o SQL acho que não dá. Por isso não fiz esse teste.
LUIS.HERRERA 04/04/2012 16:54:57
#399133
Kerplunk você disse que o PHP pode consumir um webservice, mas entendo que esse webservice deva ser escrito também em PHP ou alguma linguagem binária para linux correto? Pois acho que um webservice do Visual Studio (ASP) não rodaria.

O problema é justamente esse, terei de ter outras ferramentas específicas para isso e aprender essa outra linguagem para criar esse Webservice, só para esconder a string de conexão. Lógico é mais a [Ô]Montanha[Ô] de trabalho para esconder um texto que ficou vulnerável no Dot.Net, é coisa da Microsoft mesmo não?

Se só existir essa opção, eu terei de dixar por último, quando o sistema estiver pronto o que ainda vai demorar.

Também não sei se o servidor de hospedagem do site tem os recursos para rodar webservice instalados. Lí que existem bibliotecas específicas que devem ser instaladas no servidor Web e configuradas para o PHP usar. Agora não dá para mudar site para ASP, pois além da migração da hospedagem e custo, teria de recriar o site com SQL Server e aprender ASP também, acho que com 100 anos terminaria de aprender tudo sozinho e ainda dar suporte aos cliente da versão VB6, incluir melhorias, etc... etc... e ainda vender o sistema uuuffffaaaaaa....
KERPLUNK 04/04/2012 17:03:49
#399136
Citação:

Kerplunk você disse que o PHP pode consumir um webservice, mas entendo que esse webservice deva ser escrito também em PHP ou alguma linguagem binária para linux correto? Pois acho que um webservice do Visual Studio (ASP) não rodaria.


Com certeza que dá pra consumir sim. WebService pode ser escrito em qualquer linguagem, o modo de funcionamento é o mesmo...

Citação:

problema é justamente esse, terei de ter outras ferramentas específicas para isso e aprender essa outra linguagem para criar esse Webservice, só para esconder a string de conexão


Não mesmo. O webservice pode ser escrito em C# ou VB.NET normalmente, como qualquer outra biblioteca(DLL) a única diferença é que os métodos que você quer que sejam [Ô]consumíveis[Ô], ou seja, que outras aplicações podem acessar, devem ter o atributo [WebMethod], assim:
[WebMethod]
private string BuscarDados()
{
return [Ô]dados que são buscados do banco e tal...[Ô];
}

Ao fazer métodos assim, basta que estejam em uma aplicação [Ô]WebService[Ô] e publicar, esses métodos podem ser consumidos normalmente por qualquer linguagem, incluindo PHP, Java...

Quanto ao custo de servidor isso sim, se está em um servidor pago, provavelmente vai ter mudança de preço, mas não é nada absurdo não...
KERPLUNK 04/04/2012 17:16:42
#399139
Só pra complementar:
Imagine que você tem uma DLL que faz todo o acesso à dados que sua aplicação precisa, sem depender em nada da UI, que ele tem métodos para inserção, deleção e seleção e tudo mais que precisa, que recebem como parâmetros objetos que são classes que também estão nessa DLL.
Essa sua DLL pode ser referenciada em qualquer projeto e ser utilizada normalmente através de seus métodos e objetos, certo?
Se consegue entender esse paradigma, você já sabe também como funciona um webmethod, ele é como uma DLL que ao invés de ficar na sua máquina e ser referenciado na sua aplicação, ele simplesmente fica em uma outra máquina, mas os métodos, classes, objetos e tudo mais que exista nessa DLL, vai poder ser acessado remotamente.

Estou terminando uma série de artigos, em que eu explico como fazer uma DLL totalmente independente de UI, com todos os métodos CRUD, incluindo de pesquisa;

A primeira parte dos artigos, ensino como criar essa DLL e passo um programinha que eu mesmo fiz, que cria essa DLL(incluindo todas as classes necessárias) e o projeto dessas classes, à partir de uma connectionstring, ficou bem legal. Loguinho eu publico aqui.

A segunda parte, é criar um webservice que use essa DLL

A terceira, uma UI desktop que consuma o webservice e uma que consuma a DLL diretamente

A quarta, uma UI web, que consuma o webservice e uma que consuma a DLL diretamente

Vou publicar tudo quando estiver pronto...
LUIS.HERRERA 04/04/2012 17:45:13
#399143
Nossa vou ficar aguardando.

Só uma coisa, DLL não é windows, então como funcionaria no Linux para o PHP usar?
Quando você disse consumir remotamente, quer dizer exatamente o PHP consumir a Webservice para devolver alguma coisa ao programa desktop. Nesse caso para devolver ao meu aplicativo, teria de ser em XML só que nesse já seria um outro assunto como o PHP chamado pelo meu programa desktop iria devolver a ele esse xml que deveria ser usado internamento.
KERPLUNK 04/04/2012 17:49:24
#399144
Citação:

Só uma coisa, DLL não é windows, então como funcionaria no Linux para o PHP usar?


Se a DLL e webservice foram feitos em .NET a única maneira de rodar no linux é usando o Mono

Consumir remotamente não quer dizer que a aplicação que vai trabalhar com o webservice, precise necessariamente ser uma linguagem Web, pode-se consumir um webservice até com uma aplicação Console. Não precisa de nenhuma [Ô]ponte[Ô] para isso...
LUIS.HERRERA 05/04/2012 09:47:53
#399181
Então o que eu disse é que se o Webservice é Windows (Net) enão ele não rodaria no site linux. Acredito que o servidor não tenha mono, pois eles tem um pacote Linux e outro Microsoft, teria então de migrar todo o site para isso e banco de dados, mas isso seria outra história.

Só para concluir o racioncínio. O Webservice obrigatoriamente teria de ficar no site e não local certo?
Isso porque como é um programa Dot.Net, se ficasse local poderia ser aberto pelo Crack.Net e não resolveria nada.
Assim acho que agora um webservice realmente não seria possível no site.
Página 1 de 2 [14 registro(s)]
Tópico encerrado , respostas não são mais permitidas