Dica de Segurança no Arquivo de Configuração - Web / App .config

por Mauricio Junior em 1/1/2011 0

Ferramenta utilizada: Visual Studio.NET 2008

Linguagem: C#.NET

Framework: 3.5 .NET

Funciona em qualquer versão do framework: SIM

Referência: 1.0

Olá pessoal, o objetivo desse pequeno artigo é mostrar como é importante as informações que existem junto ao arquivo de configuração chamado web.config do seu sistema.

Nos softwares que desenvolvemos junto a ferramenta Visual Studio.NET tem nos ajudado a ser mais informatizado a cada dia, porém precisamos oferecer aos nossos clientes ou ao nosso próprio software, a segurança devida.

Segurança no software, quanto nos arquivos que existem dentro do servidor, pense comigo: “Imagine que no seu software possui uma segurança legal, criptografia ao entrar com usuário e senha, HTTPS, SSL, Contra Scriptled e muito mais. Só que, se um hacker, cracker ou lammer entrar em seu servidor, ou seja, invadir o servidor onde hospeda seu site/sistema, acesso aos seus arquivos será transparente, inclusive o arquivo de configuração. Automaticamente, o usuário mal intencionado poderá acessar o seu banco de dados, com usuário e senha”.

Concorda comigo que isso é muito perigoso? Mesmo que o usuário tenha apenas leitura no banco de dados, poderá ver os seus dados e dados de seus clientes. Para resolver este problema, acabei configurando e criptografando a conexão com o banco de dados dentro do web.config. Mesmo que alguém entre no servidor e no arquivo de configuração, não conseguirá pegar as informações.

No momento da conexão, já no código fonte do programa; eu retiro a criptografia online, ou seja, sem mudar o arquivo .cofing; conecto e faço o que for necessário no banco e com segurança.

Caso a sua conexão esteja em SSL ou HTTPS, melhor ainda.

Referência: 1.1

Note que o valor da minha conexão na referência 1.1 é toda misturada; letras, números e comandos.

É lógico que fiz um programa que criptografa os dados e descriptografa, isso é importante, pois caso necessite alterar a conexão, basta alterar e criptografar novamente.

Fique atento em relação a isso, a segurança de seus dados no banco de dados é importantíssimo. Ainda mais que, não temos controle sobre quem acesso o servidor que estamos hospedando nosso site ou sistema.

Antes de abrir a conexão com o banco para fazer uma pesquisa eu descriptografo os dados online, ou seja, não mudo o arquivo de configuração; é dinâmico a alteração dos dados.

Para pegar a conexão basta fazer:

System.Configuration.ConfigurationManager.AppSettings[“ConnectionString”]

Referência: 1.2

Bom, espero ter ajudado e despertado você para algo importante.

Qualquer dúvida, favor entrar em contato.

Mauricio Junior

www.mauriciojunior.org

blog.mauriciojunior.org

voltar comente subir

Download Copy

Mauricio Junior Formado pela Faculdade Anhanguera, Especialista pela FGV (Fundação Getúlio Vargas), Pós-Graduação em Docência Superior e cursando Mestrado na UNB Engenharia Elétrica; .
Tenho 29 anos e possuo sete livros publicados pela editora Ciência Moderna. Sou Certificado Microsoft MCP, MCAD e MVP, faço parte da comunidade ASPNETI.COM, ECODE10.COM, onde publico artigos, vídeos, ebooks e livros Publico artigos, vídeos e podcast em outras comunidades. Trabalho como Analista de Sistemas / Desenvolvedor na empresa ATP S/A. Blog: blog.mauriciojunior.org, Site pessoal www.mauriciojunior.org

Comentários:

Comentado por: Erick Belluci Tedeschi - 26/2/2009 0:00:00
Concordo que os desenvolvedores devem tomar cuidado com o arquivo web.config. Só que no exemplo acima (referencia 1.1) você está apenas "codificando" a string de conexão em Base64, e não "criptografando". Isso pode ser considerado como uma falsa sensação de segurança. Talvez seja interessante considerar o uso de "Protected Configuration Provider" como recomendado no MSDN.

t+

Comentado por: Mauricio Junior - 26/2/2009 0:00:00
Erick, o que dei a dica foi para atentar como gerar um string de conexão criptografada, ou seja, diferente de ser aberta. Dai em diante, o desenvolvedor pode fazer de acordo com o que achar melhor, foi só uma dica importante aos desenvolvedores desatentos. Valeu!