java magazine - seguranca no j2ee

7/27/2019 Java Magazine - Seguranca No J2EE

1/18

Notebook: Eng. de Software

Created: 29/12/2010 19:50

URL: http://www.devmedia.com.br/post-10128-Artigo-Java-Magazine-22-Seguranca-no-J2EE.html

Artigo Java Magazine 22 - Segurana no J2EE

Java Live

Segurana no J2EE

Parte 1: Desenvolvimento e deployment no Tomcat

Aprenda a utilizar as facilidades de autenticao e controle de acesso da plataforma J2EE para aplicaes web com o mais popular

container web

Fernando Lozano

Quantas vezes voc j construiu um mdulo de segurana para um sistema ou site web? Muda a linguagem de programao, muda a empresa,

muda o pro jeto, mas h sempre a mesma necessidade: validar senhas de usurios e permisses de acesso.

No universo J2EE no preciso reinventar a roda. A especificao determina como uma aplicao pode definir regras de controle de acesso e

como obter informaes sobre o usurio logado.

Esta srie, em duas partes bastante independentes, demonstra como configurar e utilizar os recu rsos de segurana previstos pelo J2EE para

implementar polticas de autenticao e de controle de acesso, incluindo exemplos prticos de implementao nos servido res livres mais

populares. O Tomcat o foco desta primeira parte e o JBoss, o da parte final. A abordagem ser prtica, pela construo de um exemplo em que

cada usurio pode acessar um conjunto diferente de pginas. O exemplo ser depois modificado para ilustrar outros cenrios freqentemente

requisitados pelos usurios.

Segurana declarativa

O J2EE utiliza uma abordagem declarativapara as configuraes de segurana, baseada no conceito de roles(papis). Uma aplicao define um

ou mais roles e depois quais operaes podem ser realizadas por cada um desses roles. Grosso modo, um role um grupo de usurios. O

conceito de operao depende do contexto: em um container web, consiste no acesso a uma URL; em um container EJB uma operao

representa a invocao de um mtodo remoto.

O cdigo da aplicao no chama nenhum mtodo para validar uma senha, nem para autorizar ou no a realizao de uma operao. Fazer isso

seria uma abordagemprocedural. Pode-se fazer uma analogia com comandos select do SQL e comandos seek do dBase e Clipper. No SQL, o

select descreve quais dados so desejados, mas no quais ndices acessar e arquivos de dados abrir; no dBase/Clipper arquivos e ndices so

abertos manualmente, e acessos a v rias tabelas se tornam loops aninhados. Comandos select so portanto uma abordagem declarativa;

comandos seek, uma abordagem procedural.

claro que nem todas as situaes podem ser tratadas de forma declarativa. Po r isso as APIs de Serv lets e de EJB definem mtodos para

descobrir quem o usurio corrente (ou se no foi ainda feito o login) e se este usurio possui ou no um role especfico. Com esses mtodos,

possvel tratar no cdigo da aplicao qualquer situao que no po ssa ser tratada pelos descritores. Vrios exemplos sero apresentados ao

longo do artigo.

Roles e operaes so parte da estrutura da aplicao, por isso so definidas pelo desenvolvedor e especificadas no descritor (com URIs

mapeadas para servlets) ou na interface dos EJBs. Por outro lado, a especificao J2EE no define como as senhas so validadas, nem como um

usurio associado a um role. Essas questes so responsabilidade do administrador do servidor de aplicaes, e cada produto tem total

liberdade de implement-las da forma que for julgado mais conveniente.

Assim sendo, qualquer aplicao que utilize os recursos padro do J2EE para autenticao e controle de acesso ir exigir um deployment

(instalao) customizado para o servidor de aplicaes adotado. Alguns desenvolvedores vem isto como desvantagem, preferindo implementar

seus prprios esquemas de autenticao e c ontrole de acesso visando garantir que suas aplicaes possam ser instaladas de fo rma fcil e

inalterada em qualquer servidor do mercado. O problema que acabam reinventando a roda e na maioria das vezes ficando com a segurana

deficiente, por falta de conhecimento especializado no assunto.

Controle de acesso em aplicaes web

A Listagem 1 demonstra a sintaxe para a declarao de roles e regras de controle de acesso para uma aplicao web de exemplo, que estdisponvel para download no site da Java Magazine. Note que so definidos dois roles usuario e administrador e que a pgina inicial da

aplicao tem acesso pblico , pois sua URL (/index.jsp) no se enquadra nos padresurl-patterndefinidos para nenhum dos elementosweb-resource-collectionpresentes no descritor.

Se no for definida uma regra de controle de acesso para uma operao, esta operao poder ser realizada livremente por usurios no-

autenticados. Caso se deseje que todas as pginas de uma aplicao web estejam sob c ontro le de acesso, deve-se inserir todas elas em um mesmo

diretrio, e definir um padro como nome_da_pasta/*, correspondendo a todas as pginas da aplicao. No se deve definir simplesmente /*,

padro que corr esponde a todas as pginas da aplicao. Isso porque caso sua aplicao utilize uma pgina de login customizada, esta pgina

deve estar acessvel para usurios ann imos, assim como a pgina de erro associada.

Observe que, da forma como as regras de controle de acesso foram definidas, os conjuntos de pginas acessveis para usurios e administradores

so completamente separados. C aso se deseje que o administrador tambm possa acessar as pginas dos usurios, h trs alternativas:


2/18

Ac rescentar mais umrole-namecom o valor administrador dentro doauth-constraintdo elementoweb-resource-collectionPginas do Usurio

Ac rescentar mais umurl-patterncom o v alor /usuarios/* dentro do auth-constraintdoweb-resource-collectionPginas doAdministrador

Dar aos usurios que recebem o ro le administrador tambm a role usuario

Agora veja na Figura 1 a estrutura do pacote war da aplicao de exemplo. O contedo das pginas livre, pois estamos interessados apenas

em verificar quais usurios conseguem acessar quais pginas. A pgina index.jspcontm links para as pginas de ndice em cada subdiretrio,funcionando como um menu de acesso aplicao.

Por simplicidade o exemplo consiste apenas de pginas JSP , mas as mesmas regras se aplicam a servlets, pois cada serv let mapeado para uma ou

mais URIs no descritor web.xml. A restrio de acesso baseada em URIs tambm se aplica a pginas estticas, criando uma estrutura simples e

uniforme para controlar o acesso a todas as pginas da aplicao.

por isso que alguns servidores de aplicaes, como o Tomcat, desabilitam em suas configuraes padro o acesso a servlets pelo nome da

classe (com a URI /serv lets/pacote.nomeDaClasse), apesar desse tipo de acesso ser prev isto pela especificao de Serv lets. O acesso pelo nome

de classe permitiria que um servlet sujeito a con trole de acesso pela sua URI (mapeada explicitamente no web.xml) fosse acessado por usurios

no-autor izados, pois seria utilizada uma URI diferente.

Listagem 1. Descritor web.xmlpara a aplicao de exemplo

Paginas do Usuario

/usuarios/*

usuario

Paginas do Administrador

/admin/*

administrador

usuario

administrador


3/18

Figura 1. Estrutura de pginas da aplicao de exemplo

Autenticao em aplicaes web

Tendo definido as regras de controle de acesso, devem ser estabelecidas as regras de autenticao. A especificao de Servlets define quatro

formas possveis de se configurar o login, trs delas gerenciadas pelo servidor web1 e definidas pelo protocolo HTTP, e uma gerenciada pelo

prprio container web. So elas:

1. HTTP Basic Authentication2. HTTP Digest Authentication3. HTTPS Client Authentication4. Form Based Authentication

Nas duas primeiras formas de autenticao o navegador exibe uma janela de login, sendo fornecidas as credenciais do usurio por meio de

cabealhos HTTP. Na terceira, deve ser instalado um certificado digital no navegador do usurio, semelhante ao instalado em um servidor web

para uso de HTTPS; a simples presena deste certificado autentica o usurio. Na quarta forma de autenticao, uma pgina definida pela

aplicao pede o login e senha do usurio

Os desenvolvedores em geral preferem a quarta forma de autenticao (Form Based), pois enquanto que nas duas primeiras ele no tem controle

sobre a aparncia da tela de login, na terceira opo necessrio configurar as mquinas dos usurios uma a uma, o que no vivel exceto em

pequenas in tranets.

Vamos apresentar neste momento a autenticao Basic; depois passaremos para a autenticao Form. Os seguintes elementos devem ser

acrescentados ao descritor web.xmlpara configurar esta forma de autenticao:

BASIC

Exem plo de Segurana J2EE

O elementorealm-nameidentifica o domnio (ou zona) de segurana para o navegador web. Assim o navegador sabe se pode ser utilizadauma senha j informada antes pelo usurio, ou se deve ser requisitada uma nov a senha. O texto fornecido neste elemento ser apresentado pelo

navegador em sua janela de login, como mostra a Figura 2.

Sob o ponto de vista do desenvolvedor, a aplicao de exemplo estaria pronta para ser executada. Mas o administrador do servidor ainda tem

que configurar um container web para autenticar usurios e reconhecer os roles definidos pela aplicao.

Figura 2. Janela de autenticao do Mozilla ao acessar o link Pginas dos usurios da aplicaode exemplo

Validao de senhas no Tomcat

Deve ser configurado um realm2 para que o Tomcat seja capaz de validar senhas e associar roles a usurios. Diferentes tipos de realms obtm as

informaes sobre senhas e roles de diferentes fontes de dados, que podem ser arquivos XML, bancos de dados relacionais (via JDBC) ou

diretrios LDAP (via JNDI). Voc pode, claro, estender o Tomcat com novos realms produtos de terceiros utilizam esta capacidade para

permitir a integrao com os bancos de dados de usurios do Unix, Windows e Netware.


4/18

Um realm pode ser definido em qualquer nvel da hierarquia de elementos do arquivo server.xmldo Tomcat, e se aplica a todas as aplicaes

(contextos) dentro daquele nvel. Assim, pode-se ter desde um nico banco de dados de usurios para todos os domnios virtuais hospedados

pelo mesmo servidor, at bancos de dados isolados para cada contexto de cada domnio; ou qualquer configurao entre esses dois extremos.

Veja a seguir as alteraes feitas no arquivo server.xmlpara validar senhas utilizando um arquivo chamado users.xml(mostrado na Listagem 2):

Assumindo uma instalao padro do Tomcat 5, insira este elemento imediatamente antes dee comente qualqueroutro elementopresente no server.xml.Os ro les admin e manager definidos no users.xml, assim como o usurio admin, esto presentes para que seja possvel executar as aplicaes

padro do Tomcat, Manager e Admin. Leitores interessados em mais detalhes sobre as aplicaes administrativas do prprio Tomcat podem

consultar o artigo desta coluna na Edio 19.

J podemos copiar o arquivo war da aplicao de exemplo para a pasta webappsdo To mcat e acessar a URL http://127.0.0.1:8080/jm-

seguranca-j2ee. Ao serem clicados os links Pginas dos usurios ou Pginas dos administradores o navegador ir pedir por um login e senha,

exibindo uma janela semelhante Figura 3.

Para os usurios/roles definidos como exemplo, caso seja fornecido o login fernando com senha java, apenas o link de usurios ser aceito;

com o login lozano senha tomcat, apenas o segundo poder ser acessado. Se um usurio tentar acessar uma pgina que no esteja

autorizado a acessar, ser exibida uma pgina de erro gerada pelo container (veja a Figura 4 ).

Listagem 2. Arquivo users.xml, que fornece logins, senhas e roles para o realm configurado

Figura 3. Pgina inicial e pgina do usurio da aplicao de exemplo


5/18

Figura 4. Pgina de erro quando o usurio no tem permisso de ver a pgina

Como fazer logoff?

Retornando Figura 3, note que no existe um link de logout. Isto proposital, visto que o protocolo HTTP no define esta operao. A

nica forma de se deslogar o usurio, segundo o padro HTTP, fechar todas as janelas do navegador.

Este problema decorre de o protocolo HTTP ser stateless(sem memria/estado). Pelo protocolo, o navegador poderia pedir a digitao da

senha novamente para cada pgina, mas por comodidade pede apenas a primeira vez que encontra um novo realm. A senha digitada

guardada em memria no navegador e reenviada sempre que o servidor web indicar uma pgina que necessita de autenticao. O servidor

sempre ir indicar que uma pgina restrita necessita de autenticao, mesmo que o usurio tenha acabado de navegar por outra pgina do

mesmo realm. Em suma, no existe no protocolo HTTP o conceito de login do usurio.Na verdade, mesmo o conceito de sesso HTTP que utilizamos na programao de servlets e pginas JSP inexistente no protocolo HTTP. A

sesso simulada pelo container web, sem que o servidor web tenha conhecimento disto, portanto no adianta invalidar a sesso para forar um

logou t, como feito na autenticao baseada em formulrios, que veremos mais adiante.

O leitor poder encontrar na internet exemplos de como fazer logout ou mudar o usurio em aplicaes web, utilizando as formas de

autenticao previstas pelo protocolo HTTP, mas qualquer uma delas ir funcionar apenas com uma combinao especfica de navegador e

servidor web. Ou ento ir exigir o controle efetivo da autenticao por meio de cookies, variveis de sesso ou outro mecanismo que dependa

de cdigo de aplicao. Melhor ento utilizar a autenticao Form Based, entregando este trabalho ao container.

Utilizando senhas criptografadas

O arquivo users.xml, que fornece as senhas e ro les para cada usurios no ltimo exemplo, contm as senhas em texto simples, sem criptografia.

No recomendado, por questes de segurana e privacidade dos usurios, que senhas estejam armazenadas em um lugar onde um invasor ou

mesmo o prprio administrador de sistema possa recuper-las.

Felizmente todas as opes de realm fornecidas com o Tomcat possuem o atributodigester, que permite especificar um dos algoritmos decriptog rafia de mo-nica pela classejava.security.MessageDigestdo JCE para criptografar a senha fornecida pelo usurio. A senhafornecida pelo usurio criptografada pelo container e comparada com a senha armazenada em forma criptografada pelo realm.

Modifique ento o arquiv o server.xmlconforme o trecho a seguir:

Agora necessrio gerar as senhas criptografadas e armazen-las no users.xml. No seria difcil escrever uma aplicao u tilizando as classes do

JCE para ler uma senha do teclado e fornecer sua forma criptografada (veja o artigo de Bruno Souza nesta edio), mas o Tomcat j fornece tal

utilitrio pronto para uso. necessrio acrescentar os pacotes bin/jmx.jar, bin/commong-loggin-api.jare server/lib/catalina.jarao classpath e

ento executar a classeorg.apache.catalina.realm.RealmBase. A seguir, um exemplo de uso deste utilitrio para criptografar a senhaatribuda ao usurio fernando:

> java org.apache.catalina.realm.RealmBase -a MD5 java

java:93f725a07423fe1c889f448b33d21f46

A primeira linha a linha de comando ; na opo-a indicado o algoritmo a ser utilizado (no caso, MD5); o argumento java a senha. Asada do pr ograma uma linha de texto, fornecendo a senha orig inal e a senha criptografada separados por um sinal de dois-pontos.

A senha deve ser ento copiada para o arquivo users.xml, que fica semelhante Listagem 3. Reinicie o Tomcat e verifique se as senhas ainda

so reconhecidas.

impor tante ressaltar aqui que foram criptografadas apenas as senhas armazenadas no arquivo users.xml(ou no banco de dados, ou diretrio

LDAP, se forem adotadas outras opes de realms do Tomcat). A senha ainda est sujeita a captura em trnsito, po is no mecanismo HTTP Basic

ela transmitida em texto puro (no-criptografado) para o servidor web. Veja o quadro At onde a criptografia garante segurana? para uma

discusso sobre como formas de evitar esta vulnerabilidade.

Listagem 3. Modificaes no arquivo users.xmlpara utilizar senhas criptografadas


6/18

set CLASSPATH=%CLASSPATH%;%$TOMCAT_HOME%\common\lib\hsqldb.jar

2. Inicie o servidor, onde/bd/users o nome do banco de dados, que ser criado automaticamente:java org.hsqldb .Server -database /db/u sers

3. Execute os scripts de cr iao das tabelas e dos usurios/roles de teste (digitando os comando s em uma linha):> java org.hsqldb.util.ScriptTool -ur l jdbc:hsqldb:hsql:

-database //127.0.0.1 -script tabelas.sql

> java org.hsqldb.util.ScriptTool -ur l jdbc:hsqldb:hsql:

-database //127.0.0.1 -script usuarios.sql

4. Verifique se as tabelas esto mesmo criadas e preenchidas, utilizando o Database Manager do HSQ LDB (para isso, execute um comandocomo select * from users):

> java org.hsqldb.util.DatabaseManager -url jdbc:hsqldb:hsql://127.0.0.1

Com o banco de dados de usurios e roles preparado, modifique a definio do realm conforme a Listagem 6. Lembre-se de remover (ou

comentar) a definio do realm criada anteriormente.

Reinicie o Tomcat e teste o acesso s pginas da aplicao de exemplo. Tudo deve funcionar como antes, mas utilizando o banco de dados em

vez do arquivo users.xml. Experimente tambm alterar a senha do usurio no banco de dados, ou os seus roles associados; verifique que a

mudana reconhecida imediatamente.

Observe ainda que a mudana na autenticao, de um arquivo XML para um banco relacional, no exigiu modificaes na aplicao nem em seudescritor web.xml. As alteraes foram realizadas apenas no server.xmldo Tomcat.

Listagem 4. Tabelas de usurios e roles para o Tomcat (tabelas.sql)

create table users (

login varchar(15) not null primary key,

passwd varchar(32) not null

);

create table roles (

login v archar(15) not nu ll,

role varchar(15) not null,


7/18

primary key (login, role)

);

Listagem 5.Inserindo no banco os registros correspondentes aos usurios admin, fernando e

lozano (usuarios.sql)

insert into users v alues ('admin', '21232f297a57a5a743894a0e4a801fc3');

insert into roles values ('admin', 'admin');insert into ro les values ('admin', 'manager');

insert into users values ('fernando', '93f725a07423fe1c889f448b33d21f46b');

insert into roles values ('fernando', 'usuario');

insert into users values ('lozano', '1b359d8753858b55befa0441067aaed3');

insert into roles values ('lozano', 'administrador');

Listagem 6. Modificaes no server.xmlpara utilizar o JDBCRealm e o banco de dados HSQLDB

Pginas de erro customizadas

A pgina de erro de acesso negado pode ser customizada da mesma forma, como qualquer outra pgina de erro , utilizando os recursos

previstos na especificao do HTTP.

Um exemplo de pgina de erro customizada est na Listagem 7. Ela permite ao usurio ser informado do erro e retornar ao menu do sistema.

Note o uso do mtodogetContextPath()para gerar a URL de retorno ao ndice da aplicao. Links relativos costumam no funcionar empginas de erro, pois a URL vista pelo navegador no a da pgina de erros em si, mas a da que provocou o erro. Ou seja, voc nunca sabe

qual o diretrio corrente de uma pgina de erro para construir links relativos corretos.

Para ativar a pgina de erro customizada, acrescente ao descritor web.xmlos seguintes elementos:

403/erro403.jsp

Depois recarregue a aplicao por meio do Manager do Tomcat. Tente novamente acessar uma pgina a qual o perfil do usurio no fornece

acesso (por exemplo, pginas administrativas com o usurio fernando). O resultado ser como na Figura 5.

Os cdigos de erro so os cdigos padronizados do protocolo HTTP; 403 corresponde ao erro de acesso negado. Consulte a especificao do

protocolo HTTP para os outros cdigos de erro definidos (veja links).

Note que a pgina de erro foi colocada no diretrio raiz do contexto, para que no seja inclusa em um dosweb-resource-collections queexigem autenticao. Caso contrrio, a prpria pgina de erro poderia gerar um erro de login invlido ou de acesso negado.

Listagem 7. Pgina de erro customizada para erros de acesso negado (erro403.jsp)

Demo de Segurana J2EE

Voc no tem acesso pgina:

Voltar...


8/18

Figura 5. Pgina de erros customizada, conforme vista pelo usurio

Pginas de login customizadas

O mecanismo de autenticao HTTP Basic acaba sendo pouco u tilizado em sistemas de informao e portais devido s suas limitaes. Mas til

quando se quer que uma aplicao web seja acessada por outra aplicao em vez de por um usurio humano. o caso, por exemplo, da

aplicao Manager do Tomcat. Espera-se que suas pginas de dep loyment e recarga de aplicaes web sejam acessadas diretamente por bu ildfiles

An t e outros tipos de scripts, para automatizar a instalao e atualizao de aplicaes.

O mecanismo preferido pelo desenvolvedor Java, para uso geral, a Form Based Authentication, autenticao baseada em formulrios. O

descritor web.xmlda aplicao especifica uma pgina de login que ser exibida automaticamente pelo container web, sempre que o usurio tentar

navegar para uma pgina que exija autenticao. O usurio ento fornece o login e senha, que so validados pelo container; e o navegador

redirecionado para a pgina requisitada originalmente. As informaes do usurio corrente so armazenadas em atributos reservados3 na sesso

HTTP, de modo que invalidar a sesso causa o logoff do usurio.

importante notar que a pgina de login nunca deve ser chamada diretamente pela aplicao. Deve-se deixar que o container o faa. Caso seja

desejada uma pgina de login explcita, uma possibilidade criar uma pgina (ou servlet) que apenas redireciona o usurio de volta para a

pgina pr incipal da aplicao, mas esta pgina est contida em umweb-resource-collectionque exige autenticao.A Listagem 8 mostra as alteraes no web.xmlpara configurar a autenticao baseada em formulrios para a aplicao. Ela substitui, claro, a

configurao mostrada para a autenticao Basic. Devem ser fornecidas uma pgina de login e uma pgina de erro de login.

A pgina de erro no em nada diferente de uma pgina comum (ao contrrio das pginas de erro que so associadas a excees Java ou erros

HTTP no web.xml). Mas a pgina de login deve seguir algumas regras:

1. Os campos que recebem a digitao do login e da senha devem ser chamados, respectivamente j_username e j_password2. Oactiondo formulrio deve ser a URL j_security_check

A URL j_security_check tambm no deve ser invocada explicitamente pela aplicao.

Temos na Listagem 9 um exemplo de pgina de login, e na Listagem 10 uma pgina de erro. As duas so apresentadas na Figura 6.

Nos fontes disponveis para download temos a aplicao jm-seguranca-j2ee-form, contendo o descritor modificado e as pginas de login e de

erro. Assim o leitor pode experimentar tanto com a autenticao gerenciada pelo servidor web quanto com a gerenciada pelo container web.

Observe que a pgina de login salva a sua URL no atributo de sesso pagina. Isto serve para que a pgina de erro de login possa gerar o link

de Tentar novamente, pois o container no passa nenhuma informao sobre o recurso que se tentou acessar, nem fornece a opo de tentar

novamente caso o login ou a senha no sejam reconhecidos.

Listagem 8. Modificaes no web.xmlpara autenticao baseada em formulrios

FORM

/login.jsp

/loginInvalido.jsp

Listagem 9. Pgina de login do exemplo (login.jsp)

Demo de Segurana J2EE


9/18

Esta pgina s pode ser acessada por usurios autenticados

Login:

Senha:

Listagem 10. Pgina de erro de login (loginInvalido.jsp)

Demo de Segurana J2EE (Form)

Login ou senha incorretos.

Tentar no vamente...

Voltar...

Figura 6. Pginas de autenticao e de erro de login

Agora sim, fazendo o logoff

Como as informaes sobre o usurio autenticado so salvas pelo container na sesso, basta invalid-la para fazer o logoff. A Listagem 11

ilustra como poderia ser uma pgina de logoff, e a pgina principal do segundo exemplo (disponvel para download) inclui um link que a chama.

Como na configurao padro do Tomcat (e de qualquer outro container web) sesses HTTP expiram aps alguns minutos de inatividade (o

tempo configurvel no descritor web.xmlda aplicao), um usurio que, por exemplo, se ausente do seu computador sem sair da aplicao

ser deslogado automaticamente.

Alm disso, o cookie utilizado para manter a sesso HTTP no lado do navegador criado de modo a no ser preservado entre uma invocao e


10/18

outra do navegador. Portanto aps fechar o navegador ser necessrio fazer um novo login. Entretanto, o usurio permanece autenticado,

tanto no mtodo Basic quando no mtodo Form, se ele sair da aplicao para visitar outro site. Dessa forma ainda h margem para um

usurio espertinho utilizar o login de outro usurio sem que ele o perceba. Nada substitui o treinamento dos usurios quando o assunto

segurana.

Exceto pela forma de se fazer o logo ff, tudo o que foi v isto antes sobre autenticao HTTP Basic se aplica igualmente autenticao baseada em

formulrios. A configurao do container web n o afetada pelo mecanismo de autenticao da aplicao, assim as mesmas definies de realms

do Tomcat e o uso de criptografia podem ser utilizados com os dois exemplos.

Listagem 11. Pgina de logoff da aplicao (logoff.jsp)

Demo de Segurana J2EE (Form)

Sesso encerr ada

Voltar...

Single Sign-on

Na configurao padro do Tomcat, cada aplicao web (ou contexto) mantm suas informaes de autenticao em separado, mesmo que

todos o s contextos utilizem um mesmo realm. Isso significa que se existirem vrias aplicaes web hospedadas no mesmo servidor o usurioprecisar fornecer novamente o login e senha a cada vez que mudar de aplicao.

Tendo em vista que a maioria das empresas organiza suas intranets como um conjun to de aplicaes web independentes, mas fazendo parte do

mesmo por tal, o usurio espera ter que d igitar seu log in e senha uma n ica vez, na pr imeira pgina restrita que for acessada (ou na primeira

pgina visitada na intranet). Para obter este efeito no Tomcat, deve ser configurada no nvel do host a "vlvula" (valve)4 de Single Sign-on

(login nico ). O seguinte exemplo ilustra a sintaxe deste elemento:

Porm tome cu idado com a mistura de aplicaes que utilizam autenticao Basic e aplicaes que utilizam autenticao Fo rm, pois as

credenciais do usurio sero removidas do container, mas no do navegador web.

Voc pode verificar o efeito nos dois exemplos construdos neste artigo. P rimeiro modifique o server.xmle reinicie o Tomcat; depois entre na

aplicaojm-seguranca-j2ee-form(o segundo exemplo) e fornea as credenciais do usurio fernando. Entre na aplicaojm-seguranca-j2ee

(primeiro exemplo) e depois na rea dos usurios. Veja que no ser pedida nenhuma informao de autenticao.

Agora retorne para a aplicaojm-seguranca-j2ee-form. Faa o logoff e entre na pgina de usurios apenas para confirmar que a aplicao pede

novamente o login a senha; mas em vez de clicar no boto "Ok" da pgina de login, retorne para o primeiro exemplo. Observe que ele no ir

pedir a senha para acessar as reas restritas.

A recomendao por tanto utilizar apenas aplicaes com autenticao baseada em formulrios no mesmo host do Tomcat. Isto evita o risco de

um usurio achar que fez o logoff, enquanto que para o navegador o login ainda esteja vlido.

Quem o usurio corrente?

A A PI de Serv lets fornece trs mtodo s, caso a aplicao necessite tomar alguma deciso baseada em qual usurio esteja logado, todos da classe

HttpServletRequest:

? getRemoteUser()retorna o nome do usurio fornecido na requisio HTTP, de modo que ele s relevante se for utilizado algummecanismo de autenticao gerenciado pelo serv idor web. C aso seja utilizada autenticao baseada em formulrios, este mtodo sempre

retornarnull.? getUserPrincipal()retorna um objeto da classejava.security.Pr incipal, que encapsula o usurio autenticado pelo container. Estemtodo funciona com qualquer mecanismo de autenticao.? isUserInRole()informa se o usurio correntemente autenticado est ou no associado ao role cujo nome passado como argumento.

Veja que no so fornecidos mtodos para listar os usurios existentes, nem para listar os roles aos quais o usurio est associado. Mesmo assim,

os do is ltimos so suficientes para qualquer situao que se apresentar. OgetRemoteUser()deve ser evitado, j que ele no se aplica autenticao baseada em formulrios, mas pode ser substitudo em qualquer situao pelo segundo mtodo ,getUserPrincipal().Pgina de login obrigatria

A aplicaojm-seguranca-j2ee-proc, tambm inclusa nos fontes para download, exemplifica algumas caractersticas desejadas por muitos

desenvo lvedores para suas aplicaes. Ela tem uma pgina inicial apresentada na Listagem 12, que comea fornecendo um nico link: Entrar

no sistema. Clicar neste link provoca a autenticao do usurio, fazendo a aplicao retornar para a mesma pgina inicial, mas agora com links

para as operaes que ele pode realizar no sistema.

Lgica condicional como scriptlets em pginas JSP tendem rapidamente a ficar de difcil leitura, como naListagem 12. Considere nestes casos


11/18

utilizar a JSTL.

A pgina autentica.jsp simples; ela apenas redireciona o navegador de volta para a pgina de ndice:

Para que a aplicao funcione como desejado, deve ser acrescentada uma nova regra de controle de acesso ao descritor web.xml, apresentada

na Listagem 13. A Figura 7 ilustra como o login nesta aplicao funciona sob o ponto de vista do usurio.

O nome * para um role indica que qualquer role aceito, ou seja, que as URLs relacionadas podem ser acessadas por qualquer usurio

autenticado. No definir uma regra de controle de acesso significa que usurios annimos podem acessar a pgina sem fornecer nenhuma senha.

As outras regras de controle de acesso devem ser mantidas; caso contrrio ser fcil bur lar a segurana da aplicao.

Qual a vantagem de se utilizar a segurana declarativa neste caso, onde o usurio obrigado a passar por uma pgina de login antes de poder

ter acesso a qualquer outra pgina da aplicao? A principal vantagem vem do fato que o usurio no pode pular a pgina de login

fornecendo d iretamente uma URL. Se no fosse utilizada a segurana declarativa do J2EE, seria necessrio inserir em cada pgina um teste para

verificar se o usurio j fez o login, ou configurar um filtro (java.servlet.Filter) para fazer essa verificao em todas as pginas.

Outra vantagem que o usurio pode salvar nos "favoritos" do seu navegador a URL para uma pgina qualquer, e o container automaticamente

exibir a pgina de login, poupando ao usurio alguns cliques adicionais at chegar a pgina desejada.

Listagem 12. Pgina de ndice (index.jsp) do terceiro exemplo, jm-seguranca-j2ee-proc,ilustrando o uso dos mtodos para segurana procedural na API de Servlets

Demo de Segurana J2EE (Procedural)

Entrar no Sistema

Bem-vindo, usurio

Pginas dos usurios

Pginas dos administradores

Logoff

Listagem 13. Modificaes no descritor web.xmlpara que um acesso a pgina autentica.jspprovoque a exibio da pgina de login

Fora a Atenticao


12/18

/autentica.jsp

*

Figura 7. Usurio se logando na aplicao jm-seguranca-j2ee-proc, exemplificando um usurioadministrador e um no-administrador

Formulrio de login na pgina inicial

Outra situao corriqueira em aplicaes web o caso de pginas que exibem informaes para usurios annimos, deixando em um canto da

tela um formulrio para login, depois do qual so exibidas informaes adicionais. J vimos que a pgina de login deve ser mostrada pelo

container; assim nossa pgina inicial seria incompatvel com a segurana declarativa do J2EE. Ou no?

Um pouco de criatividade e um pequeno trecho de cdigo JavaScript resolvem a aparente incompatibilidade. Primeiro fazemos com que o


13/18

formulrio na pgina inicial (Listagem 14) utilize como seuactionuma pgina restrita (no caso autentica.jsp, a mesma do exemplo anterior). O scampos do formulrio de login estaro disponveis para a pgina de login do container (pois ela parte da mesma requisio HTTP). Esta pgina

contm cdigo JavaScript no eventoonLoaddo corpo da pgina (body) para provocar a submisso imediata do formulrio (Listagem 15).Note que os campos obrigatrios foram definidos como campos escondidos (hidden).

A Figura 8 ilustra a navegao de um usurio pelo quarto exemplo,jm-seguranca-j2ee-box. Observe a caixa na parte direita das pginas, que

pode ou exibir um formulrio de login o u o nome do usurio autenticado.

Listagem 14. Pgina incial (index.jsp) do quarto exemplo, jm-seguranca-j2ee-box

Demo de Segurana J2EE (Box)

Aqui entrariam as informaes pblicas da aplicao.

Pginas dos usurios

Pginas dos administradores

Login:

Senha:

Usurio:

Logoff

Listagem 15. Pgina de login (login.jsp) do quarto exemplo


14/18

Demo de Segurana J2EE (Box)

Au tenticando usurio...

Figura 8. Login no quarto exemplo, jm-seguranca-j2ee-box

Segurana e r egras de negcio

Daqui em diante, outras necessidades relativas segurana de uma aplicao web em Java (falando em autenticao e controle de acesso) so na

verdade relacionadas com as regras de negcios da aplicao por exemplo, se um usurio pode ou no ver os registros criados por outros

usurios no banco de dados. Seria questo de incluir na pesquisa uma condio sobre o login do usurio (obtido via getUserPrincipal()).Outro exemplo seria quando um registro pode ser modificado apenas quando o seu status em aberto, mas no pode ser modificado nem

removido depois de mudar para o estado fechado.

Nenhum mecanismo automatizado ser capaz de decidir que usurio tem acesso a quais dados, ou qual operao pode ser realizada sobre um

registro em particular, mas controlar o acesso s pginas da aplicao j mais do que meio caminho andado.

Concluses

Vimos neste artigo como criar uma aplicao web utilizando os mecanismos de autenticao e controle de acesso definidos pela plataforma J2EE,

mais especificamente pelas APIs de Serv lets e JSP. Vimos tambm como aplicar esses mecanismos a alguns cenrios de aplicaes e comoconfigurar o Tomcat para fornecer estes recursos via um arquivo texto ou um banco de dados.

Mas ainda no esgotamos o tema. No mostramos, por exemplo, co mo utilizar SSL para garantir que as senhas de login no sejam capturadas em

trnsito, nem como utilizar certificados de cliente (HTPS Client Authentication). Na prxima edio veremos como configurar os recursos de

autenticao e controle de acesso web dentro do servidor livre JBoss, e tambm como utilizar os recursos de segurana da plataforma J2EE para

Enterpr ise JavaBeans.

____________________________________________

[1]- O Tomcat um servido r J2EE, significando que implementa funcionalidades prev istas pela especificao J2EE, em especial a funcionalidade

de container web. J o conector HTTP do Tomcat implementa a funcionalidade de servidor web, que poderia ser desempenhada por um

servidor externo como o Apache. (Outros componentes do Tomcat implementam outras caractersticas do J2EE como Datasources JDBC ou

servio de nomes JNI.)

[2]- Observe que realms do Tomcat no tm relao com realms do protocolo HTTP

[3]- A especificao de Servlets define que atributos de sesso cujos nomes iniciem por java so de uso interno do container e no devem


15/18

nunca serem consultados ou modificados pela aplicao. Tambm espera-se que uma aplicao no use este prefixo no s seus nomes de atributos;

[4]- Valve um componente do Tomcat configurado para atuar como filtro em requisies http recebidas pelo container. O seu uso mais comum salvar informaes sobre a requisio em logs de acesso ou de erros, mas poderia ser feita qualquer modificao sobre a requisio ou sobre

sua resposta.

At onde a criptografia garante a segurana?

O atributo digestdos realms do Tomcat realiza a criptografia das senhas armazenadas no servidor; ele no afeta

as se nhas digitadas no navegad or e transm itidas pela requisio HTTP at o se rvidor. Se for utilizado o m ecanismo

Basic, um sn iffer de rede conseg uiria mostrar a senha digitada p elo usurio.

Aind a assim impor tante criptografar a senha, no pela segurana da aplicao, mas pela privacidade dos usurios. Em geral as pessoas utilizam

a mesma senha (ou um pequeno conjunto de senhas) tanto dentro quanto fora da empresa. Ningum gostaria de saber, claro, que seria

possvel ao administrador da rede ou DBA ver sua senha na aplicao web e utiliz-la para acessar seu e-mail, internet banking ou outra

aplicao.

Utilizar o mecanismo HTTP D igest em vez de HTTP Basic melhora um pouco a situao, mas nem tanto. Com o mecanismo HTTP Digest, a senha

criptografada no navegador antes do envio para o servidor. Infelizmente muitos navegadores no suportam esse mecanismo, e a especificao

J2EE no exige que ele seja suportado.

Mesmo se voc utilizar um par navegador/servidor web que suporte o HTTP Digest, ainda assim a senha criptografada poder ser capturada em

trnsito e posteriormente retransmitida, sendo aceita pelo servidor, de modo que no haver necessidade de descriptograf-la. Isso chamado

de ataque de replay, pois a repetio de parte do contedo de um pacote suficiente para o invasor. (Note que esta descrio foi uma grande

simplificao do mecanismo e de seus riscos.)

Para o leitor p reocupado com os riscos que suas senhas correm em intranets e na internet, saiba que as mesmas vu lnerabilidades esto presentesna grande maioria das aplicaes de rede, sejam sistemas de compartilhamento de arquivos NFS, Windows ou Netware, servidores de e-mail ou

bancos de dados. sabido que segurana no uma questo absoluta (seguro ou no-seguro); algo relativo. Um sistema pode ser mais ou

menos seguro do que o outro, mas todos sero em algum grau inseguros.

Uma soluo mais forte deve utilizar algum mecanismo de autenticao distribuda construdo para evitar estes riscos, como o Kerberos.

Infelizmente o padro HTTP no define nenhuma maneira de utilizar o Kerberos ou similares como mecanismo de autenticao. Outra soluo o

uso do protocolo SSL (https://), pelo menos para a pgina de login, pois ele no sujeito a ataques de replay.

Vrios sistemas utilizam cdigo JavaScript no navegador para criptog rafar a senha antes da sua transmisso. Neste caso a autenticao feita pelo

cd igo da aplicao, no pelo servido r ou container web. Estes sistemas sofrem dos mesmos riscos que o HTTP Digest (em geral sofrem mais

riscos, pois o Digest ao menos tenta evitar os ataques mais simples de replay). Portanto c omplicam a aplicao sem realmente aumentar o nvel de

segurana.

O risco de se ter uma senha capturada por sniffing (captura de pacotes) na prtica relativamente baixo. A captura teria que ser feita na rede

local do usurio (o que dificultado pelo uso crescente de switches Ethernet), nos roteadores das empresas e provedores de acesso, ou nos

prprios servidores, significando que j houve um ataque bem-sucedido, ou que h um funcionrio mal-intencionado em alguma das empresas

envolvidas a sua, a empresa do usurio remoto, ou um dos provedores de acesso e de backbone.

O risco bem maior no caso de vrus que instalam monitores de teclado, pginas que imitam aplicaes de home banking ou de comrcio

eletrnico, usurios que escolhem senhas fceis (o invasor adv inha as senhas, em vez captur-las) e usurios que aceitam facilmente tcnicas de

engenharia social, dizendo suas senhas ao telefone para qualquer um que afirme ser, por exemplo, um diretor ou tcnico de suporte da empresa.

Links

onjava.com/pub/a/onjava/2002/06/12/form.html

Sobre o mecanismo de autenticao Form definido na especificao de Servlets

ietf.org/rfc/rfc2068.txt

RFC do IETF que descreve o protocolo HTTP e seus mecanismos de autenticao

ietf.org/rfc/rfc2069.txt

RFC do IETF que descreve o mecanismo de autenticao Digest do HTTPjcp.org/en/jsr/detail?id=154

Especificao de Serv lets, onde so definidos os elementos de autenticao e controle de acesso no web.xml

jakarta.apache.org/tomcat/tomcat-5.0-doc/realm-howto.html

Documentao sobre realms do Tomcat 5

Fernando Lozano([email protected], www.lozano.eti.br) consultor independente, atuando h mais de dez anos em projetos deintegrao de redes, desenvolvimento de sistemas e tuning de bancos de dados. tambm um antigo ativista do software livre, conselheiro do


16/18

Linux Professional Institute do Brasil e autor do livro "Java em GNU/Linux".


17/18


18/18

java magazine - seguranca no j2ee

Documents