[SOLVED] Preventing Session ID's from leaking

[leesiulung]

How do one prevent session id's from leaking?

 

My guess is use session_start() on secured connections (https) only, but the truth is I'm not sure.

 

Anyone venture to fill me in on this? Anyone working with login/logout type sites should pay attention to this.

[utexas_pjm]

Don't pass the session ID in the URL.  Set "session.use_only_cookies" in the php.ini.

 

Best,

 

Patrick

[leesiulung]

Let us assume I don't pass the session id in the URL. It is still possible to sniff the session id when it is being sent by the browser on each request unless is on a secured connection.

 

I guess I'm looking for someone that can explain how cookies are sent i.e. how the handshaking happens between client browser and server. Concerned about (although somewhat unlikely) sessions ids being sniffed while sent over http.

[MadTechie]

check the sessions are NOT stored in a tmp folder that is accessible via a shared folder.

[utexas_pjm]

If you're concerned with someone intercepting and reading http requests / responses, then your best bet is to use a form of public key encryption i.e., SSL.

[leesiulung]

check the sessions are NOT stored in a tmp folder that is accessible via a shared folder.

 

How do one check that the tmp folder is not accessible via a shared folder?  That is also fairly unlikely and limited to exploit due to one has to come across a shared folder with tmp folder storing session ids. Interresting thought,... never thought of that.

 

 

If you're concerned with someone intercepting and reading http requests / responses, then your best bet is to use a form of public key encryption i.e., SSL.

 

That is exactly what my concern is. I have SSL enable on the site, but how can I limit the session cookie to only be sent over SSL connection instead of forcing the user to surf the site over SSL at all times.

 

My guess is that the server only request the session id when session_start() is on the PHP script page being requested by client....

[utexas_pjm]

The web server gets the cookie form the client's HTTP request just as it gets any other data.  Force all HTTP requests to go through https so that any data sent from the client to the server will be encrypted.

 

[neel_basu]

check the sessions are NOT stored in a tmp folder that is accessible via a shared folder.

No Sessions are Stored in a tmp folder as File(s) with name "sess_SESSIONID" (with no extension) and I dont think its a shared folder.

[leesiulung]

The web server gets the cookie form the client's HTTP request just as it gets any other data. Force all HTTP requests to go through https so that any data sent from the client to the server will be encrypted.

 

 

I'm not sure I follow you on that. How can I force all HTTP request to go through https? Does that mean that the whole site has to be surfed through https?

 

I'm actually not sure how the cookie exchange process occurs between server and client. My guess is it goes as follows:

 

Client: Request a page

Server: if session_start() is on script page, request session id from client

client: sends a session id if it has one, otherwise send some default message

Server: sends the requested page based on session id

 

Can anyone confirm that? If so, I will be able to make sure all pages that has session_start() force using https.

 

I really appreciates all the help I have been getting so far. I just want to get to the bottom of this... It is an important topic.

[neel_basu]

Client: Request a page

Server: if session_start() is on script page, request session id from client

client: sends a session id if it has one, otherwise send some default message

Server: sends the requested page based on session id

I am explaining

First we used Cookies (That stores some Informations in USERS PC / Browser)

But Its NOT fair and also not secure to store 100s of informations as Cookie

So the Sessions came.

What sessions are

----------------

We keep Some more Informations about that user are saved in to the SERVER'S Computer and its stored as Files(and in that file its Written like var | val). And So as Different Sessions for Different user's Different Session's Data file for Different User's

Thats why We need to Identify each Sessions separately.

And to do that Each Session data file must have an IDENTICAL NAME.

To make the name Identical PHP makes the Session's file name ses_md5($time) as teh time is Unique teh md5 Hash will also be Unique.

And now what we need to do next is to Identify which session Is for Which User and To do that we store the md5 Hashed Part of that File (e.g. md5($time) Part) as Cookie in User's PC. and By default PHP keeps the Cookie var name as PHPSESID

When we are using session_start()

PHP is getting the Hashed part from the Cookie and adding "sess_" with that and accessing the File with that Name and And making an array Variable With name $_SESSION that contains that File's data in an array.

And after that we are using that Array.

[Guest prozente]

I'm actually not sure how the cookie exchange process occurs between server and client. My guess is it goes as follows:

 

Cookies are handled as part of the HTTP protocol. I'll give an explanation of the process starting from the browser, say a user wants to go to www.example.com

 

The user enters http://www.example.com/files.php in their browser

The browser initiates a request for the IP address from your DNS servers

Your DNS server makes a request to get the DNS record for www.example.com

This will usually be an A record, which would contain the IP address to the server, lets say the IP address is 10.10.10.10

Sometimes tho it may be a CNAME record, which will point to another domain so then another DNS request would be made for the record for the domain name referenced in the CNAME record, requests will be made until either the A record is found or none is found

Once the IP address is known by your DNS server it will send the information back to you

Now that your browser has the IP address it will create a connection to the server,

Since http was entered in the browser this tells it to connect to port 80 on the server

So the connection is made in this case to 10.10.10.10 on port 80

The browser crafts a HTTP packet by using the information from the address bar

The browser checks the stored cookies on the users computer, if there is a cookie for www.example.com that hasn't expired then the browser will add the cookie to the HTTP packet

 

A basic HTTP GET request would look like this

 

GET /files.php HTTP/1.1
Host: www.example.com

 

Now if the browser did find a cookie and lets say it was a PHP session id then the browser would add the cookie to the packet so it'd look similar to this

 

GET /files.php HTTP/1.1
Host: www.example.com
Cookie: PHPSESSID=10000100101

 

So this would be sent to the web server, the web server find the base web directory to use for the domain www.example.com from the web servers configuration

 

The web server passes the information from the client( including the cookie(s) ) to the PHP parser then the PHP parser will compile the PHP code to OPCodes then it will interpret the instructions.

 

With each request you make, if the cookie is present it will be sent with each packet.

 

Now all the information sent with HTTP is plain text, so it's possible for others to pick up the information in the packet if they are in the path the packet travels.

 

If you need this to be secure then you will want to use HTTPS as suggested. What this will do is it will use SSL to first initiate a connection to the web server, public key encryption is used so that the key used to encrypt the traffic isn't sent over the line. Once the connection is made with SSL then the HTTP packets will be encrypted so it won't be in plain text. This makes it much more complicated to view the traffic.

 

[leesiulung]

...

To make the name Identical PHP makes the Session's file name ses_md5($time) as teh time is Unique teh md5 Hash will also be Unique.

And now what we need to do next is to Identify which session Is for Which User and To do that we store the md5 Hashed Part of that File (e.g. md5($time) Part) as Cookie in User's PC. and By default PHP keeps the Cookie var name as PHPSESID

When we are using session_start()

PHP is getting the Hashed part from the Cookie and adding "sess_" with that and accessing the File with that Name and And making an array Variable With name $_SESSION that contains that File's data in an array.

And after that we are using that Array.

 

I did not know that the Session ID was created from the time and then hashed with MD5. It is unlikely, but possible that two surfers access the site on the exact same time down to the millisecond ending up with identical session names, unless the server is the one creating the session id.

 

 

...

 

GET /files.php HTTP/1.1
Host: www.example.com
Cookie: PHPSESSID=10000100101

 

So this would be sent to the web server, the web server find the base web directory to use for the domain www.example.com from the web servers configuration

 

...

 

If you need this to be secure then you will want to use HTTPS as suggested. What this will do is it will use SSL to first initiate a connection to the web server, public key encryption is used so that the key used to encrypt the traffic isn't sent over the line. Once the connection is made with SSL then the HTTP packets will be encrypted so it won't be in plain text. This makes it much more complicated to view the traffic.

 

 

Since the session id is sent with every page request and that there is only one packet (with the HTTP request information) sent when each page is requested the whole site has to be surfed on over a SSL connection. Is there any way around this? Someway to manage this?

 

To clarify during any http request, there is only two packets that go back and forth i.e. the request packet and the response packet. Is this correct? There is no server request for additional information during http connection?

 

Thanks guys, this is clarifying a lot of things though.

 

 

[neel_basu]

I did not know that the Session ID was created from the time and then hashed with MD5. It is unlikely, but possible that two surfers access the site on the exact same time down to the millisecond ending up with identical session names, unless the server is the one creating the session id.

I think it uses microtime.

It might also happen in this way -> When an user's session is being created it doesn't create another session. only after creating one session it handles another Session. there are 100s of way to do this.

[neel_basu]

and that there is only one packet (with the HTTP request information) sent

HTTP request is not Packet.

If you have used telnet or shell account before or even DOD command line

you might be familier with this.

what browser Does

-------------------

It opens a Sockets on port number 80 on http://yourdomain.com

and sends HTTP Request.

HTTP Request is something like this you opened telnet and entered a command on some port

or you opened dos and entered a dos command.

Just Like that Browser sends Some HTTP Comands (Just to make you understand easily I am using 'Commands') 1 by 1 on that port.

[igor berger]

I think this guy is a hacker wanabe!

 

Why don't you snife the packates and decrypt the SSL.

[leesiulung]

HTTP request is not Packet.

If you have used telnet or shell account before or even DOD command line

you might be familier with this.

what browser Does

-------------------

It opens a Sockets on port number 80 on http://yourdomain.com

and sends HTTP Request.

HTTP Request is something like this you opened telnet and entered a command on some port

or you opened dos and entered a dos command.

Just Like that Browser sends Some HTTP Comands (Just to make you understand easily I am using 'Commands') 1 by 1 on that port.

 

I just went with the lingo of prozente, but yes HTTP commands are irrelevant of the communication medium. Hence it can go over mutliple packets or whatever you are using including morse code. if rigged you computer to respond to that.

 

I was attempting to refer to the fact that only one message goes either way (ignoring packet transmission etc) gets sent out on each page fetch. Meaning the client crafts all the HTTP commands and sends that in one go to the webserver, once the  webserver receives the message it returns the requested data (message) in one go to the client. Next request is unaware of previous requests and there is no multiple exchanges of message between client and server in one http session. I hope that is clear enough.

 

I think this guy is a hacker wanabe!

 

Why don't you snife the packates and decrypt the SSL.

 

I'm not a hacker wannabe although I have played around with various exploits and had some fun with that. However, I have and will not conduct any illegal computer activity.

 

With that said, I think any serious programmer should spend time understanding at least two things:

 

- software engineering (or design in general)

- good programming practices

- security

 

A lot of terrible programming occurs because of lack of any or all of the above points. Beginning PHP programmers like myself probably produce very unsecure code due to the nature of PHP as a language and how it is designed. It surprises me that people aren't more interrested in security issues in using sessions as just about any site I visit this days use session cookies or at least cookies.

 

It seems like at this point the only way to prevent the session cookie from leaking is forcing the visitor to surf over https... Howver, that is not what large sites like amazon.com or ebay.com does it... also it would seem that the people designing the http specs would have thought of this blaringly obvious issue.

[igor berger]

Do not panic! Session is not where you store valuable data.

You put the data in your database.

 

[neel_basu]

Do not panic! Session is not where you store valuable data.

You put the data in your database.

 

Ya people uses sessions for storing temporarily. But those Sessions Data are not valuable as memory ist valuable as is must not be lecked it must be secured. You can use some kind of encryption in your Session.

[igor berger]

Encrypt SSL 128 or 256 bit on new browsers!

 

Banks use it.

 

If you want better protection do a lease line from one location to another!

 

Keep all your data on your private network and connect via secure fire walled VPN

 

But unless you own the medium and bounce the data via satellites and receivers, with supper computer encryption, there will always be a chance to break in and sniff and decode the packets!!!

 

But what are your sending over the NET? State secrets?

 

[leesiulung]

hmmm.... let me clarify my question.

 

How can I secure my site with SSL to protect the session id from being sniffed? The problem is that session ids are nothing more than a text string that can be picked up over the internet unless encrypted.

 

So is there a way to control the behavior of the client such as when to send and when not to send the session id to the server? I know that I need to use SSL to encrypt the session over https, but need to know how to implement the sessions properly in code.

 

 

But what are your sending over the NET? State secrets?

 

 

Just credit card information, but as mentioned before. I'm kind of paranoid, but in addition I think it is my job to secure the site properly especially if it proceses credit card numbers.

 

[igor berger]

Okay, SSL will encrypt the data, but it still can be cracked by very professional hackers.

You have nothing to worry about this, because only very few people know the technique.

And the web standards are to secure the session with SSL....so no further questioning about how to break into the session and sniff the packets.........

 

As for collecting credit card data on to your website it is not recommended, high risk, and may create problems with storing the data. Visa requires you to be certified to be able to do it, your bank were you have your merchant account will not like it, and visa requires your server to be professionally scanned for viruses by visa technicians every 3 months............

 

The way everyone does it they keep the customer, product, and other non critical data in their database, use some sort of shopping cart script, and when the customer inputs what ever in the form the page is transferred to your bank's payment gateway page where the customer will input the credit card details. No risk or foul for you!

You will need to get an internet merchant account from the bank to be able to do it!

If you are not a registered business with a regular merchant account history the bank will not open such account for you.

 

So your only option will be PayPal and PayPal credit card processing business account.

 

 

Thank you,

Have a nice day.

 

I have nothing more to add to this thread.

 

[leesiulung]

Okay, SSL will encrypt the data, but it still can be cracked by very professional hackers.

You have nothing to worry about this, because only very few people know the technique.

And the web standards are to secure the session with SSL....so no further questioning about how to break into the session and sniff the packets.........

 

....

 

Again, I'm not asking on how to break SSL or sniff packets over SSL connection . I'm asking how to ensure the cookie isn't sniffed when the user goes from a https to a http area. It is common for sites like amazon to only encrypt the transmission when checking out and not while browsing the site. Interresting thing is they don't ask for password when checking out if you are already logged in, but come in from a http connection. Amazon will just redirect you to https and continue the checkout process... How can I get this functionality and how can I avoid leaking session ids on http transmissions?

 

So you see, I'm asking how to get a functionality and security measures implemented. I'm not asking to break anything or how to sniff packets.

 

I do not store any credit card information and is well aware of the implications of storing credit card numbers. I said credit card processing. However, I might consider storing credit card numbers in sessions, but have not investigated potential issues with this.

 

With all of that said, I do appreciate your assistance so far.

[igor berger]

Never store credit card number in session....it is a no no!

 

If you want to SSL your whole website it is not advisable for SEO reasons.

 

Just do a session to track customer behavior on http and you go to to submit perssonal information page do an https the session should continue....

[leesiulung]

Never store credit card number in session....it is a no no!

 

If you want to SSL your whole website it is not advisable for SEO reasons.

 

Just do a session to track customer behavior on http and you go to to submit perssonal information page do an https the session should continue....

 

I guess since cc# aren't stored there is no real issue as the user must enter this in on the checkout page. Worst case in a session hijack is they find address, email and phone numbers. However, I'm still curious to know how one would do implement the sessions if cc# were stored. I am willing to go out and buy a book on the topic and read it if anyone have any recommendations.

[igor berger]

Why would anyone store cc in a session, they are stored in a database......

 

It is like leaving your wallet, with money sticking out, on the dash board of the car.....

 

Would you do it?