[SOLVED] Preventing Session ID's from leaking

[leesiulung]

Igor, I apologize. I don't think I'm being specific enough.

 

What I meant to say is how do one implement session handling in code (i.e. session_start()) if one want to store credit card numbers in the database. I realize there are database permissions and issues one should set for that too, but my discussion focuses on the code for handling sessions to prevent leakage.

 

I'm not discussing storing credit card numbers in sessions, although I don't see a problem with this unless sessions aren't stored in memory and session id is leaked somehow. I agree that it is probably not advisable to store cc# in sessions although I merit it needs some investigation.

 

I hope I am being clear enough.

 

Thanks,

[igor berger]

You do not need sessions to get credit card information from user, just use SSL

You need session to track users movement from one page to another.

 

For example, if you make a user login to a page then they go to another page only that user will be able to go to that page's session.....but you will need to run some sort of test to make sure that this user is the one who comes from the other page.

 

You really need to search in Google session... and read up more about and how it works, when it is used, and for what purpess.

[neel_basu]

sessions are used just to store some quick Informations . If you are using Sessions in such a broad purpouse then whats for that database why you are using database then ??

you should store User's Informations like name, age , sex , last Visit, last Purchase date, last Page visited, last Comment on date, etc.. etc.... in Sessions you should not store such a sencetive information like Credit card info on Sessions.

Store those Informations in database and never bring it to Sessions.

Isn't it better not to leave any security hole rather than blocking that security hole ??

[neel_basu]

Store such Informations in Sessions that doesn't matter if it gets licked.

And I dont think that you need users credit card number to Sessions to work.

[Trium918]

I believe that he is trying to hack!!!!

[leesiulung]

I believe that he is trying to hack!!!!

 

I'm tired of responding to this, but NO I'm not trying to hack. However, if I wanted to, this is not the place to find such information. I'm better of finding sites that discusses and actually have sample of code and discloses vulnerabilities I can look for. Furtheremore, there are plenty of tools freely available on the net that I can use to scan bad code.

 

To properly prevent hacking, one must understand how these breachers occur. Yet, so far I have only asked about best coding practices to avoid being an easy victim.

 

It is also interresting to note that so far on this site I have seen numerous posts about programmers asking for help regarding their hacked site. From the ones I saw, at least 1 or perhaps 2 discusses SQL injection. This is such a common thing that should be taught with whatever SQL tutorial one reads.

 

Please refrain from making unrelated comments and speculations as it makes it hard for potentially others that might benefit from this thread to wade through and get useful information.

 

I appreciate everyones response so far and please help me find an answer to this!

[utexas_pjm]

I feel like we have already answered your question.  In the most general terms you've asked how can you avoid raw HTTP data from being sniffed.  The answer is, you can't.  The best you can do is encrypt the HTTP using public key encryption (SSL).  If you don't want to encrypt the communication between the client and the server then you have to live with the fact that a determined party can hijack sessions on your site.  Amazon encrypts the communication of credit card numbers via SSL.  It does NOT force HTTPS on every page because the credit card number is not in the session.  If the session is hijacked the hijacker has only gained access to your Amazon account information.  If the hijacker wishes to make a purchase they still must enter credit card information and again submit that information via an encrypted protocol.  Please explain, in light of what I've just said, what your security concern is.

 

Best,

 

Patrick

[per1os]

You ask the same question but do not seem to get a direct answer.

 

Let me ask you this, do you know how sessions are leaked? Do you know how they are instantiated if leaked?

 

The best offense to this "session" hijacking is to make sure that your sessions timeout in a timely manner like 15 minutes with no activity from the user.

 

Usually 15 minutes is not enough time for a hacker to grab a session id, instantiate it and run through the site using it. Have you had the session id's hijacked before? I know I never have but a way to prevent a hijacking is to have checks on sessions at the start of a page, make sure that the IP is the same as it originally was, store a version of the ip in the session. Also store some other identifiying information from the user side, maybe the browser version they were using and os version.

 

This way if the os version is different than you obviously have a problem. If the IP is different it may be a dialup connection, but generally is a problem and I am sure a user would rather be logged out and have to log back in instead of having information hi-jacked.

 

Anyhow hope that sheds some light on the situation.

[leesiulung]

I feel like we have already answered your question. In the most general terms you've asked how can you avoid raw HTTP data from being sniffed. The answer is, you can't. The best you can do is encrypt the HTTP using public key encryption (SSL). If you don't want to encrypt the communication between the client and the server then you have to live with the fact that a determined party can hijack sessions on your site. Amazon encrypts the communication of credit card numbers via SSL. It does NOT force HTTPS on every page because the credit card number is not in the session. If the session is hijacked the hijacker has only gained access to your Amazon account information. If the hijacker wishes to make a purchase they still must enter credit card information and again submit that information via an encrypted protocol. Please explain, in light of what I've just said, what your security concern is.

 

Best,

 

Patrick

 

I actually tested this, by adding an item to my cart and logging in and proceed to almost checkout. Then assuming the session id is still available I went to the main page from the same browsing session. It asked me to log in again when trying to checkout. However, if there is a valid non-expired credit card on file it will allow you to re-use that card again by selecting a radio button. Not sure how amazon figured that out, other than keeping track of what pages I was on....

 

You ask the same question but do not seem to get a direct answer.

 

Let me ask you this, do you know how sessions are leaked? Do you know how they are instantiated if leaked?

 

The best offense to this "session" hijacking is to make sure that your sessions timeout in a timely manner like 15 minutes with no activity from the user.

 

Usually 15 minutes is not enough time for a hacker to grab a session id, instantiate it and run through the site using it. Have you had the session id's hijacked before? I know I never have but a way to prevent a hijacking is to have checks on sessions at the start of a page, make sure that the IP is the same as it originally was, store a version of the ip in the session. Also store some other identifiying information from the user side, maybe the browser version they were using and os version.

 

This way if the os version is different than you obviously have a problem. If the IP is different it may be a dialup connection, but generally is a problem and I am sure a user would rather be logged out and have to log back in instead of having information hi-jacked.

 

Anyhow hope that sheds some light on the situation.

 

In the course of research I just found this: http://forums.devnetwork.net/viewtopic.php?t=34468

It basically discuss much of the same information you gave me.

 

I have never had a session hijacked and the likelyhood is very small. However, I'm paranoid enough to try to find an answer. I have never tried to hijack a session myself and do not know the details. As far as I know, all one need in many cases to hijack a session is to sniff it while it is being transmitted as part of the request header or when it is first transmitted to the user from server (unless session id is user generated). Thus all you need to do is craft the right request with the cookie id...

 

However, a method described on wikipedia on the topic of 'session fixation' involves generating a new session id on each request, might be closer to the answer (albeit a little complicated). There seems to be no fool proof way, unless you use SSL on the whole entire site. Then SSL and client side is most likely the weakest link.

 

Your answer was clear and direct. Exactly what I was looking for. However, storing ip according to the thread I posted is not a good idea.

 

I will mark this thread solved. People wanting more information can visit that thread. If I find something new I will post back here. I appreciate all the help I received in this thread!

[dsaba]

correct me if i'm wrong but all that is being passed to the visitor's pc is the SESSION ID

 

so even if someone can sniff sessions, they can only sniff information that is being passed from the visitor's pc to the server, all that is being passed is the session id

 

the actual session information (passwords, credit cards #s)

that is being stored on the server, which no one can sniff?

is that correct?

[igor berger]

One problem may arise from using sessions, is session validation flag can be sniffed!

 

But of course, there is contra measure to this. Check to make sure, that all your pages are host referrer validated.

For additional security, IP consistency validated, although this may create problems with dial up connection. Once a dial up connection is disconnected and reconnected, a new IP will be assigned, from an available ISP IP poll.

 

The level of security and validation will depend on the sensitivity level of the data.