Hello Site-reference forums,

It's been a while since I visited last. But I need a good avdvise now. Hope you'll be able to help.

I am building a multy page form to collect contact and personal info from a user, let him/her chose from a range of offered services and finally make payment for the chosen service. The first 2 steps (#1 - personal info, #2 - info about goods) are being accomplished via normal protocol and #3 - payment form with credit card info, etc is on a secure https page with site seal. All info is being passed from page to page in "hidden" form fields.

Here are questions:

1) Is it true that non-encrypted information can be watched and even modified by the third party? If I enter my name, address and submit the form, and the next page bears this data in hidden fields - can anybody else view this info and modify it?

2) Do I have to use some sort of encryption for data passed between my form pages?

3) Is https connection used for the payment form good enough precausion or something else is needed?

4) The payment form sends info (including bank card detailes, etc) to a company staff e-mail addresses - should these e-mails be somehow encrypted as well?

Having a web designer background I am quite a newbie in online security issues and have limited knowledge of php. I would like to add MD5 encryption because seen it used in similar situations... but don't know how it works.

Please Help Any advice is highly appreciated! Thank you

Well, I'm not an expert but here goes....

If you pass information from one page to the other in hidden form fields (using GET or POST), yes, these can be seen by a third party. Look at the source (right click, view source) and you'll see the HTML hidden inputs.

Example:

<input type="hidden" name="firstname" value="Mark" />

These fields do not display on the page, but are accessible via the source.

Now, as for modifying these, anyone can build an HTML form that submits anywhere. I could build a form that submits to the same place as yours, and you'd not be the wiser.

So, worried about this? Security is a big deal, but small steps can make a world of difference.

For instance, since you are using PHP, you don't have to include hidden form fields at all. Store all of the variables and values into a session. Now that information is hidden from the user completely. PHP is a server-side language, all of its magic runs behind the scenes.

If you don't want to use sessions, you still don't have to use hidden form fields. Just make sure you pass each variable on to the next page once you populate it with the value submitted to the page by the user.

Hope this doesn't confuse you. Feel free to ask more questions, and I hope I've been helpful!

Thank you MarkCCDC,

Yes, I am a bit at loss and even don't know how to compose a correct question because it's more about strategy, not something one can answer in a short message.

MarkCCDC wrote:

Well, I'm not an expert but here goes....

If you pass information from one page to the other in hidden form fields (using GET or POST), yes, these can be seen by a third party. Look at the source (right click, view source) and you'll see the HTML hidden inputs.

Yes, I am aware of this. I am aware that I can view my own input looking at source but how anybody else can view on another computer my input? My communication with website through a form is only mine isn't it? When I log to a site-reference forum I can't see your login details?

MarkCCDC wrote:

Now, as for modifying these, anyone can build an HTML form that submits anywhere. I could build a form that submits to the same place as yours, and you'd not be the wiser.

Now again, somebody can build a form similat to mine, give it an action attribute with url of my script, But what would it do? My script strips off all unwanted characters, etc.... these precasions are at place. How can this technique be harmful? The main question what could be a scheme of other users' data theft?

I am basically concerned with the following only - are there any ways to catch users input including credit cards info. Because other risks (sql injections, etc) seem to be eliminated (I even run a security scan to check that).

MarkCCDC wrote:

For instance, since you are using PHP, you don't have to include hidden form fields at all. Store all of the variables and values into a session. Now that information is hidden from the user completely. PHP is a server-side language, all of its magic runs behind the scenes.

That's something I unfortunatelly don't know how to do. My knowledge is very limited. Are there any quick recepies?

MarkCCDC wrote:

If you don't want to use sessions, you still don't have to use hidden form fields. Just make sure you pass each variable on to the next page once you populate it with the value submitted to the page by the user.

Hope this doesn't confuse you. Feel free to ask more questions, and I hope I've been helpful!

If only I had an idea how to make it?! Would you please direct me to some tutorials (I looked for them a lot but they all were either too basic or too specific). I found a way to encrypt/decrypt hidden fields data but it doesn't seem very practical as I have 4 steps and need to re-use some of this data on intermediate pages.

Would anybody give a code example of session, how to use it or another method to pass php vars from page to page?

Thank you very much!

4) The payment form sends info (including bank card detailes, etc) to a company staff e-mail addresses - should these e-mails be somehow encrypted as well?

I use a simular system for taking payments via mals e cart. The data is sent via a form to a ssl secure server . an email is then sent confirming an order. My client then loggs on with password to download the credit card info.

perhaps this is a method that you could use

allenion wrote:

4) The payment form sends info (including bank card detailes, etc) to a company staff e-mail addresses - should these e-mails be somehow encrypted as well?

I use a simular system for taking payments via mals e cart. The data is sent via a form to a ssl secure server . an email is then sent confirming an order. My client then loggs on with password to download the credit card info.

perhaps this is a method that you could use

Thank you allenion,

I will think about it. The problem is that i don't have sufficient knowledge of what is possible on the web and what's not and what to expect These hacking stories seemed to be a scary tale but one day I found a huge chunk of spam links attached on invisible layer to HTML of my several websites. HOW??? I am sure it was a security hole on my hosting... still such cases make you feel uneasy especially accepting payments from people. You will not tell them "it was your hosting provider" if something bad happen.

The most sensitive data, payment card details is being collected on a secure page https connection, site seal. But all the previous steps (application form with user's contact details, order page with services selection) are accomplished using just normal forms (field input is being checked) and values passed in hidden fields.

At the moment I am working on introducing sessions for passing variables. Works between steps 1 and 2 (same url), doesn't pass info any further (different url). Any advice?

Thank you for attention

Tricky questions mate!

My communication with website through a form is only mine isn't it?

Yes and No.
When you hit the submit button, the data goes through alot of hands before it reaches the destination server. Hackers could be watching you computers download and/or upload stream, identify the information they want and extract it. Should they wish to, of course.

SSL is a "secure" connection. each up or download is preceeded with an encryption key before the encrypted data is sent. the browser or server (depending on which way the dat is going) then uses this key to decrypt the data.
Obviously, should a hacker be able to get hold of the right key in the right situation, SSL only serves to  double your bandwidth costs.

4) The payment form sends info (including bank card detailes, etc) to a company staff e-mail addresses - should these e-mails be somehow encrypted as well?

sending anything through email is insecure. you would do better to hold this lot in a data base and send an email telling whoever that it's been stored.
Before storing anything like this in a DB, I would look up "MCrypt". If your server can't run MCrypt, ask your host to install it. If they won't, either move hosts or go to phpclasses.org and search for "Encryption"

I would like to add MD5 encryption because seen it used in similar situations... but don't know how it works.

MD5 isn't really an encryption method, more of an obfuscation method.
Encrytion is a 2 way thing. If it can't be decrypted, it's not encryption.
MD5 is not decryptable. It simply hashes up a string by looping through an algorithm until the new string is X number of characters long. every MD5('string') results in the same output. It cannot be decrypted, so is used for storing passwords mainly. you would check for a password in a query like this:

$password = $_POST['password'];
SELECT * FROM db_table WHERE password = ''.md5($password).''

A good encoding method for passing strings around pages is php's base64 function. use like this:

$encode = base64_encode('string of text');

$decode = base64_decode($encode);

echo $decode;



// prints to screen:

string of text

notice it is Encoding, and not Encryption
Encoding uses a static, unchanging algorithm to make a string un readable by humans. it is easily decoded. i use it alot whenever I need to pass anything non-url safe through URL's or XML. it's easily decoded at the other end and you lose very little time encoding and decoding a string.

one day I found a huge chunk of spam links attached on invisible layer to HTML of my several websites. HOW??? I am sure it was a security hole on my hosting...

that is one of only 2 plausible possibilities. I won't tell you the other one (don't want to induce panic).
Not all web hosts are equal. the cheaper they are, the more likely you are to be hacked. The BIG problems arise when you join what you think is a big webhosting company but it turns out to be some spiv with a reseller account. before buying hosting, google them and run a whois on some of their websites domains. that should tell you if they own the servers or not.

griffinsbridge wrote:

Tricky questions mate!

My work day is over and I need time to diggest all the above.
But do not want to postpone my THANKs for such detailed explanation.

Thank you, griffinsbridge

HTTP/HTTPS

http is not secure and information travels un-encrypted over the internet

when you use ssl (https) your server sends the electronic equivalent of a pad-lock to the client's browser. The browser then encrypts (locks) the data before sending it over the net. Only your server has the decryption code (key).

SQL Injection

As Mark said, anyone can post data anywhere on the web, so one needs to sanitise any input that is expected

Sessions

Read the examples on http://www.php.net/manual/en/function.session-start.php - these are the easiest way to get sessions working.

What a session is - a magic cloud of data which floats around your site in cyber space with each individual user, powered by witchcraft.

what a session is not - an infallible way to track your users.

Session data is usually stored on the server in a file or in a database row with a unique name. The name of this file or row is called the "session id" and is passed from page to page on your site in the querystring or is stored on the clients' machine in a cookie. This unique identifier means the correct user gets the correct information.

variables can be stored in a session or read from a session at any point on a page after declaring session_start();

Personally, I use the database implementation by "stalker at ruun dot de"  detailed in the comments on http://uk2.php.net/manual/en/function.s … .php#60316 on 03-Jan-2006 03:25

WTF?

MarkCCDC wrote:

If you don't want to use sessions, you still don't have to use hidden form fields. Just make sure you pass each variable on to the next page once you populate it with the value submitted to the page by the user.

Mark, WTF are you talking about here?
If you don't use hidden form fields you have to use sessions (or cookies at a push) and putting it in the query string is just the same as hidden form fields - only 1 000 000 times more insecure as it takes no thought what so ever to see it, and read it

Maybe you mean updating a database with the new info on each new page, but here lies the problem - how do you know what record(s) to update without knowing who it is? (need for one hidden form field - database record id - or a session)

griffinsbridge wrote:

Tricky questions mate!

My communication with website through a form is only mine isn't it?

Yes and No.
When you hit the submit button, the data goes through alot of hands before it reaches the destination server.

OK, got it

griffinsbridge wrote:

4) The payment form sends info (including bank card detailes, etc) to a company staff e-mail addresses - should these e-mails be somehow encrypted as well?

sending anything through email is insecure. you would do better to hold this lot in a data base and send an email telling whoever that it's been stored.
Before storing anything like this in a DB, I would look up "MCrypt". If your server can't run MCrypt, ask your host to install it. If they won't, either move hosts or go to phpclasses.org and search for "Encryption"

But these e-mails go from a SSL secured page, isn't it enough?
I like the idea of database storing. Although not sure how to implement it. There are basically 2 forms.
#1 Application Form (with user contact details);
#2 Payment Form (with user contact details (again) + order details + card details)

User is asked to send his/her contact details 2 times. We need to collect them with Form #1 in case the user won't chose to pay from Form #2 (there are alternative payment methods - google checkout, paypal, etc)

So the first strategical question I have is whether I want to store in db both forms (application and payment) - and whether I can write into the same db table info from both Steps #1 and #2 - that would be perfect!

I think this has just be answered - I can add more info into a db table from each new step of the application process sending alerts to staff, correct?

griffinsbridge wrote:

I would like to add MD5 encryption because seen it used in similar situations... but don't know how it works.

MD5 isn't really an encryption method, more of an obfuscation method.
Encrytion is a 2 way thing. If it can't be decrypted, it's not encryption..

Got it just confused terminology. Will try base64 function and yes, we have MCrypt enabled on our server. Thank you for the code examples! Will try it out

griffinsbridge wrote:

one day I found a huge chunk of spam links attached on invisible layer to HTML of my several websites. HOW??? I am sure it was a security hole on my hosting...

that is one of only 2 plausible possibilities. I won't tell you the other one (don't want to induce panic).

I can survive any sad truths. What is the other possibility?

Thank you for the code examples. It's strange how little is said on the topic on the web... 99% of tutorials on sessions describe just very very basic usage. Anything I found is either for beginners or for more advanced users than me Good programming tutorials are still rare (unlike learning materials on photoshop, css, etc).

Thank you Northie for your detailed input.

HTTPS is used for gathering the most sensitive info (bank card details).
But I like the idea to encode this info and store it in a db, and make it available to company staff on a password protected page.

SQL injections is that one piece which I know relatively well. All the input is being sanitised.

A question on sessions:

// page #1



<? session_start(); 

$_SESSION ["color"] = "green"; 

$_SESSION ["fm_lastname"] = $_POST['fm_lastname']; 



// where $fm_lastname comes from a form field "fm_lastname" on the same page



// page #2

<? session_start(); 



and later in HTML code:

echo "My color".$_SESSION['color']; 

echo "<br>My name is ".$_SESSION['fm_lastname']; 

The "color" appears fine while the form input "fm_lastname" DOES NOT !!!

What's wrong?

Will read more... hard ((

Thank you!

Hello again!

Digging into this session/encoding/encryption stuff I realised how little is said about the strategy of data handling. What a newbie like me can get is - pieces of code, partial usually very basic explanations of various features and functions. But looking for info I failed to find a good description of a typical strategy as a whole thing.   

Now as I had your suggestions and read something here and there the following picture is assembling in my mind. Let's see if I am correct.

OK, this is where I am so far:
Page #1 Application Form ->
1) a session starts (session id);
2) user filles in the form; we encode data (base64) and send it to a database;
3) an alert e-mail is being sent.

Page #2 Select Services Form
1) the session is on
2) more info comes from our user into a database;
3) another alert e-mail is being sent if necessary.

Page #3 Payment SSL Secure Form
1) the session is on
2) we call some info from a database, decode it and use to populate some form fields;
2) our user fills in the form and sends it into a database;
3) another alert e-mail is being sent with a unique users ID.

#4 Finally a page for each user is being created in a secure, password protected zone. E-mail alert #3 contains a link or instruction how to open this page (contains some sort of id)

Now the question is what info can be used to identify each user? I thought of 2 variants:
1) session ID - seems more professional
2) a piece of info entered by user himself (like his passport number, or phone number) - (can be encoded) is easier for me to understand

I know it might look very basic for you... but as I said - for a newby Please say your mighty words of approval/disapproval

Thanks for help!

Seems this one slipped past me...

Northie, first things first, I was providing any option I could think of. URL Query string is what I was referring to. I should have mentioned the insecurities of using this, but it was just another option to use besides the actual:

<input type="hidden" name="blah" value="blah" />

But, that's why I didn't delve in to specifics. It's not the way I would suggest doing it, but another option if you didnt want to use HTML hidden inputs.

Secondly, m/m, glad you are making progress and that others here were helpful! I've learned much from members here, and try to pass on my knowledge when possible. I don't always explain things clearly enough, I guess, so for that I apologize.

You've come to the right place to get help with your problem. Hope you stick around!