Desenvolvimento - ASP. NET
Dê Segurança às suas Aplicações Web
Escolha a arquitetura de autenticação certa para os seus aplicativos web.
por Yasser ShohoudVocê poderia ser tentado a adiar a segurança e a autenticação de usuário para mais tarde, no ciclo de desenvolvimento, quando estivesse construindo os aplicativos Web. Mas, se você esperar para adicionar autenticação isso pode levar ao redesenho do aplicativo, quando for finalmente o tempo de implementar a segurança. Nesta coluna, eu discutirei as opções de autenticação de usuário, ao construir aplicativos Web que utilizam o Internet Information Server (IIS), e quando devem ser usadas.
Três componentes diferentes compõem a arquitetura de segurança de um aplicativo: integridade de dados, autenticação e autorização ou controle de acesso. Você pode assegurar a integridade dos dados empregando algumas medidas de criptografia para impedir que outros possam interceptar, ler ou alterar os dados trocados entre o browser e o servidor Web. Você pode usar HTTP pelo protocolo Secure Sockets Layer (SSL) para codificar seus dados. A utilização do SSL é bastante direta e não requer nenhuma codificação, mas você tem de obter primeiro um certificado digital de uma autoridade em certificados como a VeriSign. O browser usa este certificado para determinar se o servidor é o que reivindica ser. Em outras palavras, ele usa o certificado para autenticar o servidor. De posse do certificado, você utiliza o Internet Services Manager para fazer a instalação e habilitar o SSL em seu site Web. Você deveria usar o SSL em sites Web que trocam informações sigilosas como números de cartão de crédito. O SSL também é útil com certos mecanismos de autenticação que necessitam de criptografia.
A autenticação se concentra em assegurar aos usuários quem eles reivindicam ser. Comumente utilizadas, as técnicas de autenticação envolvem um prompt solicitando ao usuário um ID e uma senha, enquanto conferem com a lista de userIDs e senhas. Comunicar o userID e a senha (ou informação equivalente) do cliente para o servidor sem comprometer essa informação, é a questão principal sobre autenticação em aplicativos Web.
O IIS5 Oferece Opções de Autenticação
O IIS 5.0 oferece três opções de autenticação além de anonymous (anônimo) (nenhuma autenticação). As duas primeiras, Básica e Sumária, são consideradas padrões da Internet (veja Fontes de Referência). Porém, há alguns problemas com a autenticação Básica. Ela simplesmente envia o userID e a senha ao servidor em texto codificado em Base64. Um hacker não só pode interceptar esta mensagem e obter o userID e a senha, como o servidor obtém a sua senha em texto não codificado. Para tanto, você deve ter certeza de que confia neste servidor. Este é um caso claro de utilização do SSL para complementar o mecanismo de autenticação, oferecendo autenticação de servidor e criptografia necessárias para impedir que outros interceptem a senha do usuário. O Netscape e o Internet Explorer (IE) suportam a autenticação Básica. Isto torna a combinação da autenticação Básica com SSL, uma boa estratégia para aplicativos de Internet, nos quais você não pode requerer um browser específico.
A autenticação Sumária é nova no HTTP 1.1, e só o IE5 o suporta, até o momento em que escrevo este artigo. Isto significa que a autenticação Sumária não é prática para a utilização na Internet, neste momento. A autenticação Sumária é considerada mais segura que a Básica, porque não envia a senha através de conexão. Ao contrário, o cliente prova que sabe a senha transmitindo a soma de verificação (checksum) ao servidor. (Uma soma de verificação - checksum - é um valor calculado usando a informação original: o userID, a senha, o método HTTP, a URL solicitada e uma chave gerada no servidor.) O servidor usa esta informação então para calcular a soma de verificação (checksum) e compará-la à soma de verificação (checksum) enviada pelo cliente. Isso por que o servidor precisa ter acesso à informação original. O servidor calcula uma soma de verificação (checksum) semelhante utilizando os mesmos dados, e então compara àquela enviada pelo cliente.
Para este processo funcionar, o servidor tem de ter acesso à senha do usuário em texto não codificado. A maneira como o IIS5 implementa a autenticação Sumária exige que o servidor Web também aja como seu controlador de domínio, e que você verifique a opção Active Directory que permite armazenar senhas de usuário como texto não codificado. Dadas as exigências e o fato de que a autenticação Básica com criptografia SSL é uma alternativa prática para a maioria dos browsers, você provavelmente não irá utilizar a autenticação Sumária.
A terceira opção, autenticação Integrada Windows, permite ao servidor autenticar o cliente sem ter de solicitar um userID e senha. Ao invés, o servidor usa as atuais credenciais de usuário de login para a autenticação. Embora seja conveniente para o usuário, isso exige o IE, que só o torna prático na intranet. A segurança Integrada pode usar dois protocolos subjacentes para autenticação: NT LAN Manager (NTLM) e Kerberos. Antes do IIS5, o NTLM era a única opção. O servidor e clientes devem estar todos em um domínio que utiliza o Active Directory para usar o Kerberos. Novamente, essa exigência poderia torná-lo não prático na utilização do Kerberos, como protocolo de autenticação subjacente. Seja cuidadoso ao usar o NTLM num aplicativo distribuído: o servidor nunca obtém a senha do usuário; com isso, ele não consegue retransmitir as credenciais do usuário para outro servidor. Isto significa que um Active Server Page (ASP) que está tentando acessar um aplicativo COM+ num servidor remoto terá o acesso negado, a menos que a segurança do aplicativo esteja desligada.
Escolha a Melhor Opção
Você precisa escolher suas opções de segurança de acordo com o tipo de desenvolvimento de aplicativos: Internet ou intranet. Para aplicativos Internet, sua melhor opção é usar a autenticação Básica combinada com SSL. Existem algumas escolhas para os aplicativos intranet. Você deveria usar a segurança integrada ao criar aplicativos intranet, onde os usuários já são membros do mesmo domínio como o servidor Web, porque a segurança integrada é mais conveniente para o usuário. Para os aplicativos intranet, nos quais os aplicativos Web têm acesso aos recursos em outros servidores (por exemplo, um aplictivo COM+), você pode usar a segurança integrada com Kerberos ou a autenticação Básica.
Todos estes mecanismos de autenticação exigem que você defina os usuários do aplicativo como usuários Windows em seu domínio ou no servidor Web, que faz da distribuição de aplicativos para os novos servidores um processo mais complicado. Você pode criar seu próprio esquema de autenticação usando um formulário que solicita userID e contra-senha, compara-os a uma lista de userIDs e senhas conhecidas mantida num arquivo seguro ou banco de dados no servidor. Ao autenticar o usuário, você precisa de uma maneira de reconhecê-lo em cada solicitação subseqüente. Isso pode ser feito gerando um único identificador e armazenando-o como cookie no cliente ou juntando-o à string de consulta para toda solicitação que aquele cliente fizer.
O ASP.NET possui o recurso embutido de autenticação baseada em cookie, que oferece uma estrutura para se fazer exatamente isso. Quando um browser solicita uma página num aplicativo que utiliza autenticação cookie ASP.NET, o servidor verifica o cookie que indica se o usuário foi autenticado. O servidor redireciona o browser à página de login, se não achar o cookie. Ao contrário dos outros métodos de autenticação que eu discuti, essa página de login é uma página ASP.NET que contém um formulário em HTML simples com dois campos de entrada para o userID e senha, como também qualquer outra coisa que você queira colocar (veja Listagem 1). O usuário então digita um userID e uma senha e envia o formulário de volta ao servidor. Utilize sempre SSL em sua página de login prevenir a transmissão das credenciais de usuário como texto não codificado. No servidor, utilize a classe CookieAuthentication.Authenticate para verificar se as credenciais fornecidas são válidas. A classe CookieAuthentication é parte do.NET framework, e você pode usá-la em páginas ASP.NET.
Para autenticar os usuários com facilidade, baseado no fornecimento de userIDs e senhas, você pode utilizar um simples formulário e System.Web.Security.CookieAuthentication. O servidor executa Login_Click, quando o usuário clicar no botão de login. Neste procedimento, você chama CookieAuthentication.Authenticate, passando os usernames e passwords. Se a função retornar True, redireciona os usuários a URL original solicitada. Do contrário, a página de login é enviada de volta com uma mensagem indicando falha no login.
Listagem 1: Formulário para autenticação de usuários
<script language="VB" runat="Server"> public Sub Login_Click(objSender As Object, _ objArgs As EventArgs) If CookieAuthentication.Authenticate _ (txtUser.Value, txtPwd.Value) Then CookieAuthentication.RedirectFromLoginPage _ (txtUser.Value, true) Else lblStatus.InnerText="Invalid user " & _ "name and/or password. Try again" End If End Sub </script> <form method="post" runat="Server"> <TABLE> <TR> <TD>User Name</TD> <TD><INPUT type="text" name="txtUser" id="txtUser" runat="server"/></TD> </TR> <TR> <TD>Password</TD> <TD><INPUT type="password" name="txtPwd" id="txtPwd" runat="server"/></TD> </TR> </TABLE> <INPUT type="submit" OnServerClick="Login_Click" runat="server"/> </form> <SPAN id="lblStatus" runat="server"/>
Use o arquivo de configuração do aplicativo ASP.NET, config.web, para especificar o modo de autenticação, o nome do cookie e a página URL de login:
Listagem 2: Trecho do web.config
<configuration> <security> <authentication mode="Cookie"> <cookie cookie=".ASPXAUTH" loginurl="login.aspx" decryptionkey="autogenerate"> <credentials passwordformat="Clear"> <user name="user01"password="pwd"/> </credentials> </cookie> </authentication> <authorization> <deny users="?"/> </authorization> </security> </configuration>
Você também pode armazenar os userIDs e as senhas no arquivo config.web através do elemento , um recurso que torna extremamente simples o processo de distribuição de userIDs com o seu aplicativo. Alternativamente, um banco de dados ou um serviço de diretório para armazenar userIDs e senhas podem ser utilizados. O config.web também inclui um elemento que lhe permite especificar usuários que possuem acessos concedidos ou negados. Eu não entrarei na questão da autorização (controle de acesso) nesta coluna, exceto para mostrar que, por padrão, todos têm acesso permitido, num aplicativo ASP.NET. A linha nega aos usuários anônimos (não autenticado) acesso ao seu aplicativo; ou seja, o servidor exige que o usuário efetue o login. Quando o servidor verifica as credenciais de usuários, ele gera um ingresso de autenticação codificado com a chave especificada no elemento no arquivo config.web. Especificar decryptionkey = "autogenerate" gera automaticamente uma chave específica do servidor.
Visualização de Informação Rastreada
Ao usar uma página de rastreamento ASP.NET, a minha página default.aspx exibe informações úteis de rastreamento, inclusive os cookies cliente (veja Figura 1). Neste caso, o cookie .ASPXAUTH contém uma mistura do ingresso de autenticação e da chave de criptografia específica. Você mesmo pode implementar as técnicas usadas na autenticação cookie ASP.NET, mas o fato de que as técnicas fazem parte do ASP.NET framework significa que alguém já fez o trabalho por você. A autenticação cookie ASP.NET combinada ao SSL funciona bem nos aplicativos para Internet e intranet e não complica a sua distribuição.
Figura 1: Exiba Cookies Cliente.
Obtenha uma lista de cookies enviados pelo cliente ao usar o rastreador ASP.NET. .ASPXAUTH é a autenticação cookie do cliente, que o servidor utiliza para identificá-lo em cada solicitação.
A autenticação de passaporte, um dos provedores de autenticação ASP.NET, funciona semelhantemente a autenticação de cookie com a principal diferença onde a autenticação acontece. Aqui, o browser é redirecionado ao serviço de login de Passaporte, que é um serviço central de Internet para autenticar os usuários. Assim que o Passaporte autentica o usuário, redireciona o browser de volta ao seu servidor junto com um ingresso de autenticação, que o servidor utiliza para determinar a identidade do usuário. A autenticação de usuário é só o primeiro passo na segurança de aplicativos Web. A seguir, você precisa pensar sobre autorização ou controle de acesso: determinando se o usuário tem acesso ao recurso solicitado. Tente explorar este caminho, agora que você se familiarizou com a autenticação de usuário.
Sobre o Autor
Yasser Shohoud é co-fundador e presidente da DevXpert (www.devxpert.com), uma empresa de desenvolvimento e treinamento em software baseada ao norte de Virgínia, Estados Unidos. Yasser desenvolve e ministra cursos de treinamento e constrói sistemas baseados em XML para os clientes. Ele é autor da XML Magazine e orador freqüente da VBITS e SD.
