Is this dangerous for storing the user_id in the session?

When the user is login success, I will have a user_id to access to the session. But the question is can the user/hacker enable to modify, after I assigned? Because the user_id I will use to query and insert db and use th开发者_如何学运维is user_id to do all the query. If this is dangerous and not security, what else can I do? Thank you.

When you say that you will have a "user_id to access the session", it sounds like you are really talking about a session ID, not a user ID. Basically this is a cookie that you set upon successful login, and the server uses the cookie to look up the right session.

Beware: session hijacking. Using a session ID is a pretty standard scheme (though it's usually called session ID, not user ID), but it really depends how it is implemented. In general you want the app server to handle this for you automatically, rather than having to code it up yourself, because there are more and less secure ways to do it. If the session IDs are guessable, for example, then your app is vulnerable to so-called session hijacking. Obviously you don't want the IDs to be a sequence, but that's not all. You want them to be random, you want them not to have patterns (not always easy to see--but there are tools to determine whether there are patterns), you want there to be sufficiently many bits at play when generating the session ID, etc. Usually this is stuff that app developers would delegate to the supporting infrastructure.

Beware: session fixation. One other risk is session fixation. There are different varieties, but the basic concept is that the attacker tricks somebody into clicking on a link with a known session ID (which can be done when the session ID is passed along in the URL instead of using a cookie). He may for example post the link in a public forum, then the victim clicks on it and subsequently authenticates the session. Now the attacker can take over the session and he's authenticated to boot. One countermeasure is to make sure that the app generates a new session ID when it receives an unrecognized session ID from the client, as opposed to simply accepting the unrecognized session ID and starting a new session with it. If you are using a standard mechanism for generating session IDs then there's a good chance (though no guarantee--look at your documentation) that it already provides this countermeasure, as least as a configuration option. If you write your own then it's something that a nonexpert would almost certainly overlook.

Identifying session and user IDs leads to session hijacking. One other thing. If you are using a single ID to do double-duty as a session ID and a user ID--don't do that. First, sessions and users are conceptually different things (a session has an associated user, but it isn't the same thing as the user), so from a pure modeling perspective, it's not correct. But more importantly, user IDs usually aren't a secret, and they show up in things like URLs (which users can see). Session IDs on the other hand are definitely secret. So if for example every time I log into your app you send me a cookie that says "user_id=14" then all somebody has to do is go look at your app, notice that I'm user 14, and then periodically try to pass a "user_id=14" cookie to your app. Sooner or later they'll do that at the same time that I'm actually logged in, and voila, session hijack.

There are a lot of places you could take that, but on the surface. It sounds fine. Many sites store the user id in the cookies or session object. You just have to make sure you follow best practice to ensure this is not taken advantage of.

If you are very conserned you could always encrypt it.

Des