Session, cookies and ids

It was suggested to me to use sessions for cross page storage, and maintain the session ID by storing it in a GET parameter or cookie.

What's the safest way to save data into a session and make it last开发者_StackOverflow forever (like login informations)?

Sessions are a standard feature in PHP. Start from this page to read some detail about how sessions are handled in PHP. Anyway, be aware that even session aren't 100% safe. There are a number of security concerns even about sessions (you can read something about session security, Session Fixation, Session Poisoning to understand the security implications of sessions).

Not sure I entirely understand your question, but you may be mixing up two things. The sid GET parameter is used as a fallback session ID when cookies are disabled. Both the GET parameter and the cookie do the same thing, but storing the session ID in the cookie doesn't clutter the URL, which is why this is the preferred method.

When you store session data using $_SESSION in PHP, the data gets stored only internally. It is not transmitted to the user's browser. Only the cookie (or sid) containing the session ID ever leaves the server.

The main difference between a cookie and a session is that the session data is stored on the server side while the cookie data is stored on the client side. But as sending sensitive data between server and client implies significant security concerns (data tampering, eavesdropping, etc.), the data should rather be stored on the server side.

But to associate a client with a session you need some kind of identifier. That’s where the session ID comes into use. Because since the HTTP is stateless (i.e. each request is an independent transaction that is unrelated to any previous request), there is no native way to identify a client just by its requests.

So instead of storing the data in a cookie on client side and have it sent back with every request, you just store the session ID on the client side and have it sent back with every request. That is way more secure as sensitive data is not being sent over the wire. All that is sent is the session ID (here you can use either the URL or a cookie as well).

But now as the session ID is the only information to associate a client to a session, it’s the session ID that has become some kind of sensitive data that needs to be protected. Here you need some kind of session authentication and management to avoid attacks on the session.

Imagine a community, users post links and external images.

To keep the session alive the page makes use of GET instead of cookies.

So: a user watches an external image or clicks on a external link. The owner of the external ressource will now be able to read the REFERER, and by this he can see the session-ID and hijack the session.

That's why most communities and similar pages put a proxy between the page and the external ressource, they strip the SESSION-ID if it is stored via GET.<edited/>