Hidden fields are not more secure than parameters in the URL.
('show source' in your browser and everything is revealed...)
But they look more 'professionnal' to me, even if I admit it's purely subjective and aesthetic...

To me one way to secure a parameter would be to compute a hash (MD5,SHA1)
of the parameter, the id session, and a private value (the customer ref in your base, for example)
This way the link can't be cut and pasted later (beccause of the ID session)
And link can't be faked given an id-session
(as the private value is needed to compute the hash...)

UPDATE :
Just my 2 cents idea, Cookies would solve a lot of your troubles here,
a lot of professionnal sites use them.
And you may be surprised to see how well the customers accept this constraint
('Yes sir! your browser need to be cookie enabled to use our site.'
is a sentence that I often say and it's always ok for my customers...)
"Only Bad Coders Badly Code In Perl" (OBC2IP)

Right, hidden fields are not secure. But Hero Zzyzzx was not concerned about secure sessions (I assume he would handle that through SSL). Instead the issue is that customers can mistakenly give away a link into their session just by giving the current URL to someone else.

I don't understand how computing a hash will prohibit sessions from being transferred with URLs. Is the server or the browser going to compute the hash? If the browser, then JavaScript is required (and I believe the issue is not requiring the customer to use cookies, and possibly other optional browser features like JavaScript). If the server, then the URL is usable by any browser (which means that it can be given to others along with the hashed session ID).

I'd break my query string into parts, a session ID and a product ID. The "recommend" link would have just the product ID in the URL.

As far as preventing the SessionID from being reused (i.e. for those users that copy the URL), you can check out apache's mod_unique (IIRC, that's what it's called) which generates a unique ID for each browser session. You can use that ID to generate your session ID, and then validate the session ID on each request against Apache's unique ID. If an invalid (non-matching) sessionID comes in, you simply generate a new one and rewrite the URL (if you have mod_perl) or send a redirect (if you don't).

HTH

Philosophy can be made out of anything. Or less -- Jerry A. Fodor

How about hashing into the sessionid parameter that might be in the URL or hidden fields, not only the time (so that you can time out the session), an internal reference to the shopping cart id you store on site, but some indicator of the page that the user clicked from? You can then check the validity of the sessionid against the HTTP_REFERER field, and reissue the sessionid for the new page for all needed links. A user coming from off site with a session id will have practically nothing set in the HTTP_REFERER field, and so you can redirect him to your front page, or if properly encoded, the product field embedded in the sessionid.

I'm not sure how well this would work with proxies or other aspects, but it shouldn't require any access to apache itself...

This is an intriguing idea. The only thing I'm leery on is what happens to HTTP_REFERER when the user clicks a back button? If you encode a valid HTTP_REFERER into the URL, and the user clicks back, the HTTP_REFERER in the URL probably wouldn't match the HTTP_REFERER in %ENV hash.

Am I missing something here with this system?

When the user clicks on the back button, most browsers that I know of do not attempt to reget the page, but use the version from the browser's cache, which means they'll see the page as if they never moved from it in the first place. But you do have to consider the few oddball browsers, as well as some that send HTTP_REFERERs when the URL is entered manually or from bookmarks, as well as ones that don't send HTTP referers at all.

As was discussed in the CB, you've got to decide for yourself how much inconvience do you want to give the customer for a possibility of a malicious cracker to modify the cart prior to them entering the secure part of the site, vs whatever secure that you lose by running the storefront without cookies or SSL or other Apache-based features. Since the worst that the cracker can appear to do is run up a lot of items on the shopping list, you simple need to make sure that in the secure area, the user has the ability to review the shopping list and delete items he/she does not want at that time.

If you do that, then all you need simply for handling the 'refering' of a product to the second user is a time out on the sessionid of 5 or so minutes, with the sessionid being refreshed with a new time out every time it is successfully accessed.

---

Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain

Beatnik:

I don't think your solution would work (though it's one I considered) for AOL users, who I'd still like to be able to sell to. Have you ever looked at the access logs from AOL users? AOL does some screwy things with IPs. You can't rely on an IP from AOL.

This would also flame out in the case of shared computers, like at a university or corporation. If a user accessed my site and added/edited their shopping cart, their cart would still be available to the next user if they didn't log out or close the browser, if you used the IP for verification.

IP stuff will also fail on load balancing proxies...

I can't speak for all schools but in my school they have logins for each student, making somewhat impossible to browse on someone else's account...
I doubt you can make it 100% foolproof :)

Greetz
Beatnik
... Quidquid perl dictum sit, altum viditur.

One more wrinkle:
This is being done on a shared host, no access to mod_perl or probably any apache features that require configuration.

So, no cookies, eh? Check to see whether the unique module is available anyway (assuming you're using Apache).

It sounds to me like all you can get to reidentify an individual is what you can get through vanilla CGI and possibly javascript, and you want security on sessions.

Good luck. You might do OK by making the session ID a combination of IP, user agent string, and any other info you can get from the user's client automatically (see a Javascript reference for that sort of thing) that might differ between different client programs (or different instance of the same client programs). I.e. if you know that if this is a different useragent OR different IP OR different (whatever), you say "sorry, but I can't verify your identity."

Nothing along these lines is going to be perfect in preventing another user 'hijacking' a session ID. (e.g. a computer lab with 25 machines all running IE 5.5 sp 1 on WinNT that access the site via NAT are all going to come out the same on all these criteria, unless there's some unique ID for each copy of the browser program, but even that's going to be vendor-dependent).

I suppose you could use the PIII's ID and an ActiveX control or some such ... =) (j/k)

If this is a real "shopping cart," I'd suggest you reconsider your hosting situation. If it's an exercise, well, nice brain teaser.

Philosophy can be made out of anything. Or less -- Jerry A. Fodor

Do not use IP. Do not use IP. Do not use IP.

IP can change from one hit to the next (think "AOL"). IP can be the same for many different users (think "AOL" or every corporate or ISP proxy).

If the answer is "IP", you've asked the wrong question. {grin}

-- Randal L. Schwartz, Perl hacker

Arturo:

You hit the nail on the head with my issues here, and why I'm somewhat stumped. This isn't an exercise, and I think probably a lot of people with minimal e-commerce sites are in my situation, though they may not be as much of a purist as I.

I may end up just going back to cookies. I do like the "store session id in form data" idea mentioned a couple of answers back, though I need to think fully through the security ramifications.

I'll report back on what I decide to do.