use & require cookies. yahoo does. no need for url-rewriting or hidden form fields.
Hmm, Yahoo requires cookies for using their email (as does Hotmail) but not for other parts of the site. Moreover, Amazon uses URL rewriting when cookies are turned off to let one browse the site, add items to the shopping cart, and even to log in and view protected pages. As I thought however, the following problems do exist:
1.) I copied the URL to a new window and I could view my shopping cart in the new window. This indicates that the shopping cart is both visible and modifible by another person if they get a URL encoded link copied to them (I tested this).
2.) While I could log in and view my info, I had to do so for every protected page.
Overall, if Amazon isn't worried about a shopping cart being seen by someone other than the original person who added the items to it, then I guess I shouldn't be either.
don't store much in the session; use the database. we use sessions to cache >a couple things like the userID, but otherwise everything needed to process >a request is sent in the URL or in a form. this allows you to load balance >a web cluster without the overhead of session replication.
How much overhead does session replication actually cause vs. fetching everything from the database on every request? I suppose the memory, CPU, and network bandwidth overhead needs to be broken out separately and looked at in terms of $$ cost. I think memory is still the most expensive by far, so your idea to store in the db is good from that perspective, and front end caching could be used to mitigate performance problems as you said.
But how do you delete the session data persisted in the database when that session is over?
--"It also avoids the back button problem."
Hmm, I'm probably missing something trivial, but can you explain a bit storing session data in the db avoid the back button problem? Thanks. :-)
--"even more, it allows you to reorganize the order of your pages with minimal effort."
Again, could you explain this out a bit? I'm not seeing it quite yet.
all credit card data is of course encrypted with an application private key.
we also store credit card info in a separate database from the main data.
That's a good idea, although we plan to avoid storing CC data at all in the beginning. People can't steal what we don't have. :-)
all user passwords are hashed (non-reversably) as soon as they arrive and are never handled as plaintext.
Good idea--I'm also doing that.
SSL does protect the entire HTTP header, including the requested URL and any
exchanged cookies. make sure that your initial request is also over HTTPS
or else the initial setting of the session cookie may be exposed.
Ok, thanks for that info and that tip. Any insight on my question of whether the session ID stays the same when switching between URL encoding and session cookies (or vice versa)? My concern is that since URL encoding exposes the session ID in plain view, it's as good as compromised despite using SSL to encrypt it once the customer logs in.
Was that why you were saying to only use session cookies everywhere? And I guess I can't really compare everything to Amazon, since they've invested millions of $$ and years in their site that I just can't compare to at this point.
Nevertheless, I do see many other B2C e-comm sites using URL rewriting for browsing. Oh gosh, I'm torn!
to enforce cookie use, just bounce them to the login page if no cookie is sent.
For robustness, shouldn't I check for a cookie with a specific name? Also, is there some built in action to do this?
if you're using standard container-managed sessions and the
authentication framework, just set a userID in the session when the user logs in. for auth-protected resources, just check to see if that ID has been set.
Cocoon's authentication framework already does all of this, except the ID is put inside the "authentication" context, which is then stored in the session.
Other questions:
--Is it really insecure to store sensitive info (like a credit card # filled in during the checkout process) in the session? I can't see how it is any less secure to store the session in memory vs in the backend db when the weakest link in that data's protection is the session ID.
--Btw, are there any data indicating how many people surf the web with session cookies off? I'm only concerned with session cookies (which are only stored in RAM), and not "normal" cookies (which are stored on the hard drive).
From: Tim Olson <[EMAIL PROTECTED]>
use & require cookies. yahoo does. no need for url-rewriting or hidden form fields.
don't store much in the session; use the database. if you're worried about
load, use a caching technology like an EJB container. jboss 4.0 will give
you ejb-like features on any bean without the overhead of writing to the ejb
spec.
we use sessions to cache a couple things like the userID, but otherwise
everything needed to process a request is sent in the URL or in a form.
this allows you to load balance a web cluster without the overhead of
session replication. it also avoids the back button problem. even more, it
allows you to reorganize the order of your pages with minimal effort.
all credit card data is of course encrypted with an application private key.
we also store credit card info in a separate database from the main data.
all user passwords are hashed (non-reversably) as soon as they arrive and
are never handled as plaintext.
SSL does protect the entire HTTP header, including the requested URL and any
exchanged cookies. make sure that your initial request is also over HTTPS
or else the initial setting of the session cookie may be exposed.
to enforce cookie use, just bounce them to the login page if no cookie is sent. if you're using standard container-managed sessions and the authentication framework, just set a userID in the session when the user logs in. for auth-protected resources, just check to see if that ID has been set.
> From: Sonny Sukumar [mailto:[EMAIL PROTECTED] > > I would be most grateful if some of you guys could weigh in > on this. I'm > trying to implement a secure and solid sessions strategy on > an e-commerce > website, and I've tried to summarize my current understanding > below with > some additional questions, both high and low level. > > This would also be quite beneficial for everybody in the same > situation in > the future, as our discussion will be logged in the archives > for posterity. > :-) > > Thanks, > > Sonny > > >From: "Sonny Sukumar" <[EMAIL PROTECTED]> > > > >Hey all, > > > >Antonio brought up some good points (in line below) which > made me really > >think, and so the following is my current understanding of > how sessions > >should be implemented with some additional questions I > thought of along the > >way. Again, please consider my thoughts in the context of a > B2C e-commerce > >site.... > > > >--I think we agree that, although URL encoding has its > pitfalls, it is an > >option that should be provided for generally browsing the > B2C e-commerce > >website (product pages and the like) but not for viewing pages with > >sensitive information (like account detail pages and checkout pages). > > > >It should be provided for browsing because it is, in a way, > asking too much > >to force a customer to enable session cookies just to > browse, when there's > >no tangible benefit to the customer. For viewing sensitive > pages, on the > >other hand, the tangible benefit is security and ease of use. > > > >--Why ease of use? I mentioned this because I think > sufficient security > >*can* be provided for sensitive pages using URL encoding, > but it would > >require a customer to log in *every* time she requests a > protected page. > >This is because links can easily be copied to friends and by > other means, > >which exposes the session ID and hence the session, so every > single request > >must be treated like a potential Black Hat is trying to > hijack the session > >and steal precious data. This seems too tedious for anybody to bear. > > > >With a session cookie, on the other hand, the session ID > isn't going to > >wind up in web server logs, in plain text in the URL textbox > at the top of > >the browser window, getting copied to friends and posted on > discussion > >boards, etc. It is simply stored in RAM on a single > customer's computer > >and is exposed only when being sent for each request. > > > >--Granted, this is still a significant risk, as the cookie > could rather > >easily be captured if not encrypted, so an SSL connection is > in order. But > >this seems to be a moot point because the connection should > be encrypted > >anyway after logging into a protected part of the site. So the same > >encryption that protects the sensitive form/document data > being sent back > >and forth will also protect the HTTP request header > containing the cookie, > >from what I understand about SSL. (It does encrypt the whole > HTTP packet, > >right?) > > > >--Antonio also raised the issue of whether to store data > like a credit card > >number in the session, stating that it'd probably be better > stored in the > >database and fetched later. I > > > >a.) It's slow (have to go to backend server + get data from disk vs. > >reading from memory on front end server). > >b.) Since we have no way of knowing when a customer closes > her browser and > >stops shopping (terminating her session), how would we > expunge this data > >from the database in a timely manner? > >c.) Our current policy is to never store a full credit card > number in the > >database, but only the last 4 digits and this only after the > transaction is > >processed and goes through. Rather, we just store the > number in the > >session so we can later send it to the payment processor > (over another SSL > >connection) > >d.) If we're still fetching the data based upon a session > ID, it seems like > >a moot point to talk about where to store the data. Rather, > it seems the > >question of how to protect the session ID is still the crucial issue. > > > >Despite the thoughts I listed above, I'd be interested to > hear all your > >thoughts on this, as I could very well be missing things. > > > >--Another question: When switching from URL encoding to > using a session > >cookie or vice versa during the *same* session, is the same > session ID > >used? > > > >If so, then let's say a customer came to the site with > session cookies > >disabled and browsed around for awhile using URL encoding. > Say she copied > >links to a few of her friends (containing her session ID, of > course) and > >now she goes to checkout. She discovers she needs to enable session > >cookies to log in and does so. Now she goes about entering > sensitive > >personal info which is to be stored in the session. > > > >However, if her session ID is still the same as it was when > using URL > >encoding, then the SSL protection for the cookie being sent > back and forth > >is worthless. Or am I missing something here? > > > >--Using URL encoding for general browsing still exposes > one's shopping cart > >to being seen and being changed since logging in isn't > currently required > >to view/change the cart. Ideally, I'd like the cart to be > protected as > >well so each customer has a truly private experience, > whether URL encoding > >or session cookies are being used. > > > >Thoughts on what to do here? > > > >--While I think the idea of requiring session cookies > enabled to log in is > >a good one, how does one implement it? I mean, how can one > >programmatically tell if session cookies are enabled and > prohibit logging > >in if they are not? > > > >As always, I welcome everybody to share any insights they'd like to. > > > >Thanks, > > > >Sonny > > > > > >>From: "Antonio Gallardo" <[EMAIL PROTECTED]> > >>Reply-To: [EMAIL PROTECTED] > >>To: <[EMAIL PROTECTED]> > >>Subject: Re: Need Session Help! > >>Date: Wed, 24 Sep 2003 17:49:15 -0600 (CST) > >> > >>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: [EMAIL PROTECTED] > >>For additional commands, e-mail: [EMAIL PROTECTED] > >> > > > >_________________________________________________________________ > >Frustrated with dial-up? Get high-speed for as low as $29.95/month > >(depending on the local service providers in your area). > >https://broadband.msn.com > > > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > _________________________________________________________________ > Instant message in style with MSN Messenger 6.0. Download it > now FREE! > http://msnmessenger-download.com > > > --------------------------------------------------------------------- > 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]
_________________________________________________________________
Get MSN 8 Dial-up Internet Service FREE for one month. Limited time offer-- sign up now! http://join.msn.com/?page=dept/dialup
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
