Geoff Soutter wrote:
> Craig R. McClanahan wrote:
> >Geoff Soutter wrote:
> >> Craig R. McClanahan wrote:
> >> >This would be just as fertile a ground for viruses as the Microsoft
> Office
> >> >macros that allowed Melissa and all of its clones. Removing the ability
> to
> >> list
> >> >all the active sessions protects you from this, even in third party
> code.
> >>
> >> Craig, would you consider it safe if the API returned only sessions
> created
> >> by this webapp, and if the session object returned in this case only
> allowed
> >> access to attributes of the session created by this webapp?
> >
> >No, I would not consider it safe even if the list of sessions were
> restricted
> >to this web app. People will still use third party servlets, JSP pages,
> and
> >other components in their apps, so they would still be at risk.
>
> This doesn't make sense to me. If one can use third party components safely
> in a normal app, can't you use them in a servlet too?
"If" you can use them safely, maybe so. It's the "if" that I'm not convinced
there is a universal answer to.
> I thought that one
> must always assume that one's third party components were "secure",
> regardless of wether they were deployed in a java servlet or as an OCX in a
> VB program.
>
Without trying to get into a flame war about it (I'm not interested ... the
following is just my personal preference), that's basically the philosophical
difference between a "trust model" and a "sandbox model" of security.
A trust model assumes you know your component's originator (at least with OCX
controls you have the option to authenticate the originator -- this isn't real
easy for Java class libraries), and trust them not to mess with you (because
they operate in an environment of broad powers). But if that trust is
violated, some pretty nasty things can happen. Have you ever thought about
what a malicious device driver -- for Windows or Linux makes no difference --
could do to you? But people blithely load them all the time, without even
looking at the code.
A sandbox model is more paternalistic (is there a gender-neutral version of
this term? :-): "I'm going to protect you from yourself by not even allowing
certain potentially dangerous activities." At the level of a generic API, my
personal preference is for this attitude to be present; hence, I liked the
changes to deprecate HttpSessionContext and getServlet.
In the particular case of this desire (accessing all the sessions in your app),
a creative design can work around the deprecation of HttpSessionContext for
your own particular app. I know this, because I had to do so to meet the
functional requirements for a particular application (restricting simultaneous
logins on the same username, and allowing a sysadmin to forcibly terminate a
particular session). But I'm not going to explain how -- I'll take
responsibility for loading the gun and pointing it at myself (100% of the code
in this app came from my own fingertips), but not anyone else.
>
> Geoff
>
Craig
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
