Need Session Help!

[Sonny Sukumar <ah...@hotmail.com>]

Hi guys,

I know I've brought up some session questions before, and I gained great 
insight from those discussions, but there's some issues I want to understand 
better before I make implementation decisions.  Assume the context of a B2C 
e-commerce site when considering these issues....

---Assume URL encoding is being used because a customer has all cookies 
turned
off.

1.) Customer puts a few items in her shopping cart.
2.) Customer logs in to view some account details.
3.) Customer then sees her friend on IM and copies a product page URL to her
friend.  This URL contains her session ID.
4.) The friend clicks on the link and views the product page.  However, she
now can click on "My Account" or whatever or "My Cart", and because she'll
appear to be the first customer (she has the same session ID), she can view
all the personal details she shouldn't be able to.

What's the best way to go here?  I'm thinking that if
A.) a given page allows URL encoding to be used and
B.) it contains *any* sensitive info that shouldn't be seen even if the URL 
is
copied and
C.) even if the customer is already logged in

then the customer should have to log in to see that page every time that 
page
is requested.  This seems like a hard policy to implement though (and 
tedious
for the customer), and I don't see any support for it in the Auth Framework.
After all, if you have the session ID and the "authentication" context is in
the session, then you're considered logged in.  And with URL encoding,
anybody could go and view your account details.

So I don't like URL encoding. :-) However, I'm worried about losing 
customers
who don't have cookies turned on and I notice that most major e-commerce
sites allow URL encoding.  What would you do?

--Should I ever allow URL encoding during the secure checkout process?

In theory it seems like if I'm storing a super sensitive piece of data like 
a
credit card number in the session, then I wouldn't want the session ID being
so visible as it is when in the URL textbox at the top of the browser 
window.

URLs are also often stored in web server logs and other places, and if it
contains the session ID this can spell trouble because there's a "window of
vulnerability".  Our session timeout is set to 4 hours, so that's 4 hours
during which somebody could access that sensitive info.

On the other hand, if pages coming before the checkout allow URL encoding 
and
the checkout process doesn't, then that gives the impression that the site
will always work even with session cookies turned off.  Then the customer
finally finds what she wants, puts it in her cart, and heads to
checkout--only to find that she needs to have cookies enabled!  I'm not sure
that's the best way to go, although it can be argued from a security
perspective (but customers are emotional and won't consider
technical/security aspects for a second).

--If URL encoding was being used on a previous page, and then now (say 5
minutes later, or sometime later that still comes before the session times
out) session cookies are enabled, would it still be possible to use the
previously encoded session ID to access the session?  Or would Tomcat 
destroy
that session ID key as soon as it recognizes it can use cookies?

For example, if my encoded session ID was "ABCD" (just an example!), and now 
I
turn on cookies so the next page I request has no more encoded session ID,
can I still somehow use that session ID to access the session?

My guess is no, but I thought I'd ask.

--I'm also pretty sure about this, but I thought I'd ask this too... :-)

Just because somebody gets ahold of the session ID, there's no possible way
for them to *actually* access the session is there?  I mean, they'd have to
rely on requesting a page that happens to hand over that sensitive info
stored in the session, right?

Again, I'm fairly sure they can't actually fetch the Java objects, or even
read the bytes out of server memory, but it's almost a moot point since 
pages
are always going to exist to serve up that info.  Otherwise the info 
wouldn't
be stored in the session in the first place. :-/

Thanks for your help and insights,

Sonny

_________________________________________________________________
Instant message with integrated webcam using MSN Messenger 6.0. Try it now 
FREE!  http://msnmessenger-download.com


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

Re: Need Session Help!

[Joerg Heinicke <jh...@virbus.de>]

Sonny Sukumar wrote:
> 
> Hi guys,
> 
> I know I've brought up some session questions before, and I gained great 
> insight from those discussions, but there's some issues I want to 
> understand better before I make implementation decisions.  Assume the 
> context of a B2C e-commerce site when considering these issues....
> 
> ---Assume URL encoding is being used because a customer has all cookies 
> turned
> off.
> 
> 1.) Customer puts a few items in her shopping cart.
> 2.) Customer logs in to view some account details.
> 3.) Customer then sees her friend on IM and copies a product page URL to 
> her
> friend.  This URL contains her session ID.
> 4.) The friend clicks on the link and views the product page.  However, she
> now can click on "My Account" or whatever or "My Cart", and because she'll
> appear to be the first customer (she has the same session ID), she can view
> all the personal details she shouldn't be able to.
> 
> What's the best way to go here?

What about binding the session on an IP address? As I wrote the last 
time I don't like cookies (security problem if somebody does not logout 
explicitely). For link rewriting you have the problem above. So why not 
testing server side if the login for a specific session was done using 
the same IP as the current request. The friend who got the copied link 
has not a valid IP/sessionid combination - and has to login itself.

Joerg


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

Re: Need Session Help!

[Antonio Gallardo <ag...@agsoftware.dnsalias.com>]

Sonny Sukumar dijo:
>
> Hi guys,
>
> I know I've brought up some session questions before, and I gained great
>  insight from those discussions, but there's some issues I want to
> understand  better before I make implementation decisions.  Assume the
> context of a B2C  e-commerce site when considering these issues....
>
> ---Assume URL encoding is being used because a customer has all cookies
> turned
> off.
>
> 1.) Customer puts a few items in her shopping cart.
> 2.) Customer logs in to view some account details.
> 3.) Customer then sees her friend on IM and copies a product page URL to
> her friend.  This URL contains her session ID.
> 4.) The friend clicks on the link and views the product page.  However,
> she now can click on "My Account" or whatever or "My Cart", and because
> she'll appear to be the first customer (she has the same session ID),
> she can view all the personal details she shouldn't be able to.

Yep. This is the cruel true. Some systems does not allow people to LogIn
if they have not cokies enable (SquirrelMail is one of them).

> What's the best way to go here?  I'm thinking that if
> A.) a given page allows URL encoding to be used and
> B.) it contains *any* sensitive info that shouldn't be seen even if the
> URL  is
> copied and
> C.) even if the customer is already logged in
>
> then the customer should have to log in to see that page every time that
>  page
> is requested.  This seems like a hard policy to implement though (and
> tedious
> for the customer), and I don't see any support for it in the Auth
> Framework.

Auth-FW use the session-FW. If you does not give the
jsessionid=277C6FCB22B55AAF661F381AA867FC73 then the "friend" will need to
LogIn too.

Some sites allow you to post the links to friends with or without cokies,
but when you decide to checkout you need to write your password again.
This can be one solution.

> After all, if you have the session ID and the
> "authentication" context is in the session, then you're considered
> logged in.  And with URL encoding, anybody could go and view your
> account details.

Yep. For the time the session is valid.

>
> So I don't like URL encoding. :-) However, I'm worried about losing
> customers
> who don't have cookies turned on and I notice that most major e-commerce
> sites allow URL encoding.  What would you do?
>
> --Should I ever allow URL encoding during the secure checkout process?

The answer is above for URL encoding: The user must reenter the password.
>
> In theory it seems like if I'm storing a super sensitive piece of data
> like  a
> credit card number in the session, then I wouldn't want the session ID
> being so visible as it is when in the URL textbox at the top of the
> browser  window.

No, I think the session cannot have too many info. All this info must be
stored in a database and picked from there just only when you need it. It
is not fine to let credit card info "fly" into the internet with no sense.

> URLs are also often stored in web server logs and other places, and if
> it contains the session ID this can spell trouble because there's a
> "window of vulnerability".  Our session timeout is set to 4 hours, so
> that's 4 hours during which somebody could access that sensitive info.

I agree, but the window will be smaller if the user need to reenter the
password.

>
> On the other hand, if pages coming before the checkout allow URL
> encoding  and
> the checkout process doesn't, then that gives the impression that the
> site will always work even with session cookies turned off.  Then the
> customer finally finds what she wants, puts it in her cart, and heads to
> checkout--only to find that she needs to have cookies enabled!

> I'm not
> sure that's the best way to go, although it can be argued from a
> security perspective (but customers are emotional and won't consider
> technical/security aspects for a second).

I think with the increments of e-frauds they are really concerning about
this. Many people often ask me about if is secure buy in the Net. Also
they also are concerned if they can trust in the site. OK, this is just my
view of the situation.

Often some people ask me to be there when they will buy, just to be sure
all will be OK and they will not give away more info that needed.

Media are helping us in this arena. I think people is getting into the
e-commerce slowly, becuse they know, there can be problems and they dont
want to pay a bill from a e-fraud.

> --If URL encoding was being used on a previous page, and then now (say 5
> minutes later, or sometime later that still comes before the session
> times out) session cookies are enabled, would it still be possible to
> use the previously encoded session ID to access the session?  Or would
> Tomcat  destroy
> that session ID key as soon as it recognizes it can use cookies?

Dont know.

> For example, if my encoded session ID was "ABCD" (just an example!), and
> now  I
> turn on cookies so the next page I request has no more encoded session
> ID, can I still somehow use that session ID to access the session?
>
> My guess is no, but I thought I'd ask.

Good question.
>
> --I'm also pretty sure about this, but I thought I'd ask this too... :-)
>
> Just because somebody gets ahold of the session ID, there's no possible
> way for them to *actually* access the session is there?  I mean, they'd
> have to rely on requesting a page that happens to hand over that
> sensitive info stored in the session, right?

Yep. The session info is stored in the server. The session ID is just a
handler to this info.

> Again, I'm fairly sure they can't actually fetch the Java objects, or
> even read the bytes out of server memory, but it's almost a moot point
> since  pages
> are always going to exist to serve up that info.  Otherwise the info
> wouldn't
> be stored in the session in the first place. :-/
>
> Thanks for your help and insights,

Thanks for this interesting discusion.

Antonio Gallardo.




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org