使用会话ID验证用户身份-这样做安全吗？

Question

I am writing a shopping cart program from scratch using PHP (Zend) and MySQL. Now I am implementing the guest shopping cart and I save the items in cart into a table in my database. Therefore each item in the table has the following fields:

item_id session_id some_other_details_fields

When a user visits the website I assign a session ID using session_start(), and if he or she adds something into cart, I insert a row into the table above.

So when users want to edit or remove something from their cart, they can do:

mydomain/cart/edit?item_id=XXX

and

mydomain/cart/delete?item_id=XXX

An obvious problem is that user can deliberately change XXX to access other's item info or remove items from other's cart. So I am thinking of adding mydomain/cart/edit?item_id=XXX&sess_id=YYY to verify if the sess_id YYY matches the session_id of item XXX in database.

I don't know if this is a good practice, and if using session ID to verify user identity would be sufficient. Any idea or reference on this would be highly appreciated.

EDIT:

1. I would like to save the items in cart for as long as possible (eg, up to 1 year) , so I use session ID stored in cookies to identify users and save their items in cart in the database to make sure it will not be lost as long as the users do not clean up their cookies. I was thinking sessions are usually used for storing user data for a shorter time, and may be less reliable than database, please let me know if this is wrong.

2. For registered users I use a separate table for their carts and use user_id to identify them. If a guest registers I will move their items from the "guest cart table" to the "registered users cart table". Rather than using sessions which might be accidentally cleaned from time to time, I'd prefer to manually clean up the "guest cart table" just for peace of mind.

3. I am new in Zend so am not quite sure how to write this using Zend classes. So I decided to use php for these stuff.

Please correct me if I the things I do above are stupid. :)

Answer 1

I can't fully understand your design. Using a database suggests permanent storage, but binding the cart to a session means that users cannot register and keep their carts.

• If cart is just session data, it should get stored right into $_SESSION .
• If cart is permanent, the key should be the user_id .
• If you want a session cart that optionally gets saved into database when user registers, you can either use both approaches or go for database only. If you choose the latter, user_id would be optional and $_SESSION would contain cart_id .

Additionally, transmitting the session ID in the URL (the default behaviour in earlier PHP versions) proved to be a wrong idea: it's too easy to give away your session data inadvertently (eg by just sending a link to a friend).

To sum up: there's normally no need to use the session ID.

---

I've just noticed your edit:

I would like to save the items in cart for as long as possible (eg, up to 1 year), so I use session ID stored in cookies to identify users and save their items in cart in the database to make sure it will not be lost as long as the users do not clean up their cookies.

So the shopping cart has actually nothing to do with the PHP session. Using the session ID as cart identifier unnecessarily links the whole session feature with your database cart and adds a lot of extra hassle for no benefit:

• You need to change the default session settings so session cookies persists across browser restarts.

• You increase the risk of session hijacking by reusing the same ID for months.

Are you sure you don't really mean cookie rather than session ? It's just fine to generate a very long random alphanumeric identifier, store it into a cookie, and use it as secondary key for the database table.

---

Followup questions

In terms of safety, would it be sufficient to generate just one long alphanumeric "GUID" for each guest and use that "GUID" to verify the identity when he or she comes back?

It doesn't need to global (the G in GUID) but I suppose it won't hurt. But you need to define "sufficient". Binding data to an IP address or User-Agent string makes it harder for attackers to gain access and makes it easier to user to lose his data. Using HTTPS-only makes it more secure you need to use HTTPS everywhere.

To avoid "GUID" conflicts, is there a good point to start? I used session ID just because it will generate a "GUID" for me.

Sorry but the session ID is not a GUID: it's just a cryptographic hash with a random seed. But please think about it: it's extremely difficult to win a lottery that sells numbers from 00000 to 99999 (that's 1/100000 chances). If you generate a 32-character string with digits and 26 English letters you have 1 / 36^32 = 1.5787740357426709877210×10 ^-50 .

For my case when shall I use sessions (as a best practice)? I'm kinda lost if this is not a good scenario to use sessions. Many thanks!

You're possibly using sessions already for user sign-in or order payment, for a pretty good reason: since HTTP is a stateless protocol, there's no other way to do it. Why is it so important to store the cart in session at any cost? ;-)

Answer 2

Others told you to just use session, and generally this is the right way to do it. However, if you want a dual system "you can make an account, but you're not forced to do so", I see why you'd want to use a database (a single cart-saving system for both types of users, with the permanence needed by the registered ones).

So, if I understood your intention right, you want purchases in a database, related to the user ID. However, when the user chooses not to register and/or log in, you have a problem. In this case, I'd suggest saving some temporary user ID in a session, along with some flag (ie $_SESSION["realUser"] = false; ) and using it as if it were real. To avoid conflicts, those temporary names should be unique. For example, they can start with a space character, which I assume is not allowed for the regular user IDs. Alternatively, you can use the pair of variables $userId, $realUser as a user identifier, and in that case $userId can be the same as the session ID.

However, carts connected to these temporary IDs will not last you a year. Once the session is deleted, the user will have no way to access that data. So, this data can be pruned after a much shorter period of time, while the data related to the regular users doesn't have to be pruned at all (so, they can find their cart even after a decade, although doing so doesn't make much sense to me).

If I understood you wrong and you don't want to mix registered users with the unregistered ones, just put all the data in the session and forget about databases for this, as others have suggested.