Encriptar arquivo web.config

Se você está receoso em manter informações criticas no arquivo web.config,então você deve encripta-lo — ou pelo menos as partes que você mais se importa.

Eu gosto de manter minhas informações na seção appSettings do meu arquivo web.config,isso me permite mudar o comportamento
de um web site inteiro apenas mudando alguns valores no arquivo.Eu especialmente gosto de manter strings de conexão no elemento
ConnectionStrings(isso garante que eu mantenha o número de conexões minimo,o que aumenta as performances de pooling).

Meus clientes nem sempre concordam em manter dados no web.config.Pra ser mais especifico meus clientes,ficam receosos em manter
informações sensiveis(como connectionStrings)num arquivo de texto.Eu digo a meus clientes que se  pessoas podem acessar arquivos
de texto dos seus servidores web,então eles tem problemas,que nem mesmo eu posso resolver.

Meus clientes não consideram esse um argumento válido.

E pra ser honesto,eles tem razão.Uma porcentagem significativa,de brechas de segurança são feitas por pessoas dentro das
empresas .Então eu sugeri aos meu cliente encriptar o arquivo web.config.

Encriptando Seções

Esse é o código que eu utilizei para encriptar,uma sessão especifica do web.config.Eu primeiro selecionei uma seção utilizando,
o objeto de configuração da seção de coleções.Nesse caso eu estou selecionando a seção ConnectionString:


System.Configuration.Configuration configFile;
ConfigurationSection configSection;

configFile = System.Web.Configuration.WebConfigurationManager.OpenWebConfiguration(Request.ApplicationPath);
configSection = configFile.Sections[“connectionStrings”];

Esse código presume que você está executando através de uma página do site por isso usei a propriedade ApplicationPath no objeto
Request para recuperar o caminho fisico para a pasta do web.config.

Agora que tenho a seção,vou encripta-la,especificando o sistema de encriptação que quero usar.O último passo é salvar a versão
encriptada de volta no web.config:

configSection.SectionInformation.ProtectSection(“RsaProtectedConfigurationProvider”);
configFile.Save();

O resultado aparece assim no web.config:

<connectionStrings
configProtectionProvider=”DataProtectionConfigurationProvider”>
<EncryptedData>
<CipherData>
<CipherValue>…encrypted data… </CipherValue>
</CipherData>
</EncryptedData>
</connectionStrings>

A boa noticia é que quando você usa a coleção ConnectionString do ConfigurationManager para recuperar uma conexão encriptada,
essa conexão é automaticamente decriptada para você.Esse código funciona tanto se a conexão estiver encriptada ou não.


string conection = System.Web.Configuration.WebConfigurationManager.ConnectionStrings[“minhaConexao”].ConnectionString;

Uma vez que as strings são encriptadas usando a chave privada para o Web server,mesmo que o arquivo seja roubado do site,
não pode ser decriptado em nenhuma máquina,a não ser no web server.Isso significa também que você não pode encriptar a connection
string até que o arquivo tenha sido movido para o servidor.Se você encriptar a connection string no servidor de teste e depois
mover seu site para o servidor de produção,o ASP.NET não poderá decriptar a connection string usando a chave privada do servidor
de produção.

Dependendo da ocasião,você poderá precisar decriptar a seção do web.config apenas pra checar o que o arquivo na verdade contém.
Esse código faz o serviço:

System.Configuration.Configuration configFile;
ConfigurationSection configSection;

configFile = System.Web.Configuration.WebConfigurationManager.OpenWebConfiguration(Request.ApplicationPath);
configSection = configFile1.Sections[“connectionStrings”];

configSection.SectionInformation.UnprotectSection();

configFile.Save();

Encriptação por linha de comando:

Se você preferir não utilizar código,você pode encriptar ou decriptar seções do seu arquivo web.config,usando o aspnet_regiis utility.
Você deve passar ao utilitario o parametro -pe para especificar a seção que deverá ser encriptada junto com o caminho para,
a pasta do arquivo de configuração.Você também deve passar o parametro -prov para especificar o esquema de encriptação:

aspnet_regiis.exe -pef section physical_directory -prov provider

Esse exemplo encripta a seção configurationStrings para um arquivo de configuração em c:\NorthwindCRM folder:

aspnet_regiis.exe -pef configurationStrings c:\NorthwindCRM
-prov “RsaProtectedConfigurationProvider”

Você também pode usar o aspnet_regiis utility para decriptar uma seção usando parametro -pdf ao invés de -pef.
Ou você também poderia se  certificar que ninguém poderia roubar arquivos de texto do seu web server.

Anúncios

JavaScript para desenvolvedores ASP.NET

Sofri um choque de culturas ao me adptar para trabalhar com JavaScript,iniciando pelo fato de não ser uma linguagem orientada-a-objetos

Eu nunca vi com “bons olhos” a linguagem JavaScript.Sempre me pareceu que apesar de qualquer beneficío que a linguagem
pudesse
trazer,a incapacidade do JavaScript de especificar um tipo de dado para uma variavel mantinha a linguagem afastada de ser
uma “real” linguagem” de programação – pelo menos quando se trata de negócios.

Entretanto,com o passar do tempo eu fui utilizando e me aprofundando mais no estilo de programação AJAX,e me peguei começando
a desenvolver um certo respeito pela linguagem.

Parte do motivo pelo qual eu não gostava de JavaScript era de certa forma falta de conhecimento sobre a linguagem meu.
Desde que comecei a programar,eu trabalhei ou com linguagem orientada-a-objetos.
Eu me aventurei por varias linguagens,mas sempre relacionadas com orientção-a-objetos.

O que mudou um pouco minha visão sobre JavaScript,foi um livro sobre JavaScript de Douglas Crackford chamado JavaScript:The
Good Parts
.Os créditos de Crackford para escrever um livro sobre JavaScript são excelentes,entre outras qualificações,ele
é responsável,pelo formato JSON que é o responsável por transmitir dados estruturados,entre cliente e servidor
em aplicações AJAX.

O livro tem algumas revisões negativas no Amazon.com,que dizem que o livro é curto e definitivamente não ensina vocÊ
a como programar em JavaScript.Ao invés disso,o livro foca em trazer conceitos essenciais da linguagem ao leitor,conceito
esse que eu havia ignorado.

Então essa “clareada” dada por programadores “reais” JavaScript,é a base para este post:para descrever,em termos que fazem
sentido para programadores aSP.NET, os conceitos fundamentais de JavaScript,e como eles são diferentes do conceitos de linguagens
OOP que estamos acostumados.

objetos vs protótipos

Diferentemente de linguagens do lado-servidor que eu escrevia códigos,JavaScript não é orientado a objetos.
Ao invés disso,é organizado em protótipos.Em JavaScript vocÊ pode definir estrutura de dados,e depois ou usa-las ou copia-las.
A habilidade de copiar uma estrutura,para criar uma nova, siginifica que qualquer estrutura pode ser um protótipo para
estruturas subsequentes.Entretanto,diferentemente de uma classe na programação orientada a objetos,onde a definição da estrutura
é inviolável,protótipos e suas cópias podem ser modificados ou extendidos a qualquer momento.

Esse código por exemplo,define uma estrutura de dados que contém duas variaveis:uma chamada id(inicializada com uma string
de tamanho zero)e uma chamada dataOrdered (inicializada com um objeto de Data).Essa estrutura de dados pode ser referenciada
através da variavel salesOrder.

var salesOrder = {
id: “”,
dateOrdered: new Date()
};

Eu posso começar a utilizar esta estrutura imediatamente.Esse código,por exemplo,atribui a propriedade id para um valor string.
(E a boa noticia!A propriedade id irá aparecer no IntelliSense da variavel saleOrder).

salesOrder.id = “A1230”;

Entretanto,eu também posso criar cópias desta estrutura tratando-a como um protótipo.Para copiar a estrutura,eu criei uma
função simples,atribui a propriedade prototype da função para minha estrutura de dados original,depois usei a palavra-chave
new do JavaScript para criar uma nova estrutura a partir daquela estrutura.Esse código cria uma nova cópia da minha estrutura
e referencia ela na variavel através da variavel chamada backOrder.

var SalesOrderGenerator = function(){};
SalesOrderGenerator.prototype = salesOrder;
var backOrder = new SalesOrderGenerator;

Eu posso agora usar essa nova cópia da estrutura de dados:

backOrder.id = “B4567”;

Se esse processo não fosse diferente o bastante,JavaScript permite a você adicionar dinamicamente,um novo elemento para sua
nova cópia simplesmente atribuindo o elemento a um valor.Esse exemplo adiciona um elemento outOfStock para a versão da estrutura
backOrder:

backOrder.outOfStock = true;

Tudo isso,com certeza,é obvio para programadores com experiência em JavaScript.Mas para membros da comunidade ASP.NET que estão
migrando, de código do lado-servidor para código do lado-cliente,existe com certeza um choque de culturas em jogo.

Não ajuda muito saber que uma palavra chave familiar como new aparece em javascript.Uma das melhores regras para seguir,em
design de interfaces de usuário é:”Coisas que fazem a mesma coisa devem parecer iguais,coisas que fazem coisa diferentes,devem
parecer diferentes”.Voltando a palavra chave new,num ambiente diferente essa palavra pode parecer útil,mas na verdade,isso
me encorajou a pensar em javaScript como uma liguagem OOP quando na verdade não é.

Eu ainda estou me ajustando,ah mas se pelo menos eu pudesse declarar uma variável com um simples tipo de dado…