Embedding encrypted info about things like the domain, ip address, and
user credentials in the cookie as well as a timeout for the cookie can
make it very difficult to spoof though.
Ollie
On Thu, 2004-02-19 at 23:46, Nicholas Lesiecki wrote:
> I second Andy.
>
> BTW, It is possible to spoof someone else's session id cookie, posing a
> security risk. An application with serious security concerns (banking,
> ecommerce) would need to pay attention to this vulnerability.
> Nick
>
> On Feb 19, 2004, at 10:41 PM, Andrew Barton wrote:
>
> > Hi Robert,
> >
> > Your understanding is the same as mine. But, the security question you
> > pose
> > is interesting. I wonder if it would be possible to change your
> > session ID
> > and access someone else's session. Depending on the application, this
> > could
> > be a security risk.
> >
> > I'll have to look into that...
> >
> > Andy
> >
> > On 2/19/04 8:55 PM, "Robert Zeigler" <[EMAIL PROTECTED]> wrote:
> >
> >> Recently, somebody proposed an interesting question to me which,
> >> though
> >> I'm pretty sure I know the answer, I've been unable to verify.
> >> So, I decided to turn here to see if someone with more wisdom than I
> >> had
> >> an answer. ;)
> >> My understanding of HttpSessions is that, unless you specifically
> >> write
> >> something to a cookie, the only thing stored on the client side is the
> >> sessionID (either via a cookie or via URL rewriting). However, if I
> >> do a
> >> session.setAttribute("someattr",someobject), that object is simply
> >> stored (typically in memory, though not necessarily) server side,
> >> available in the web application context.
> >> Correct so far?
> >> In other words, session "attributes" are not directly editable client
> >> side... right? I mean, this makes complete sense to me, as the client
> >> in
> >> a web app really doesn't give a hoot about foo or bar, it just wants
> >> html. However, someone made a claim to me recently that some
> >> information
> >> stored as a session attribute could be alterred directly by the user,
> >> client side, and therefore posed a security risk to a particular
> >> application.
> >> Any thoughts?
> >> Thanks for the help on this... I've looked over the javadocs, etc.,
> >> and
> >> while they don't say anything to negate my viewpoint, they also don't
> >> say anything specifically to validate it.
> >>
> >> Robert
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >
> > --
> > Andrew Barton
> > eBlox, Inc.
> >
> > 520.903.2541 x102 voice
> > 520.903.2542 fax
> >
> > Discover storeBlox and webBlox at the new eBlox.com!
> > http://www.eblox.com
> > mailto:[EMAIL PROTECTED]
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
