Security (and sessions) Question..

laeelin

Currently my setup saves no personal information in the session, but i'm going to be adding a shopping cart.

Useing my current setup it would be super easy to just save the shipping and billing information in the session.

Howere I'm worried about doing that because I know that there are security problems with sessions.. but I dont kown exactly what they are.

If i store (for example) a cerdit card number, It's my job to make sure that no one has access to that information, and I dont want ot make any mistakes.

So, I have question:

Is the security problem with sessions the fact that if someone "hijacks" a session they can see the information that we have already approved the visitor to see? (aka: hijacker can see the entered shipping/billing information that is displayed on the page) OR is the problem that they can access everything saved in the session (i assume it's the first, but need to know for sure)?

If it's the first way, then I can just not show the CC information anywhere.. and just encode it for saveing in the database when the order is saved.

If it's the second way, then I can not use the session variable for storeing this information at all.

ps: Anyone kown of a good place for me to learn more about website security?

Thanks
Laelein

AstroTeg

Session hijacking is the act of grabbing a URL used by the customer and going to it. By you going to that link, you'll be using the session of the customer and will be able to do whatever you like that a normal customer would be able to do, but you have the other customer's data (assuming they've entered it already).

Its very much like clicking on this link:

http://www.phpbuilder.com/board/newreply.php?s=&action=newreply&threadid=10265121

It should take you to a new reply page. If my session ID (assuming there was one) was up there and you managed to click the link before the session timed out, in theory you would be able to post a message as me.

That might put things in perspective.

As for credit card numbers, its been a golden rule of mine and a company I worked at to NEVER EVER NEVER save the credit card numbers ANYWHERE.

The process worked like this:

check out page (ask for CC number)
|
user clicks submit
|
- script accepts post request and validates card number for user errors
- if all ok, validate for tempering
- if all ok, send transaction info to CC processor
- if success, save results (transaction results, price, products, etc - but not CC number info) in table
|
Show user results/receipt page

If anything, save the last 4 digits of the CC number to validate the user used card X (handy with domain renewals and you forgot your user/pass combo).

If you need to rebill the customer on a monthly basis, most processors allow a "subscription" which automatically bills the customer each month.

This way, if your gear gets hacked, you don't have to worry about CC numbers getting stolen...

laeelin

The process worked like this:

check out page (ask for CC number)
|
user clicks submit
|
- script accepts post request and validates card number for user errors
- if all ok, validate for tempering
- if all ok, send transaction info to CC processor
- if success, save results (transaction results, price, products, etc - but not CC number info) in table
|
Show user results/receipt page

If anything, save the last 4 digits of the CC number to validate the user used card X (handy with domain renewals and you forgot your user/pass combo).

The problem with that is that i'm not useing live transactions.. In fact I average the order being placed 3-6 months before billing and shipping. (currently It's all handeled over the phone because there is so much involved in knowing what can be shipped to them.. (I shipp butterflies, and state permits, season, time of day, temp, ect all change what would be the best ones to ship) .. however, im working on makeing a multi step system so that I can have an automatic system (soooo much easier in the long run, so much harder right now)

This way, if your gear gets hacked, you don't have to worry about CC numbers getting stolen...

I do encrypt the CC number when it's saved in the database, short of that the only other time it's open would be in the actual session files (unless i'm missing something) ..

I will start encrypting it from the second i recieve it...

But in my situation I cant just discard the actual number.. =(

drawmack

the only thing in a session is what you put there.

Here is a simple rule of thumb that I use when it comes to putting information into a session: "When in doubt, don't!"

it is that simple.

You doubt the security of a session to hold cc information, then don't put it there.

You're worried about session highjacking, get a password everytime they access a page that displays or charges to a cc.

keith73

if you store the encrypted CC in a database then why do you need it in a session.

best not to even retrieve that card # until it is needed. Don't store it in the session.

personally, I hate it when sites save my credit card #. especially when they require that you have one stored or don't tell you they are storing it.

I would rather enter my card # every time than worry about having it stored somewhere that is accessible through a web application.

keith

laeelin

personally, I hate it when sites save my credit card #. especially when they require that you have one stored or don't tell you they are storing it.

I agree.. I hate it when a site saves my CC# and next time I place an order they fill it in.. how do they konw that it's me placeing the order again? .. it could be someone else doing it that I let use my computer...

if you store the encrypted CC in a database then why do you need it in a session.

best not to even retrieve that card # until it is needed. Don't store it in the session.

I'm thinking about storing the CC# for one page..

the enter billing information page where you enter the CC#

then when you hit "next" after entering the information it takes you to the "Finalize Order" page (that doesnt show the CC#).. you click confirm.. and then the order is placed (and saved in the D😎 ..

As things stand now, the only way I can see that the CC# is open is if someone was actually at the physical server (and everyone with access to it already has access to the CC#'s anyway)

Now, that said..

If I'm wrong.. please tell me =)

ps: Thinking about it now.. I think I might just save the CC# in the database in a table with just CC#'s ... and just save the row number in the session..
(and when i save the order, i'll jsut ave the row number for the CCtable)

leatherback

Hm.. How about thinking about it completely the other way around (I do not know how secure this is though.. )
Do not store it anywhere.

-> Send an email (Or a number of emails if you prefer) with (pieces of) the encoded CC # to your own email account. You could even use the encrypted CC info into the section seperator string in the email, which just holds all the other orderdetails. You have a backup of the order, and the CC#. If there is no clear number, no identification of it and it is hidden in the seperator string.. Who is going to know it is even there?

A thought..

laeelin

Unless someone here tells me not to, I think i'll do something like that =)

I know emails are not secure unless they are encrypted.. but that sounds secure to me...

even more so if i do something like have it sent as not just 4 diffrent numbes, but hide the numbers in other numbers..

for example "9444" could be the first number (and it's hidden by the numbers arround it, not just the fact that only part of the number is saved in that location.)
154899444590201