Você está na página 1de 29

segurana do trabalho

Os Pritlcipais

rrabalhos

relativos seguratla dos servlets

A tabela abaixo lhe dar uma idia dos principais itens relativos segurana dos servlets. A Autorizao o item mais demorado para se implementar, e a Autenticao vem em segundo lugar. Da perspectiva do servlet, a Confidencialidade e a Integridade dos Dados so razoavelmente fceis de se configurar. *

Conceito de segurana

Quem responsvel?

Nvel de complexidade

Nvel de esforo

Importncia para o exame

maioria dos mdio Administrador Distribuidor alto baixo Distribuidor


Autenticao

de

tem9S entatlzm- l Aut9tlzaft'9 neste Glptu19, p9t'lpe este 9 maJs lmp9ttUlte e G9mpleX9 d9s G9nooJt9S de segutlnl g19bq1s.

*Na verdade, obter a certificao SSL no to simples, ento por "fcil", queremos dizer que "voc na realidade no precisa fazer nada no cdigo do seu servlet". 662 capitulo 12

segurana da aplicao web

Autettticaoo suflciettte para se discutir a Autorizaoo


Posteriormente neste captulo entraremos em mais detalhes sobre a autenticao, mas, por agora, veremos como inserir no sistema apenas a quantidade necessria de autenticao para que possamos nos concentrar na autorizao. O usurio no pode ser autorizado at que tenha sido autenticado. A especificao dos servlets no fala sobre como o Container deve implementar o suporte aos dados de autenticao, incluindo usernames e senhas. Mas, a idia geral que o Container dever fornecer uma tabela, que varia conforme o fabricante, contendo usernames e as suas senhas e papis associados. Mas praticamente todos os fabricantes do um passo alm e fornecem uma maneira de se conectar aos dados de autenticao especficos da sua empresa, freqentemente armazenados em um banco de dados relacional ou em um sistema LDAP (o que vai alm do escopo deste livro). Normalmente, a manuteno destes dados feita pelo administrador.

o "realrn"

da segurana

Infelizmente, o realm mais um termo sobrecarregado no mundo da segurana. Conforme a especificao dos servlets, um realm um local onde as informaes de autenticao so armazenadas. Quando est testando sua aplicao no Tomcat, voc pode usar um arquivo chamado "tomcat-users.xml" (localizado no diretrio conf/directory do tomcat, e NO dentro de webapps). Esse arquivo "tomcat-users. XliI" se aplica a TODAS as aplicaes distribudas sob web-apps. conhecido popularmente como o memory realm, porque o Tomcat carrega este arquivo na memria no momento da inicializao. Embora seja excelente para testes, ele no recomendado para produo. Um motivo para isso que voc no pode modificar o seu contedo sem reinicializar o Tomcat.

o arquivo

torncat-users.xrnl

tJ sf!rVliJtlr

da sf.la tJ.plictJ.{o.f.lSiJ.I': tJ.'i6 di'-Ierl!!nh ele pel'o';ji"+i'r-It.e-:

o';jtJ.s tJ.

<tomcat-users> sel'it.iJ.s e ptJ.pets. <role rolename="Guest"/> <role rolename="Member"/> roles="Member, password="coderll <user name="BillfT </tomcat-users> ~ se ItJctJ.ll;f eo';j a'5lio';j -hj>tl

A-1-&tlMA- FtJ/t.MAI

o';jtJ.pttJ.t'f.lSf.lIriiJS

Guest"

/>

I-eo';jbre- se! IS+6 ti.,

tJ ccn-fr{)le
p{)deFI flsar

tia I.whJrhca{'

pp~ f.lo';ja ~
para

de es+rf.l+f.lI'(1,
f.lo';j

tie titJ.dtJS C"o';jtJes+(1,. al'~fllv{) IJ

!J" N

1;o';jca+,} v6c +"o';jca-l-vsers.

tie idri'canh

)(14.1- ct.a"MiJ.d4

Jto';jl ,) 4 Sfla/ at'''MiJ.'5I!!I1(1, C{)i;1In-f6S Sue

tie nll"Me- Sf!I1t.a-ptJ.pel

6 C411+al~el'

lisa 116"M6"Men+" da af.lhl1.f,-cfJ.'.IJ.

Habilitando a autenticao
Para fazer a autenticao funcionar (em outras palavras, para fazer o Container pedir um username e uma senha), voc precisa inserir algo no DD. No se preocupe com o que isso significa por agora, mas, se quiser comear a brincar com a autenticao, use isto:
<login-config> <auth-method>BASIC</auth-method> </login-config> allhwhcfJ.f'. ~/iJ.re"M(Js s6bl'e I'S+6 "MaiS iJ.J.lltnh
'"

1'/6

"Mas; plll" 1Jj1lNlJ v<lce precisa itll?Cl6l'1ar.

voc est

663

definindo <security-role>

Autorizao, Passo 1: defh1ittdo papis


A forma de autorizao mais comum em servlets o Container determinar se um determinado servlet - e o mtodo que invoca a solicitao HTTP - podem ser chamados por um usurio que recebeu um determinado "papel" de segurana. Assim, o primeiro passo mapear os papis no arquivo "users" (que varia de fabricante para fabricante) aos papis estabelecidos no Deployment Descriptor.

Annie um "Admin", um "Member" e um "Guest".

Ted
Diane

tanto

um "Member",

"Gues'

quanto um "Guest".

VARIA CONFORME O FABRICANTE:


O elemento <role> em tomcat-users.xml
($-1-1'(1-1-111'4 <tomcat-users> <role rolename="Admin"/> <role rolename= er"/> <role rolename=' est"/>

JeJad$

Je V.'N/!J.1"I4$
J"

.f

<user username='
<user username=' <user username=' </tomcat-users>

nie"

password=/Fadminfl

I!papel$

.f

I!SpI!CI{lC4

iane" password="coder" ed" password="newbie"

Member, roles="Member, Guest" roles="Guest" I>

roles="Admin,

Guest'l /> />

deS-N:

~"!J.'1tii! ef,'f!(j!J.i! IY,(JIY,e"l-l-e. tia !J.1I-I-IJl"tjtJ.5';t;.li!

ESPECIFICAO

DO SE VLET:
em web.xml

Ci!J!1-1-oJ#'if!1' itOI!J.pf!la s Sfl4S IPi-ltil'itOIlJ.5';es Je a

O elemento DD <security-ro/e

elf!itOIf!'1-1-"s <secfll"'l'fj-f'lJle> <security-role><role-name>Admin</role-name></security-role> <security-role><role-name>Member</role-name></security-role> <security-role><role-name>Guest</role-name></security-role>


'"

pap~iSJ espec:llCtl.S J(J Idl'l(;!J.I1-N: eitOl t.1eshJ 3 11 ~".:l/SSflel' <1'r::Je-p,D.itOIe>$ 3ve f!"ICiJI't-l-1'1.1" /S P

seu PlJ.

<login-config> <auth-method>BASIC</auth-method> </login-config>

se eS3/1eS" tie 311e Vtlcf! <lc5i'pn:'1liJ>;


C!J.S6

PN!CIStJ.

se~re

til;

3vet't< t.di/i-l-tJ.r ti "1I-N:I1-e"5'i(J,

o dlsttlbuld9t
.1

ctla element9s <t9Ie-name>

n9 DD, pma ~ue 9 C9ntalnet p9Ssa mapem ~o o papelS a usuml9S.


664 C8j?itlJfo 12

segurana da aplicao web

Autorizaol Passo 1.: defi . itldo restries de recursos/ 'Mtodos t


Finalmente, a parte legal. aqui que especificamos, declarativamente, que uma dada combinao de recurso/mtodo acessvel somente a usurios com certos papis. A maior parte do trabalho de segurana que voc far provavelmente ser com elementos <security-constraint> em seu DD (apresentaremos uma srie de regras chatas mais adiante).

Elemento <security-constraint>
<web-app ...> <security-constraint> <web-resource-collection>

no DO:

<web-resource-name>UpdateRecipes</web-resource-name> . <url-pattern>/Beer/AddRec1pe/*</url-pattern> <url-pattern>/Beer/ReviewRecipe/*</url-pattern> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-col1ection> <auth-constraint> <role-name>Admin</ role-name> <role-name>Member</role-name> </auth-constraint> </ securl .t y-cons t' raln t> </web-app> ~ .~ O(s) elf:lln.f:l'rfa(s) <I.++P-IIn.e+t.o,/) ~ " Os elelln.e".f.6s <VI'I-P/1fflM> .lell#'lelln. 6S l'eCill"S6S ti serelln.

Jef.srJeIAJt.Ibos.

f.lll.lS 1In.+".las (JS recf.lt'ss ~ ~

/lrrp sel''"
pe/tJ. fJJtL.

.leltl1il6S

O elf:lln.el1+il "'pciJ1tJ.1<a(/+I.-c6I1S+I'/11i1+> / ~ Ils+a 1/,'1,(1"$ ptJ.pf:1"$ PObiA",( Ii1V6Cal' S ~e+.l6s

/lrr? l"esft'l+tlS.
I'I(JSpa.ll'';es .le

f.itI CV+f'4S
I.<

pallJ.vl'lJ,s,) ele .ll;

jlliA",( es+u, 4V+f'l'G..l(J

1'f:l.<ll"jlJ.f' t.:re

posr

UJeL especlllco.Js.

Por estarem

no papel "Member",

Diane

e Annie podem realizar GET e POST em recursos Iistados nos elementos <url-pattern>. Ted

apenas

um nem

"Guest", ento no pode realizar GET nem POST.

Guest voc est

665

o mtodo isUsernRoe()

As regras de <security-cot1straittt para eletMetttos <web-resourcecollec1iot1>

>

Principais pontos sobre <web-resource-collection>


~ O elemento <web-resource-collection> tem dois subelementos principais: <urlpattem> (um ou mais) e <htlp-method> (opcional, zero ou mais). ~ Os padres URL e Mtodos HTTP trabalham conjuntamente para definir solicitaes de recursos que so

Lembre-se: o propsito do subelemento <webresource-collection> dizer ao container quais combinaes de recursos e mtodos HTTP devem ser restringidas. Gostaramos de poder dizer que voc pode ficar tranqilo aqui, mas voc realmente precisa saber os detalhes destes elementos. Se cometer um pequeno deslize na parte de segurana do seu DD, voc poderia deixar as partes mais sensveis da sua aplicao abertas a... qualquer um. Fazer um site feio pode no abalar a sua reputao, mas se voc vacilar na parte de segurana ... no bom nem pensar nas conseqncias. (Na verdade, estamos apenas tentando assust10 o suficiente para que voc preste ateno nas prximas pginas.)

restringidas. ~ OBRIGATRIO ter um elemento


<web-resource-collection> (mesmo que voc provavelmente no v us-Io para nada). (Considere que para !DE ou uso futuro.) ~ Um elemento <description> OPCIONAL. ~ O elemento <url-pattem> usa regraspadro de nomeao e mapeamento de servlets (consulte novamente o captulo sobre distribuio para detalhes sobre os padres de URL). ~ Voc deve especificar pelo menos um <url-pattern>, mas pode ter vrios deles. ~ Os Mtodos vlidos para o elemento <http-method> so: GET, POST, PUT, TRACE, DELETE, HEAD e OPTIONS. ~ Se um elemento <web-resourcecollection> no contiver nenhum elemento <http-method>, ento a coleo inclui o uso de TODOS os Mtodos HTTP em todos os padres de URL. ~ Se voc DE FATO especificar um <httpmethod>, ento somente os mtodos especificados sero restringidos. Em outras palavras, ao especificar mesmo um s <http-method>, voc automaticamente habilita quaisquer Mtodos HTTP que no tenha especificado. ~ Voc pode ter mais de um elemento <web-resource-collection> na mesma <security -constraint>. ~ O elemento <auth-constraint> aplica-se a TODOS os elementos <web-resourcecollection> na <security-constraint>.

o subelemento
<web-app ...>

<web-resource-

collection> de <securityconstraint>

<security-constraint>

<web-resource-collection>s~s <web-resource-name> UpdateRecipes </web-resource-name>

~
<url-pattern>/Beer/AddRecipe/*</urlpattern> <url-pattern>/Beer/ReviewRecipe/*</ url-pattern> <http-method>GET</http-method> </web-resource-collection> <auth-constraint> </auth-constraint> </security-constraint> </web-app>

666

12

-----------.
da aplicao web

'vel do RECURSO. Elas se e encontram no nI

, A.s restries na ,o ~ da SOLICITAO HTTP. encontram no n1ve ~. Mas na realidade, e a , .os recursos estao restntos. " diz "este um recurso E,tentador pensar que os PMroPtndOTTPqueest.Quandovocerestritocomrelaoao H ," t 'um recurso , .o - d urso + e o combinaao e rec A t realmente dizendo e es e e 'todo HTTP por meio do prorn restrito", o que voce es est sempre restrito em um me . e_collection> de forma ta BTTP GET". O recur:~OSSA configurar a <v.:eb-~esOUI~teno inserindo NENHUM Mtodo, embora v?ced .am restringidos, Slmp esme TODOS os Meto os se] _ essar que ethod>. . 'is tm autorizaao para ~c , elemento <http-m . t> NO define quazs pap.e d ,-r; e quais papis tem O elemento <auth-constram llection>. Em vez dzsso, eJ~n termOs de "Bob e um d b_resource-cO . >. r- pense nISSOem "b ' os recursoS a <we. fcitao restrlta. lVao disso diga Bo e um autorizao 1?arar~al::; ::e~s~r o servlet.A.ddR..ec~~i Member, entao Bo p d alizar uma solzcztaao Member, ento Bob po e re

:::/:;~Tno ;ervlet

AddRecipe".

Se voc especificar um elemento <http-method>,

todos os

mtodos HTTP que voc NO especificar sero restritos! O trabalho do servidor web SERVIR, ento, supe-se que por padro voc queira que os Mtodos HTTP sejam IRrestritos, a no ser que voc diga explicitamente (usando <http-method que um determinado mtodo deva ser restringido (para os recursos listados por <url-pattem. Se voc colocar APENAS um <http-method>GET<! http-method> na restrio de segurana, ento POST, TRACE, PUT, etc. no estaro restringidos! Isso significa que qualquer um, independentemente do papel de segurana (ou mesmo independentemente de se o cliente foi autenticado ou no), pode invocar esses Mtodos HTTP. MAS ... isto s verdadeiro APENAS se voc tiver especificado pelo menos um elemento <http-method>. Se voc NO especificar nenhum <http-method>, ento estar restringindo TODOS os Mtodos HTTP. (Voc provavelmente nunca far isso, porque o propsito de uma restrio de segurana justamente restringir solicitaes HTTP especficas para um determinado conjunto de recursos.) claro que os Mtodos HTTP no funcionaro em um servlet, a no ser que voc substitua o mtodo doXXXO, ento, se tiver apenas um doGetO no seu servlet, e especificar um elemento <http-element> apenas para GET, ningum poder fazer um POST da mesma forma, porque o servidor sabe que voc no oferece suporte a POSTo Ento, podemos modificar a regra um pouco para dizer: quaisquer Mtodos HTTP suportados pelo seu servlet (porque voc substituiu o mtodo de servio correspondente) sero permitidos, A NO SER QUE voc faa uma destas duas coisas: 1) No especificar NENHUM elemento <http-method> no <security-constraint>, o que significa que TODOS os Mtodos sero restringidos. 2) Listar explicitamente o Mtodo, usando o elemento <http-method>.

667

<auth-constrant>

rguas

Regras ehatas de <seeurity-cotlstraint> subeleiltentos de <auth-cotlstraint >

para

Embora tenha a palavra constraint (restrio) no seu nome, este o subelemento que especifica quais papis tm PERMISSO para acessar os recursos web especificados pelo(s) subelemento(s) <web-resource-collection>.

o subelemento
<web-app ...>

<auth-constraint>

de <security-constraint>

<security-constraint> <web-resource-collection> Zs-l-fJ 4ft; 311t A-tiil'll"

</web-resource-collection>

e It4.til'lbtl'

PiIl.lCil'l tJ.iI'IbfJSI4ctf:SSIJ.;"&'s

<auth-constraint>~ <role-name>Admin</role-name> <role-name>Member</role-name> </auth-constrain~


</security-constraint> </web-app>

cfJlJ\bll1lJ.Jf!;s 4fe l'eclIl'sfJs! .lell"ltlfJs 1t4.:-I-l:JtifJS

Hrrp

114

<welr I'es wl'ce-cIJllec+flJ"I>.


H 1/

bllts+
P#I'+o.,,1-# s6/lct1-aJ#es

Its-l-&.)

"I6 +eil'l

pel'lJ\lS s:. ptJ.;"4 I"'ttJ./l;<l!1' tJ.S

I'ts.f.l't.f.tJ.S.

regras de <role-name>
~ Dentro de um elemento <auth-constraint>, elemento <role-name> OPCIONAL. ~ Se existirem elementos <role-name>, eles dizem ao Container quais papis so PERMITIDOS. ~ Se existir um elemento <auth-constraint> sem NENHUM elemento <role-name>, ento NENHUM usuRIo PERMITIDO. ~ Se <role-name>*</role-name>, ento TODOS os usurios so PERMITIDOS. ~ Os nomes dos papis so sensveis caixa alta/baixa. o

regras de <auth-constraint>
~ Dentro de um elemento <securityconstraint>, o elemento <authconstraint> OPCIONAL. ~ Se existir um elemento <auth-constraint>, o Container DEVE realizar autenticao para as URLs associadas. ~ Se NO existir um <auth-constraint>, o Container DEVE permitir acesso noautenticado para estas URLs. ~ Para melhor legibilidade, voc pode adicionar uma <description> dentro de <auth-constraint>.

668 capituo 12

segurana da aplcao web

COlMO <auth-cotlSfraittt> O

fut1ciot1a

Member

Guest

Contedo de <auth-eonstraint>
<security-constraint> <auth-constraint> <role-name>Admin</role-name> <role-name>Member</role-name> </auth-constraint> </security-constraint>

Quais papis tm acesso


Admin
Member

e Guest

<security-constraint> <auth-constraint> <role-name>Guest</role-name> </auth-constraint> </security-constraint>

Guest

<security-constraint> <auth-constraint> <role-name>*</role-name> </auth-constraint> </security-constraint>

Todos

r\

shS

"''''$ h";"

"

--------------Se NO

M.SM,{) efet-l-~.!

houver nenhum <authconstraint>

Todos

<security-constraint>

<auth-constraint>
</security-constraint>

~
~ f.pc..

Nenhum

Se

vcc

ce,/"cQI' "1I\c. -I-4J. Vl<j,-a

ed';tJ lJIJHfJMpil.pf!lh,,:
No haver NENHUM <auth-constraint>

aces~".
de um <auth-constraintJ> VAZIO!

o oposto

Lembre-se disto: se voc no disser quais papis devam ser restringidos, ento NENHUM papel ser. Mas, assim que voc insere um <auth-constraint>, ento APENAS os papis explicitamente indicados tero acesso permitido (a no ser que voc use o coringa "*,, para <role-name. Se no quiser que NENHUM papel tenha acesso, voc DEVE colocar o <auth-constraint/>, apenas deixando-o vazio. Isto diz ao Container: "Eu estou indicando explicitamente os papis permitidos e, a propsito, nenhum !"

quando o <securtty-constrant>

colide

C0i\10 i\1ltiplos elei\1etttos

<security~cottstraittt > ittteragei\1

Bem quando voc tinha pensado que j estava dominando <security-constraint>, voc percebe que mltiplos elementos <security-constraint> podem acabar entrando em conflito. Observe os fragmentos de DD abaixo e imagine as diferentes combinaes de configuraes de <auth-constraint> que poderiam ser usadas. O que acontece, por exemplo, se um <security-constraint> negar acesso, enquanto que outro <securityconstraint> explicitamente concede acesso ... ao mesmo recurso restrito, para o mesmo papel? Qual <security-constraint> tem precedncia? A tabela na pgina seguinte tem todas as respostas.

Mltiplos elementos <security-constraint> com os mesmos (ou parcialmente idnticos) padres URL e elementos <http-method>
<web-app ...> <security-constraint> <web-resource-collection> <web-resource-name>Recipes </web-resource-name> <url-pattern>/Beer/DisplayRecipes/* </url-pattern> <url-pattern>/Beer/UpdateRecipes/* </url-pattern> <http-method>POST</http-method> </web-resource-collection>

I
~'leeCUCi'Y-CUnUCraincu

O
<web-resource-name>Update </web-resource-name> <url-pattern>/Beer/UpdateRecipes/* </url-pattern> <url-pattern>/Beer/UpdateUsers/*

I'!CfJrSt;,S tlefi#1iil.t;,s ei>'!. Iljef!.1'1 H

<security-constraint> <web-resource-collection> eiei>'!.e"+4$ <4i/+t.CCi'lS+r4i#1+> tllferf!I'I"!-es

pii.rii. (;$ plifl!!lS

CCi>'!.

J'lCi>'!.f!.S

iJptl4+ele!Cip!S

1*".

<http-method>POST</http-method> </web-resource-collection> ~
I

</url-pattern>

</security-constraint> </web-app>

Como o container deve realizar a autorizao quando o mesmo recurso usado por mais de um <security-constraint>?

670 ca~)tu(o 12

segurana da aplicao web

Eletttetttos <auth-cot1straittt>

COt1f1itatttes

Se dois ou mais elementos <security-constraint> tiverem elementos <web-resourcecollection> parcial ou totalmente conflitantes, eis como o container resolve o acesso aos recursos conflitantes. A e B referem-se ao DD na pgina anterior.

Contedo de "

Contedo de
<auth-constraint>

Quem tem acesso a 'UpdateRecipes'


Guests e Admins

1
<auth-constraint> <ro1e-name>Gues </auth-constraint> t</ ro1e-name>

<ro1e-name>Acbnin</ro1ename> </auth-constraint>

Todos

2
<auth-constraint> <ro 1e -name>Gues </auth-constraint> t< /ro1e-name>

<auth-constraint> <ro1e-name>*</ro1e-name> </auth-constraint>

Ningum
<auth-constraint>

3
<auth-constraint/>
.j-iJ.jlJfJ.,ifJ.

<ro1e-name>Acbnin</ro1ename> </auth-constraint>

4
NENHUM elemento <auth-constraint>

<auth-constraint> <ro1e-name>Acbnin</ro1ename> </auth-constraint>

Regras para a interpretao desta tabela:


1 Ao combinar nomes de papis individuais, todos os nomes de papis listados sero permitidos. 2 Um nome de papel de "*,, combina com qualquer outra coisa para permitir acesso a todos. 3 Uma tag <auth-constraint> vazia se combina com qualquer coisa para no permitir acesso a ningum! Em outras palavras, uma tag <auth-constraint> vazia sempre tem a ltima palavra! 4 Se um dos elementos <security-constraint> no tiver nenhum elemento <auth-constraint>, ele se combina com qualquer outra coisa para permitir acesso a todos. voc est
t<

671

segurana constraints

f et.s-untas Idl9tas
r:
Eu entendo que colocar um elemento <auth-constraint/> vazio diz ao Container que NINGUEM, de nenhum papel, pode acessar o recurso restrito. Mas no entendo POR QUE voc faria isso. Para que serve um recurso que ningum pode acessar?

N9 exJst~m

I\: Quando

dissemos "NINGUM", queramos dizer "ningum DE FORA da aplicao web". Em outras palavras, um cliente no pode acessar o recurso restrito, mas uma outra parte da aplicao web pode. Voc poderia querer usar um request dispatcher para encaminhar algo para outra parte da aplicao web, mas voc nunca desejaria que os clientes pudessem requisitar esse recurso diretamente. Pense nos recursos 100% restritos como se fossem como os mtodos privados de uma classe Java - para uso interno, somente. Por que o elemento <auth-c!?nstraint> colocado dentro de <security-constraint>, mas NAO dentro do elemento <webresource-collection>?

r:
I\:

Desta maneira, voc pode especificar um s elemento <authconstraint> (que poderia incluir mltiplos papis), e depois especificar mltiplas colees de recursos para as quais a lista de papis de <auth-constraint> aplicar-se-ia. Por exemplo, voc poderia definir um <auth-constraint> para um papel de Frequent Buyer, e ento colocar elementos <web-resource-collection> para todas as diferentes partes da aplicao web s quais um Frequent Buyer tem acesso especial.

r:

Eu tenho mesmo que sentar e digitar cada um dos meus usurios, nome por nome, com as suas senhas e os seus papis?

I\: Se estiver usando o realm de memria de test do Tomcat, sim.


Porm, no mundo real, provvel que voc esteja usando um servidor de produo que lhe fornea uma conexo ao LDAP ou banco de dados onde as informaes reais de segurana dos seus usurios esto armazenadas.

672 captulo 12

segurana da aplicao web

o servlet

recipe de Alice, utlta histria sobre

segurana progratltfica ...


Alice sabe que, na maioria dos casos, a segurana declarativa a melhor soluo. Ela flexvel, poderosa, porttil e robusta. medida que as arquiteturas de aplicaes web foram evoluindo, os servlets foram ficando mais e mais especializados. Antigamente, um nico servlet seria usado para fornecer a lgica de negcios para dar suporte a funcionrios e gerentes. Hoje em dia, estas funes provavelmente seriam divididas em pelo menos dois servlets distintos. Mas, a sortuda Alice simplesmente herdou o "RecipeServlet" de algum. Alice ouviu um boato dizendo que o RecipeServlet usa segurana programtica, ento, ela comea a verificar o cdigofonte e encontra este fragmento ...

if( request.isUse~InRole("Manage~")

II

crie a pgina UpdateRecipe ~ crie a pgina


ViewRecipe

/I CtJIIJC61,1 MI).I1~ei"

fi
CIJIiIC 11"'liIe Je Viii

else {

II

se 4 Sfl4 ftl'lpl"ftstJ. .f..t"vl!sse piprs

JlleNtl1ffs) Cl(j"'S I1tJliIl!S tJPI"tJ91"41i1aJcI" JtJ sf!;i"vle+ JeSC411t.ece?

Quais so as implicaes?
Pense no que voc aprendeu at aqui neste captulo, observe o pequeno fragmento de cdigo acima, e tente responder as questes.

Que passo referente segurana deve ser realizado antes deste fragmento rodar? Que passo referente segurana est implcito neste fragmento? Qual a funo, se que h alguma, desempenhada pelo DD neste fragmento? Como voc acha que este cdigo funciona? E se o papel de "Manager" no existir no seu container? voc est aqui 673

li>

o mtodo

CustotMiza.,do

tMtodos: isUserl.,((.oleO

No HttpServletRequest, trs mtodos so associados segurana programtica: O getUserPriucipalO, que usado principalmente com EJBs. No iremos abord-Io neste livro.* O getRemoteUserO, que pode ser usado para verificar o status da autenticao. No usado normalmente, ento no iremos abord-Io neste livro (e no h nada que voc precise saber sobre ele para o exame). O isUserInRoleO, que examinaremos agora. Em vez de autorizar no nvel do mtodo HTTP (GET, POST, etc.), voc pode autorizar o acesso a partes de um mtodo. Isto lhe fornece uma maneira de customizar como um mtodo de servio se comportar, com base no papel do usurio. Se voc estiver neste mtodo de servio (doGetO, doPostO, etc.), significa que o usurio passou pela autorizao declarativa, mas agora voc deseja fazer algo no mtodo de forma condicional, com base em se o usurio est em um determinado papel.
Acabei de receber este servlet do Stan, do departamento de contabilidade, e ele escreveu diretamente no cdigo alguns papis que ns nem temos. (que %$&# um superCliente?) No vou redefinir, de jeito nenhum, todos os papis no meu container, s para poder usar o servlet

O
O

idiota do Stan ...

Como voc combina papis no DD com papis em um servlet?

Como funciona:

Antes de isUserInRoleO ser chamado, o usurio precisa ser autenticado. Seo mtodo for chamado para um usurio que no estiver autenticado, o Contaner sempre retomar "falso". O Container pega o argumento de isUserInRoleO, neste exemplo, "Manager", e o compara aos papis definidos para o usurio nesta solicitao. Se o usurio estiver mapeado a este papel, o Container retoma "verdadeiro".

e e

* Ns conhecemos, no entanto, um livro sobre EJB muito bom ... 674

12

segurana da aplicao web

o lado declarativo

da seguratla prograJ\1tica

H uma boa chance de que, quando um programador escreve nomes de papis de segurana diretamente no cdigo de um servlet (para usar como o argumento para isUserlnRole()), o programador est apenas inventando um nome qualquer. Ou ele nem sequer sabia os nomes reais dos papis, ou est escrevendo um componente reutilizvel que ser usado por mais de uma empresa, e essas empresas dificilmente tero os mesmos exatos nomes de papis que o programador usou. ( claro que, se o programador realmente quisesse criar componentes reutilizveis, escrever um nome de papel diretamente no cdigo seria uma Pssima Idia, mas vamos deixar isso para l.) Ocorre que o Deployment Descriptor tem um mecanismo para mapear nomes de papis escritos diretamente no cdigo (o que equivale a dizer inventados) de um servlet s declaraes "oficiais" de <security-role> no seu Container. Imagine, por exemplo, que o programador tenha usado "Manager" como o argumento de isUserlnRoleO, mas a sua empresa usa "Admin" como o <security-role>, e voc nem sequer tem um papel de segurana chamado "Manager". Assim, mesmo que no possa impedir um programador de escrever nomes de papis diretamente no cdigo, voc pelo menos tem um remdio para quando os papis escritos diretamente no coincidirem com os seus reais nomes de papis. Porque, mesmo que voc tenha o cdigo-fonte do servlet, voc realmente vai querer modificar, recompilar e testar novamente o seu cdigo, s para mudar todas as ocorrncias de "Manager" para "Admin"?

No servlet
if( request.isUserInRole("Manager") crie a pgina UpdateRecipe

NoDD
<web-app ...> <servlet> <security-role-ref> <role-name>Manager</role-name> <role-link>Admin</role-link> </security-role-ref> </servlet>

II

else

{ crie a pgina ViewRecipe

II

<security-role> <role-name>Admin</role-name> </security-role> PiJl''!!fH! '1~6 i'/ fi

eh~~~~6

~a~~el'
tJ
I"

</web-app>

ele~etrl-6
1"/

Pf'HS

pl'<l5ro.~o...,..;(:(;S

C(;~ij(;)a ele~el'/+6S

o Container

usar um mapeamento com <security-role-ref> mesmo SE o nome programtico coincidir com um nome "real" de <security-role>.

Quando o Container designa um argumento para "isUserInRoleQ ", ele procura PRIMEIRO por um <security-role-ref> correspondente. Se encontrar um, isso que o Container usa, mesmo que o nome escrito diretamente no cdigo DE FATO coincida com um n07n;~ de " <security-role>. Pense nisso - voc poderia de fato TER um papel de segurana Manager na sua empresa, mas ele poderia significar algo completamente diferente daquilo que o programador tinha em mente. Assim, voc poderia, por exemplo, mapear o "Manager" escrito no cdigo a "Admin ", e depois mapear um "Director" escrito no cdigo a "Manager". Assim, o <security-role-ref> sempre tem precedncia quando ambos incluem o mesmo <role-name>.

voc est

il>

675

exercco de segurana

Suponha que todos os constraints abaixo tenham os mesmos elementos <url-pattem> e <http-method>. Com base nas combinaes mostradas, decida quem poder acessar diretamente o recurso restrito. Member Todos Admin Guest <auth-constraint> foi definido. <auth-constraint> <auth-constraint/> <role-name>Admin</role-name> <role-name>Guest</role-name> <role-name>*</role-name> <role-name>Member</role-name> </auth-constraint> <security-constraint> </security-constraint> </security-constraint> <auth-constraint> <security-constraint> <auth-constraint> <auth-constraint/> ~<s~~~ritY-Constraint> ~ <s~~~ritY-Constraint>

... ...

Assuma que NENHUM

Ningum

676 cap,'tulo 12

segurana da aplicao web

Autet1ticao revisitada
Para um Container J2EE, a autenticao se resume a isto: pedir um nome de usurio e uma senha, e depois verificar se eles esto corretos. Na primeira vez que um usurio no-autenticado pedir um recurso restrito, o Container automaticamente iniciar o processo de autenticao. H quatro tipos de autenticao que o Container pode fornecer, e a principal diferena entre eles "O quo seguramente as informaes de nome e senha so transmitidas?"

Os QUATRO tipos de autenticao


A autenticao BASIC transmite as informaes de login em uma forma codificada (no criptografada). Isso pode parecer seguro, mas voc provavelmente j sabe que, uma vez que o esquema de codificao (base64) bastante conhecido, o BASIC fornece muito pouca segurana. A autenticao DIGEST transmite as informaes de login de uma forma mais segura, mas, pelo fato de o mecanismo de criptografia no ser muito usado, os containers J2EE no so obrigados a suport-lo. Para mais informaes sobre a autenticao DIGEST, consulte a IETF RFC 2617 (www.ietf. org/rfc/rfc2617.txt). A autenticao CLIENT-CERT transmite as informaes de login de uma forma extremamente segura, usando Certificados de Chave Pblica (Public Key Certificates, ou PKC). A desvantagem deste mecanismo que os seus clientes precisam ter um certificado antes de eles fazerem login no seu sistema. bem raro que consumidores tenham um certificado, ento, a autenticao CLIENT-CERT usada principalmente em cenrios de empresa para empresa. Todos os trs tipos acima - BASIC, DIGEST e CLIENT-CERT - usam o formulrio pop-up padro do browser para inserir o nome e a senha. Mas o quarto tipo, FORM, diferente. A autenticao FORM lhe permite criar o seu prprio formulrio de login customizado a partir de qualquer coisa que seja HTML permitido. Mas ... de todos os quatro tipos, as informaes do formulrio so transmitidas da forma menos segura. O username e a senha so enviados de volta na solicitao HTTP, sem criptografia.

voc est aqui ~

677

de autenticao

ItMpletMet'ltattdo

Autentiea~o

Esta a parte simples - basta declarar o esquema de autenticao no DD. O principal elemento do DD para autenticao o <login-config>.

Quatro exemplos de <Iogin-config>:


<web-app ...> <login-config> <auth-method>BASIC</auth-method> </login-config> </web-app>

() 6fJrSIC btSlct:>.

Jw"a

o 11<3eI! D!J; <l C<ll1+fJ.Ii1er s y stei'1t.o. o.V+iJw"fJ.+lcfJ.w"el1hw" ystt'WfJ."",e te ilw"tJ. ilw"l"eC{,Il"s<:J I"es+",t+tj

-ou<web-app ...> <login-config> <auth-method>DIGEST</ </login-config> </web-app> ~ auth-method> Se sev CI{J"+O.li1te'"SIlf'()I'+o.l'


'f'

<l

DI{.s-r; ele

w"anl vltl"': rODOS 4$ tle+fJ.IAe$.

-ou<web-app ...> <login-config> <auth-method>CLIENT-CERT</auth-method> </login-config> </web-app>

O CL.I1.lJr Se(/S c/tenhs Mas;

tle tleIN:"'';()

tle fa+6; ele IAe hU"I1ece

.'x.rJt.fJrFOJt.r/

-ou<web-app ...> <login-config> <auth-method>FORM</auth-method> <form-login-config> <form-login-page>/loginPage.html</form-login-page> <form-error-page>/loginError.html</form-error-page> </form-login-config> </login-config> </web-app>

e o "",a/s
Ii"e"",,,s
o.

I'

I' eXfJ.Wtli'lfJ.-{{j

tle

678

segurana da aplicao web

Autettticao

Jaseada

et11 FOrtMUlrios

Embora seja mais complicada de implementar do que as outras formas, a autenticao FORM no to ruim. Primeiramente, voc cria o seu prprio formulrio HTML customizado para o login do usurio (embora ele possa certamente ser gerado por um JSP). Em seguida, voc cria uma pgina de erro HTML customizada para o Container usar quando o usurio cometer um erro de login. Finalmente, voc junta os dois formulrios no DD, usando o elemento <login-config>. Nota: se estiver usando a autenticao de formulrio, certifique-se de ativar o SSL ou o tracking de sesso, ou o seu Container poder no reconhecer o formulrio de login quando este for retomado!

o que VOC

faz:
no DD

Trs entradas no formulrio de login so a chave para a Comunicao com o Container: Lsecurity_check

Declara <Iogin-config>

Cria um formulrio de login HTML Cria um formulrio de erro HTML

-Lusername -Lpassword

No DO...

<login-confg> <auth-method>FORM</auth-method> <form-login-confg> <form-login-page>/loginPage.html</form-login-page> <form-error-page>/loginError.html</form-error-page> </form-login-confg> </login-config> () C.M+ai";lel' exije Jtle

aI

ar""a-;elle 6 1'/6""e ,i6 tlSIIQI'IC,

Dentro de loginPage.html. ..
login daddy-o
PQt'lt

Please

6 t:.,611+QI'IIel'

<fo~m method~"~OST" "actio~:'~j_Securit:_c~eck"> <lnput type~"password" name- J_username > ~<input type~ text name="j-?assword"> <input </form> type~nsubmit" value="Enter">

---' {""V!Qt';,ie r J-secvrl-h- ct.eck

'7-

Dentro de loginError.html ...


wrong password

<html><body> Sorry dude, </body></html>

..............................................................

~l\elaxe! pgina para exame! ~ l'J9 I Voc precisa osaber tudo .

nesta

..............................................................

voc est

1>0

679

de tipos

ResutMO dos tipos de

Autetrlica~o

Esta tabela resume os principais atributos dos quatro tipos de autenticao. "Spec" refere-se a se o tipo do mecanismo de autenticao em questo definido na especificao HTTP ou na J2EE. (Dica: voc ter que se lembrar desta tabela quando for fazer o exame.)

Tipo
BASIC

Spec
HTTP

Integridade dos Dados


Base64 - fraca

Comentrios
Padro HTTP, todos os browsers o suportam. Opcional para containers HTTP e J2EE. Permite o uso de uma tela de login customizada. Forte, mas os usurios devero ter certificados.

DIGEST

HTTP

Mais forte - mas sem SSL

FORM

J2EE

Muito fraca, sem criptografia

CLlENT-CERT

J2EE

Forte - chave pblica (PKC)

retguntlS Idl9tls
N9 e.xlst~m

r:

o que a integridade dos dados tem a ver com a Autenticao?


Quando voc est autenticando um usurio, este lhe envia o seu username e senha. A integridade dos dados e a confidencial idade referem-se a at que ponto um espio pode roubar ou modificar estas informaes. Em instantes, falaremos sobre como implementar a integridade dos dados e a confidencialidade durante o login. A integridade dos dados significa que os dados que chegam so os mesmos que foram enviados. Em outras palavras, ningum os modificou no caminho. A confidencialidade dos dados significa que ningum mais pode ver os dados durante o percurso. Na maioria dos casos, no entanto, trataremos a integridade dos dados e a confidencial idade como um s objetivo - coisas que voc precisa fazer para proteger os dados durante a transmisso.

Preencha as lacunas para esta aplicao de autenticao baseada em formulrio. Isto apenas para ajud-lo a memorizar as partes do DD relacionadas autenticao e o formulrio HTML. (As respostas esto na pgina anterior.)

I\:

DO
<login-config> <auth-method>l:::::]</auth-method> <form-login-config> > <I l>/loginpage.html< 1 . _

<form-error-page>/loginError.html</form-errorpage> </form-login-config> </login-config>

HTML
Please <form login daddy-o action=I name= I>

method~HPOSTH type~HtextH

<input <input <input </form>

1:::::::::::::::::::1>

type=HpasswordH type=HsubmitH

name=HJ_passwordH> value=HEnter">

680 captulo 12

segurana da aplicao web

Ela no cotlhece a "cotlexo de catMada de transporte

protegida~~o d

JZEE

No entre em pnico. Voc pode ter o seu formulrio de login customizado e seguro. Os dados de login ainda so dados, ento voc pode proteger a segurana deles da mesma forma que voc protegeria um nmero de carto de crdito em uma loja virtual - usando os recursos de integridade de dados e de confidencialidade compatveis com o J2EE do seu Container.

voc est

li"

681

seguro

Protegendo a

seguran~

dos dados etMtrnsito: HffPS etMao

Quando voc diz a um Container J2EE que deseja implementar a confidencialidade e/ou integridade dos dados, a especificao J2EE garante que os dados a serem transmitidos viajaro atravs de uma "conexo de camada de transporte protegida". Em outras palavras, os Containers no so obrigados a usar nenhum protocolo especfico para manipular transmisses seguras, mas, na prtica, quase todos usam HTTPS, em vez de SSL.

solicitao HTTP - no segura


HTTP atravs de TCP
POST /CheckOut.jsp '" [request headers] creditCardNum=5551212343 &expDate= 0505

contamer

Mal-intencionado obtm cpia da solicitao HTTP que contm as informaes do carto de crdito do cliente. Os
uma

o Espio

dados no so protegidos, ento, eles vm no corpo do POST em um formato perfeitamente legvel. O espio fica feliz.

POST /advisor/SelectBeerTaste.do

HTTP/l.l

... [request headers here] creditCardN nm=5551212343&expDate=0505

Uma solicitao segura HTTPS atravs de SSL


HTTPS atravs de SSL atravs de TCP
POST /CheckOut.jsp e7x33fg7gwXll sdf@ll f666d41dd f666d41dd

contamer

O Espio Mal-intencionado obtm uma cpia da soliCitao HTTP que contm as informaes do carto de crdito do cliente. Mas, pelo fato de elas terem sido transmitidas com HTTPS extrafortes atravs de SSL, ele NO PODE ler as informaes!!

682

C8jOti'JlO

12

segurana da aplicao web

Voc precisa que cada solicitao e resposta sejam seguras? Se no, quais partes da sua aplicao precisam de transmisses seguras?

Pense no que foi abordado neste captulo. Para a sua aplicao web ser rpida, eficiente e segura, voc ter que responder a algumas questes ... (no h respostas para este exerccio; voc deve descobri-Ias).

o que voc o que

acha que a confidencialidade dos dados significa? voc acha que a integridade dados significa? dos

Se voc pudesse aplicar medidas de segurana de transmisso a apenas algumas solicitaes e respostas, como voc desejaria dizer ao Container quais solicitaes e respostas so essas?

Voc consegue pensar em quaisquer outros elementos do DD que funcionem no mesmo nvel de granularidade que voc deseja para declarar transmisses protegidas?

voc est

683

confidencia/idade

e integridade

00"'0 i",ple",etrtar cot1fidettcialidade e integridade de dados caso a caso e declarativa",ettte


Mais uma vez, observaremos o DD. Na verdade, usaremos o nosso velho amigo <security-constraint> para a confidencialidade e a integridade, adicionando um elemento chamado <user-data-constraint>. E quando voc pra pra pensar, faz sentido - se estiver considerando a autorizao para um recurso, voc provavelmente ir considerar se quer os dados transmitidos de forma segura.
<web-app ...>

<security-constraint>

<web-resource-collection> <web-resource-name>Recipes</web-resource-name> <url-pattern>/Beer/UpdateRecipes/*</url-pattern> <http-method>POST</http-method> </web-resource-collection>

/
SIJ iss/1l/r1 l'el{J.cll1ar1

&1l

,
r1dS <.vser

twh3l'trlar1e
<auth-constraint> <role-name>Member</role-name> </auth-constraint>

&1l

clJl1ltrlem;;/"aItr1ar1e

r1fJ.r1IJS : +1'1J+fJ.r1 J1 ele~eJ1+(; r1t<+IJ.-CJ1s+I"o.lJ1+>

</security-constraint> </web-app>

u~o.
Junte estes trs subelementos para ler: Apenas Members podem fazer solicitaes POST a recursos encontrados no diretrio UpdateRecipes, e certifique-se de que a transmisso segura. Valores legais para <transport-guarantee>
/,o.vel"lJ. I1fceS!#r1t11,r1e r1e +e

pltJ.J1'fjfJ.J1r14

NONE

PI'IJ+e31!1'

4S r1fJ.r1cs/

Este o padro, e significa que no haver proteo dos dados. INTEGRAL Os dados no podem ser modificados ao longo do caminho. CONFIDENTIAL Os dados no podem ser vistos por ningum ao longo do caminho.
NOTA: embora no garantido pela especificao, na prtica quase todos os Containers usam o SSL para o transporte garantido, o que significa que tanto INTEGRAL como CONFIDENTIAL fazem a mesma coisa - qualquer um dos dois lhe fornece tanto confidencialidade quanto integridade. Uma vez que voc s pode ter um <user-dataconstraint> por <security-constraint>, algumas pessoas recomendam que voc use CONFIDENTIAL, mas, novamente, isso provavelmente nunca far diferena na prtica, a no ser que voc mude para um novo (e incomum) Container que no use SSL.

684 caJ.~tu,'o 12

segurana da apJfcao web

Protegendo os dados da solicitao


Lembre-se de que, no DD, o <security-constraint> refere-se ao que acontece aps a solicitao. Em outras palavras, o cliente j fez a solicitao quando o Container comea a olhar os elementos <security-constraint> para decidir como responder. Os dados da solicitao j foram enviados atravs da conexo. Como possvel lembrar o browser de que "ah, a propsito ... se por acaso o usurio requisitar este recurso, mude para os sockets seguros (SSL) antes de enviar a solicitao". O que voc pode fazer? Voc j sabe como forar o cliente a receber uma tela de login ~ definindo um recurso restrito no DD, o Container automaticamente iniciar o processo de autenticao quando um usurio no-autenticado fizer a solicitao. Ento, agora temos que descobrir como proteger os dados vindos de uma solicitao ... at mesmo (e, s vezes, principalmente) quando o cliente ainda no tiver feito o login. Poderamos querer proteger os seus dados de login! Vamos ver como tudo isso funciona ...

voc est

J!o

685

sem <transport-guarantee>

o cliente

no-autorizado requisita um recurso restrito que NO tem garantia de transporte

o
O cliente requisita IBuyStuff. jsp, que foi configurado no DD com um <security-constraint>.

o Container

verifica o <securityconstraint> e percebe que BuyStuff um recurso restrito ... o que significa que o usurio DEVE ser autenticado. O Container

<user-data-constraint> <transport-guarantee> NONE </transport-guarantee> </user-data-constraint>

descobre que NO h garantia de transporte para esta solicitao.

HTTP atravs de TCP POST /BuyStuff.

conTamer

o~
e

/I
AJOAJf

el'rriJ.6 e iSSIJ3Je .. l/6ce I',gcde >'t\eShl6 se AJIJrO eSfeci'fic{U' 1Ih1 elehlf!l'I+tJ !J!J flu'a <+riJ.I'ISfcl'+-

/.'" I

11 I '" f! 6 fiJ.IliI'fJ.6;

O Container envia um 401, que diz ao browser para obter informaes de login do usurio, como resposta ao cliente.

O browser faz a mesma solicitao novamente, mas desta vez com as informaes de login do usurio no header.

401 Unauthorized WWW-Authenticate: Basic realm ="user"

OST /BuyStuff.jsp uthorization: Basic: x5w3 ..=

container

....

l.f((/ IJrs c!ie".f.e


cJtel1.f.e

llie llic fl'tI.>'t\el'l';/I<IIiiJ.s ff"hllI. de

Sf!ji/l'lI.. () f,lSf!f"'1Q,hlf! <l Sf!I'It.11, e de

O Container autentica o cliente (verifica se o username e a senha coincidem com os dados do usurio configurados no servidor). Em seguida, o Container autoriza a solicitao para certificar-se de que o usurio em questo est em um papel que tem permisso para obter o recurso restrito. Tudo est certo, ento a resposta enviada. <html> Enter Credit Card <input type=text

#
Container

name=ccNum>

</html>

686

12

segurana da aplcao web

o cliente
o cliente

no-autorizado requisita um recurso restrito, que tem uma garantia de transporte de CONFIDENCIALlDADE
v que este recurso restrito tem uma garantia de transporte. O Container percebe que a solicitao NO chegou de forma segura ...

requisita /BuyStuff. jsp, um recurso restrito que tem tambm uma garantia de transporte.

o Container

user-data-constraint> <transport-guarantee> CONFIDENTIAL </transport-guarantee> </user-data-constraint

HTTP atravs de TCP


POST /B

Container

e
e

o Container envia um 301, que diz ao browser para redirecionar a solicitao usando um transporte seguro, como resposta ao cliente.
301 Redirect Location:HTTPS:1

I...

Container

o
, .,

I
e
fl.

<l

(Isfl.iil<l ptU'fl. J1<l,"'~fl.I'"s~tJ.S

l'eiilif'ecrpPlo.~eJ1.f<ls

rAM$f.X-{
di')
de 0.4

'<lI'~fJ. pe/fI. /I A~~tJJ


f'

bl'iJwst'l': '"

tlflfJ. CCPlextM st'Stll'Q. dfl', PI'4X1/M,t;.


vel'e~cs se pCdell?t6S C6I'lVeI'So.l'

!JAZ
O browser faz a mesma solicitao novamente, mas, desta vez, atravs de uma conexo segura. Em outras palavras, o recurso permanece o mesmo, mas o protocolo agora o HTTPS.

Agora, o Container v que o recurso restrito, e que o usurio no foi autenticado. Ento, agora o Container inicia o processo de autenticao, enviando um "401" ao browser ... 401 Unauthorized WWW-Authenticate:Basic realm ="user"

O browser torna a fazer a mesma solicitao (sim, pela TERCEIRA vez), mas desta vez a solicitao tem os dados de login do usurio no header E a solicitao chega atravs de uma conexo segura. Ento, desta vez os dados de login do cliente so transmitidos de forma segura!

POST /BuyStuff.jsp Authorization: Basic: x5w3 ..=

voc est

687

(iados de login

Para certificar-se de que as informaes de login do usurio so submetidas ao servidor de forma segura, coloque uma garantia de transporte em TODOS os recursos restritos que possam iniciar o processo de login!
Lembre-se, quando voc usar autenticao declarativa, o cliente nunca faz uma solicitao direta para o login. O cliente dispara o processo de loginlautenticao requisitando um recurso restrito. Assim, se quiser certificar-se de que os dados de login do seu cliente chegaro ao servidor atravs de uma conexo segura, voc precisa colocar uma <transport-guarantee> em TODOS os recursos restritos que possam disparar o formulrio de login para o cliente! Dessa maneira, o Container receber a solicitao pelo recurso restrito, mas, ANTES de dizer ao browser para obter os dados de login do cliente, o Container diz a ele: "Voc no deveria nem sequer FAZER esta solicitao sem estar usando uma conexo segura." Ento, quando o cliente retoma, o Container AGORA diz: "Bom, estou vendo que voc est em uma conexo segura, mas ainda assim preciso dos dados de autenticao do usurio." O browser apresenta o formulrio de login para o usurio, obtm as suas informaes, e envia de volta esta TERCEIRA solicitao, atravs de uma conexo segura.

N9 e.xIste.m

Yeth'unt:ls idl9ta.s

p: Eu no entendo por que O Container


retor~~ u~ REDIRECT (301) ao cliente quando a sOh~ltaao chega sem uma conexo segura. Isto Simplesmente no faz redirecionar de volta para a mesma solicitao original?
Normalmente, voc pensa no r~direcionamento como significando "ei, browser, va para uma URL diferente, em vez dessa". O redirecionamento invisvel ao cliente, lembrese; o browser do cliente automaticamente faz a nova solicitao para a URL especificada no header redirect (301) que vem do servidor. Mas,G0!TI a segurana de transporte um pouco diferente. Em Vez de dizer ao browser do cliente "redirecione para um recurso diferente" o Container diz: "redirecione para o mesmo ' recurso, mas Com um protocolo diferente - use HTTPS em vez de HTTP".

p: Ento,deo alguma atravsno Container? HTTPS do SSL j Vem embutido forma


,No garantido pela especificao, mas e bastante provvel que o seu Container esteja usando HTTPS atravs do SSL (sockets seguros). Mas isto no Ser necessariamente automtico! Voc provavelmente ter que ?onfigurar o SSL no seu Container e, mais Importante - voc precisa de um certificado! Voc ~er que v~rificar na documentao do seu Contalner, mas e provvel que o seu COhtainer possa gerar um certificado que voc poder usar para testes, m~s, p~ra produo, voc ter que obter uma certlficaao de Chave Pblica a partir de uma fonte "oficial", como o VeriSign. (Os certificados e Os protocolos de segurana, como o HTTPS e o SSL, vo muito alm do escopo do exame, a propsito. S ser cobrado qu~ vo~ saiba o que tem que fazer no DO, e por que. Nao se espera que voc seja um especialista em sys-admin e segurana de redes.)

I\:

1\:

688

da aplicao web

Configure os aspectos de segurana de uma aplicao web, preenchendo os trs blocos no DD abaixo. A aplicao web dever ter o seguinte comportamento: Voc quer que todos possam fazer um GET nos recursos dentro do diretrio BeerlUpdateRecipes (incluindo quaisquer subdiretrios), mas quer que APENAS oS que tiverem o papel de segurana "Admin" possam realizar um POST nos recursos dentro desse diretrio. Alm disso, voc deseja que os dados sejam protegidos, de forma que ningum possa espionar.
<web-app ...>

<security-constraint>

</security-constraint>

</web-app>

voc est

lP

689

exerccio de segurana

Preencha a seguinte tabela com os elementos DD relevantes. Voc ver as respostas ao virar a pgina (e nem sequer OLHE a pgina seguinte!).

Objetivo de segurana

O que voc colocaria no DD

Voc deseja que o Container faa autenticao BASIC automaticamente.

Voc deseja usar a sua prpria pgina customizada de formulrio, chamada "loginPage.html" (e distribuda diretamente na raiz da aplicao web), e deseja que "loginError.html" seja exibida, caso o cliente no possa ser autenticado.

Voc deseja restringir tudo que tiver uma extenso ".do" para que todos os clientes possam fazer um GET, mas apenas Members possam fazer um POST.(NO preciso incluir os elementos do DD necessrios para configurar as informaes de login.)

Voc deseja restringir tudo dentro do diretrio joo/bar, de modo que apenas os usurios com um papel de segurana Admin possam invocar QUAISQUER mtodos HTTP para esses recursos. (NO preciso incluir os elementos do DD necessrios para configurar as informaes de login.)

690

12