shopping cart security and the back button?! HELP!

[acidbox]

I am trying to build a shopping cart and am stuck with a security issue. Maybe someone has some insight on this.

Basically, when a customer is checking out with the PHP script I am building, they are passing a lot of sensitive data (ie: credit card information, etc..).

To me, it is obvious that I would want to use $_POST vars to pass this information when they submit the form and I prepare to store the information in the database.

The problem is that I want the customer to be able to use the back button on their browser to get back to previous steps in the process. This is a usability issue that I think is natural for people to want to use the browser back button instead of a form button on your site to go to the previous step.

I do know that I can use $GET to pass data and that the back button will then be available, but I am a bit concerned because $GET is hardly secure, and with a checkout process involving money, I think security should supercede all.

My question is, how can I use $_POST for processing my form variables in my checkout script so that the process is secure, but also allow the back button the be available to the customer to get to previous pages?

I have read some custom hacks about adding some headers to the page which will disable cache, but I tried them and they didn't seem to work.

If anyone has any insight on how I can accomplish this, that would be excellent.

Thanks in advance!

[jonzy]

Maybe assign the form entries to session variables and test to see if these variables are empty or not on each checkout page. If they have contents, enter the contents into the form, and for credit card info, replace the numbers in the variables with X's (except for the last 4 digits). Just a thought... 😃

[acidbox]

anyone else have any insight on this?

[Chris_Evans]

Sessions should work fine... but remember to store them in the database - perhaps using md5 so that you can check that the variables are the same as what they were before... i.e. if all is successful, the md5 hash should match that way you know that no values were altered.

Chris.

[Chris_Evans]

Sorry, slight difference. No need to store the sessions themselves in the database (unless on a shared server) but what i mean is to share the values that the user submits in the database, so you can check the session values for the form against the database values for the form. 🙂