Session id Security Question

[HardCoreMore]

Hi, I think that this is the best place for this question . So i am working in some application in Flex 3 and i need to check if user is logged in in order to upload picture with flex application. It seams that only way i can achieve this is to pass php session_id() into flex and send it back when user upload picture to check user id logged in.

 

Question is :

Does this have some security implications. For example if malicious user decompile my swf and find session_id can he do some damage to my database or server by knowing session_id()

[roopurt18]

When an attacker gains a known session id the only thing they're able to inherently do is mimic or imitate the user the session id belongs to.

 

If the session id they obtain belongs to a guest who is not logged in and can not do anything, then no harm no foul.

 

If the session id they obtain belongs to a site administrator they can do anything the site administrator can do.

 

But they don't have to decompile your flex application to obtain a session id.  The user's browser stores it in a plain text file on the users machine or passes it via the URL, both of which are easily monitored by malicious users.

[HardCoreMore]

Big thanks for reply. Can you please inform me or point me to some articles on how user can do anything when he obtains session_id(). Are there some special tools that they would use or what. What are the ways of doing harm to the server or database if one knows session_id(). Thanks again.

[gizmola]

It's not like the session_id is hard coded .. it's typically a hash value.  Someone needs to intercept or access this value, which is typically stored in a cookie. How are these attackers going to get access to this value? 

 

The answer to almost all these questions typically involves sniffing traffic, or some xss exploit where people have their cookie files dumped.  If you really need to insure that sniffing can never happen, there's an answer:  https://

 

At very least your admins can use https://, and they should also be aware that if they're using a shared computer, they shouldn't use a remember me feature.

[HardCoreMore]

I understand now. But can someone explain on concrete example or point to some articles on how one can do what administrator can if he obtain session_id. I am really not familiar with this. For example if i obtain someones session_id

what would i need to do to get privileges that session_id has. It would really help me understand php and apache security. Thanks again.

[gizmola]

So let's assume that the value of the cookie file is phpsessid.  If I can get your phpsessid value, and I alter my cookie file, when I make the next request to the site, the server will read whatever session values exist on the server for that session id. 

 

Typically people read user information and permissions into the session and store it. 

 

If I can set my cookie up to have the same hash value as you, AND there is an unexpired session on the server,  as far as the site is concerned -- I am you. 

 

I can do anything you could do, and anything I do will look to the site as if you did it. 

 

There is nothing magical about it -- the session id is the thing that gets passed in each request (again typically as a cookie), and is used to read session values from the server back into the $_SESSION superglobal. 

 

Those are the basic moving parts.  *If* I can get access to a valid session ID I can have my browser impersonate you, but this is by no means a trivial task. 

 

 

[HardCoreMore]

I see now. So is https only secure way and on all non https transactions i can read the hash because is passed in each request. And when you said that is not a trivial task did you mean on getting the session_id or setting your  browser to impersonate that session_id once you get it. Is it than using $_SESSION in non https transactions unsafe or there is special way of care when dealing with sessions for security reasons. I am sorry if i ask too much but this things are not really clear to me. Thanks a bunch for answers it really helped me understand things about sessions.

[gizmola]

https is the only way to insure the data can't be sniffed.  This gets into networking, but for the most part people can't sniff data because they are on a switch and have no visibility to data on the network.  A common exception to this rule would be wifi hotspots and places where you have a hub or a shared workstation.  If I go into an internet cafe, jump on a computer and login to a site, if i don't know what I'm doing there's a possibility that a cookie will be left around.  By default most sites implement a session cookie which is deleted as soon as the browser closes.  If however, I leave and don't close the browser -- well it's possible that someone goes right onto the site, and it will of course think it's me.

 

So what are some safeguards that people provide on the server side?  One you might notice is that to change the password or account email, it might prompt you for the "old password" first.  This is protection against this type of exploit, or even more commonly, the "I'm at college, I step away from my computer to get a drink and my roomate jumps on to the site and changes the password" problem.

 

As data flows across the internet, there are places where someone could get access to packets.  How important security is varies greatly.  Pretty much anytime banking, personal medical information etc., is involved then https is pretty much insisted upon.  For other things -- not so much.  The overhead of ssl is not insignificant, so everything is a value judgement.

 

Now for "guessing" a session ID, php uses by default a hash.  The particular hash they use has the property that you can't reverse engineer (decrypt) it, and you can't guess what the next hash will be given yours.  You can read the manual for more information. 

 

You do not have to use the default id.. and can change pretty much anything you want from the name of the cookie variable to the nature of the id itself, to the way sessions are stored.  If you don't like the default hash you can make a different one.  If you want to implement extra security you can -- for example, you could store the IP address in a $_SESSION variable, and if the IP address in $_SERVER['REMOTE_ADDR'] suddenly changes, you can choose to invalidate the session or require that they relog if they do anything that requires an "escalation" of privileges (for example, let em read whatever they want but don't let them actually change or add anything)..  I've seen all sorts of different approaches used.  It really depends on how paranoid you are, and how much time you want to invest in complexity.

 

Often people change the way sessions work purely to support a web cluster.  By default php stores sessions in files that are serialized and stored in the temporary directory of the server.  When you have a cluster, this is a problem, because any request might arrive at any of the different web servers in the cluster.  People often use a custom session handler that stores the sessions in a database or in memcache.  I bring this up, just to reiterate that you can change all sorts of things about basic php sessions to suit your desires/requirements.

[HardCoreMore]

Hey thanks man that was very informative for me.  But how can i get $_SESSION data once i have valid phpsessid.

 

I try like this but without result:

 

Open this script in safari for example:

 

<?php
session_start();

$_SESSION['test'] = 'My session data';
<?

 

Next i read session is from tmp folder in wamp.

 

Then i run this script in Mozilla:

 

<?php
session_start();

session_id('0ab5th9bdg3f0mu3d66ugfped5')// session_id that safari created;

print_r($_SESSION) //prints empty Array;

?>

 

What is wrong here? How to get $_SESSION data once you know phpsessid?

[gizmola]

session_id() has to be called before session_start().

[Zane]

Everything everyone has told you is far more than what I would have time to explain, but I'll try to answer you last question.  Though, please put it in regards to what gizmola has told you.

 

The session_id that you get from starting a session (or a site starting one) is stored by default.. on the server.  This means, that in order for a hijacker to grab/sniff/hijack your session_id, he/she would have to have access to that particular server that issued the hash.  Though, as roopurt mentioned... these hashes are not only stored on the server but typically stored in a COOKIE.  Notice I said typically.  This means that they are normally not in a cookie.  But if they are in a COOKIE.. the hash is stored on the client's computer.  This is how the hijacker gets the session id.  Unless of course the developer decides to pass the session id through a GET variable which is typically... not a good idea.

 

So why did your script not work?  For one.  You have to set your session id BEFORE you start the session..  Secondly, your script DID WORK.  It worked perfectly; it just didn't hijack anything like you had hoped.  If you print_r an empty session.. what would you expect it to print? .... Exactly!  Nothing at all.

 

Try setting the session_id before the session_start and see what happens

[HardCoreMore]

Yeah the session_id needed to be set first. Now i understand sessions completely finally. Thanks a bunch folks. All best