php session hacking and preventation tips

The term "session" is overloaded to mean different things on the server and in the browser. Browser sessions are at best tenuously connected to server sessions. "Session hijacking" refers to server sessions.
Server-side, a session has an ID (which is passed between the client and server), content (stored on the server) and potentially other properties, such as last access time. The session ID is usually passed as a cookie. In PHP the default name for the cookie is "PHPSESSID". If cookies aren't available, PHP will (optionally) use a query string parameter of the same name ("PHPSESSID"). This cookie (or query param) can easily be changed and therefore the session identifier can be changed too.
The contents of a session (i.e. containing the login state of a user) cannot be changed by the client, the data is stored on the server and can only be changed by a PHP script on that server. Note that in a shared-hosting environment (shared by other services or users), the sessions can be overwritten if using the default session storage directory (/tmp). To protect against that, either use a database through session_set_save_handler() or set a custom session directory using session.save_path with the proper directory permissions set (preferably 700 which means that only the owner (the PHP user) can read and write to it).
To protect against session hijacking, you must have other ways to identify the user against a session. This can be a user agent, IP address or another cookie. The previously mentioned methods are just workarounds, best way to protect against stealing of the session cookie is by using HTTPS if a session is involved. Do not forget to set the httponly flag to true using session_set_cookie_params()
Client-side, "session" is again overloaded and used in various contexts (e.g. session managers, which restore open pages when a browser is opened, session cookies and sessionStorage). We can try to combine these meanings (into what is by no means a standard one) by saying a browser session consists of a collection of views and their associated data. (By "view" I mean roughly tabs in tabbed browsers and windows in non-tabbed browsers; the DOM window object exposes a view to JS.) Each view has a history, a current page and page data. Page data for pages in the same domain is shared between views in a session; if two pages are in different domains or different sessions, they don't share data. Exiting the browser closes all open session(s), possibly saving part of the session(s) (e.g. histories, current pages, sessionStorage) so that a session manager can re-open them. Session cookies are cookies that are discarded when a session is closed; in other words, session cookies are non-persistant. Though a session cookie may hold a session ID, the two concepts are orthogonal (sense 4; session cookies can hold things other than session IDs, and session IDs can be stored in persistant cookies).
Whether two different views are in the same collection depends on the browser. For example, one browser may consider a session to consist of all tabs within a single window; separate windows are separate sessions. IE8 lets users create new sessions via the "New session" menu item. Otherwise, new windows and tabs are opened in the same session. Privacy modes also create new sessions.
In summary, browser sessions are indeed set by the browser, though it provides users various means of controlling browser sessions: creating new sessions, changing the history and current page in a view by browsing, saving and restoring sessions. A user could even change session data by editing sessions saved on disk, though this isn't a feature afforded by the browser. None of this has anything to do with session hijacking. Server sessions are created and managed by the server, but users can (attempt to) switch server sessions by changing the session ID their browser passes back to the server, which is the basis for session hijacking.

session hack prevent tip 

Unfortunately, there is no effective way to unmistakably identify a request that originates from an attacker in opposite to a genuine request. Because most properties that counter measures check like the IP address or user agent characteristics are either not reliable (IP address might change among multiple requests) or can be forged easily (e. g. User-Agent request header) and thus can yield unwanted false positives (i. e. genuine user switched IP address) or false negatives (i. e. attacker was able to successfully forge request with same User-Agent).
That’s why the best method to prevent session hijacking is to make sure an attacker cannot find out another user’s session ID. This means you should design your application and its session management that (1) an attacker cannot guess a valid session ID by using enough entropy, and (2) that there is no other way for an attacker to obtain a valid session ID by known attacks/vulerabilities like sniffing the network communication, Cross-Site Scripting, leakage through Referer, etc.
That said, you should:

• use enough random input for generating the session ID (see session.entropy_file, session.entropy_length, and session.hash_function)
• use HTTPS to protect the session ID during transmission
• store the session ID in a cookie and not in the URL to avoid leakage though Referer (see session.use_only_cookies)
• set the cookie with the HttpOnly and Secure attributes to forbid access via JavaScript (in case of XSS vulnerabilities) and to forbid transmission via insecure channel (see session.cookie_httponly and session.cookie_secure)

Besides that, you should also regenerate the session ID while invalidating the old one (see session_regenerate_id function) after certain session state changes (e. g. confirmation of authenticity after login or change of authorization/privileges) and you can additionally do this periodically to reduce the time span for a successful session hijacking attack.