What are the risks in storing data in session?

I've heard of cross-site scripting and that people can access cookies and devious ways. So I was hoping that someone could answer a few questions around these. I want to take the example of storing something in session the purest way, but using a CMS like Drupal. Let's say we have this:

$data = $fancyWebService->getSuperSecureDataThatOnlyTheCurrentlyLoggedInUserCanSee();
$_SESSION['basic_variable'] = $data;

1. Should the user now travel from mysite.com, to devious-site.com, is there any way that someone can get the data from "basic_variable", just by knowing that the variable is called that?
2. Is there any way that the current user can see a print out of the $_SERVER variable and actually see all the contents stored in it?
3. I read somewhere that data in the session or in cookies should be "encrypted". In the above example, I'm fairly sure the data is being stored in the session, and that this session is secure. Is this the case, or is it only secure if HTTPS is enabled?
4. Drupal stores some info in cookies, if you choose to use cookies as apposed to "session", how does that affect the above?


**UPDATE**

With regards to question 2. I mean, if I type the following in a php file:

print '<pre>';
print_r($_SESSION);
die();

(or just vardump the session variable)...

I end up with all the info I have stored there, unencrypted. My question is, is there any way a user can somehow find a way to get access to the session variable (other than through me exposing it) that would make it a bad idea to leave values unencrypted?

Cookies are only accessible by the stored domain of where the cookie came from. hijacking depends on networking.

User grom has a great answer here that mentions ways to help secure your session in PHP:

[To see links please register here]

I'd like to start off by saying that PHP, especially 5.x.x versions, have come a long way in security; however, there are still many potential things that can happen to your session data, as it is constantly passed between your server and the client. Let's tackle your 4 points individually:

> 'Should the user now travel from mysite.com, to devious-site.com, is
> there any way that someone can get the data from "basic_variable",
> just by knowing that the variable is called that?'

Inherently, no. Your variables and variable names are stored on your server, and because the code is processed into an HTML view before being sent to the client, your PHP code never reaches the client. Data stored in variables that are otherwise not passed to the client are *safe* on your server, granted someone doesn't gain access to your server or in some manner compromises your server's security. If your data in the given variable is stored in a session or cookie that is transferred over the wire/network to the client, it has the potential of being intercepted. This traffic is unencrypted by default, unless you have implemented OpenSSH via an SSL certificate or similar encryption scheme.

> 'Is there any way that the current user can see a print out of the
> $_SERVER variable and actually see all the contents stored in it?'

If you 'echo' it, or otherwise program your PHP to expose the data stored in it. Again, if the variable is ever put somewhere where it is sent to the client and not processed into HTML or otherwise disposed of before an HTTP response is sent, it is at risk.

> 'I read somewhere that data in the session or in cookies should be
> "encrypted". In the above example, I'm fairly sure the data is being
> stored in the session, and that this session is secure. Is this the
> case, or is it only secure if HTTPS is enabled?'

Yes, HTTPS must be enabled, and you must have an SSL certificate to encrypt the data, otherwise everything in your unencrypted HTTP requests/response are subject to sniffing, cross-site scripting attacks, domain forging, redirection attacks, and the list goes on. SSL definitely helps prevent much of this.

> 'Drupal stores some info in cookies, if you choose to use cookies as
> apposed to "session", how does that affect the above?'

Cookies are stored on a user's machine. The data in the cookies can be encrypted or hashed by your server so that it is safely stored clientside, but anything is possible. If a potential hacker forges your domain, they gain access to the cookies and everything in it. If the cookie links to an active session, they have just spoofed their identity and gained access to your site with the victim's session. Poof. Identity theft, malicious editing of user content, etc. Drupal definitely has been around long enough to have mechanisms in place to help prevent this; however, I am not a Drupal expert.

Hopefully that sheds some light. Best practices IMO, do not store sensitive data in the session! If you are storing identifying information in your cookies, make sure you have some type of implementation to prevent cross-site forging, e.g. in ASP.NET MVC I utilize an Anti-Forgery token that is offered in the framework. You want a way to insure the person claiming to be who they are via cookie has another way to verify the request with said cookie originated FROM YOUR SITE/DOMAIN, and not another one.

Session id is stored in clients cookie, and no other domain can access cookie of other domain, and same two servers (two websites) can not see each other`s session (until you are storing that in shared server)

1: With general approach it is impossible ,, but there is a way- To make your session available across various website you have to store session on common server and have to Transfer your session ids per GET/POST vars .
Write your own session_save_handler and store the sessions in a database. The database can be accessed from multiple web servers , and you are done.

2: Question is not clear.

3: Yes https can secure you from session hijacking.

4: Question is bit unclear, follow this url to get the difference/ Relevant between session & cookie

[To see links please register here]

Yes, you can store data in a session.However, you have to minimise the vulnerable
data and store only minimal info so that you can identify the user for example,
by id number, eventually it will work. Overall, using session data is not
recommended.