Securing 'hidden' form values

[SaranacLake]

If I store a value in a hidden form control, and then use that as a means to pass the value to another PHP script, could that cause any security issues?

 

 

[cryptichorizon]

The short answer is yes. The value of hidden form variables can easily be changed to basically anything on the client side. You can't assume that what you put there is what you going to get back.

You'll be fine if you follow good general security practices like validating the form data you receive and properly escaping values when you use them in SQL queries.

[gw1500se]

Yes, you always should validate any data coming back from a form. However, if the objective is to obscure the data from the user as well, then use some form of encryption for those fields.

[benanamen]

8 hours ago, cryptichorizon said:

....properly escaping values when you use them in SQL queries.

The current coding standard is to use Prepared Statements. There is no "escaping" done.

[SaranacLake]

Let me clarify...

I am building an ecommerce site where people can sign up for dfferent membership plans.

When I person clicks "Subscribe", I display a page containing a couple of different choices.  (Currently, Silver, Gold, Platinum)

When the user - who doesn't have an account yet - clicks on a "Select" button beneath one of the currently displayed plans, I need to capture that choice so it can ultimately be sent to my checkout.php script.

I have already decided I want a generic "Select" button beneath any plans displayed as this is a pretty common ecommerce design.  (So no radio buttons or dropdown menus.)

In order to make my design flexible, I was thinking of the following...

In my product comparison (html) table, for each plan I have a tiny sub-form like this...

	<td>
	  <form id="offer01" action="" method="post">
	    <input name="planID" type="hidden" value="mp-1111" />
	    <input name="planSelected" type="submit" value="Select" />
	  </form>
	</td>
	 
	// Repeat for however many plans are being offered
	

 

Now when the user clicks "Select", I can check IF (isset($_POST['planSelected']} and if so, then grab $_POST['planID'] and stuff it in my user session.

This will allow me to then use that planID on my checkout.php script during checkout.

 

Obviously you have to sanitize and verify all form data, but I was just wondering if the above approach poses any additional risks than I'd have with a normal form that is getting submitted (e.g. log in page, form submission)?

Hope that makes sense!

 

[kicken]

A form field is a form field, whether it's hidden or not is irrelevant.   Your user has control over it's value so you always have to validate the data.  So long as you do that and take proper precautions such as prepared statements for any queries using those values you're fine.

Just don't ever assume that because it's hidden the value can be trusted.  Ie, don't do something like

<td>
  <form id="offer01" action="" method="post">
    <input name="planID" type="hidden" value="mp-1111">
    <input name="planPrice" type="hidden" value="20">
    <input name="planSelected" type="submit" value="Select">
  </form>
</td>

And assume that someone can't change the price field because it's hidden.

 

[SaranacLake]

@kickin

I wasn't assuming it couldn't be seen or changed, just curious how it comapred to other form elements.

[ginerjm]

Seems rather complex.  Why not a single form with several radio buttons (with labels!) and one submit button.  The value of the radio buttoncan give you your needed id.

I failed to see your desire to avoid these.

[requinix]

3 hours ago, SaranacLake said:

@kickin

I wasn't assuming it couldn't be seen or changed, just curious how it comapred to other form elements.

It may not be seen, but it can very easily be changed by anyone with a casual knowledge of how webpages work.

[SaranacLake]

1 hour ago, ginerjm said:

Seems rather complex.  Why not a single form with several radio buttons (with labels!) and one submit button.  The value of the radio buttoncan give you your needed id.

I failed to see your desire to avoid these.

Because I am not building a form, I am building something like this...

 

Sample

 

[ginerjm]

Whatever that sample you linked to IS, I could not possibly have deduced that from the meager coding sample you provided that DID build a form.

[maxxd]

Look at some sites using that method (InMotion hosting comes to mind immediately). They're mostly links to pages, not buttons in a form. It seems like you're introducing quite a bit of unnecessary complexity to a fairly simple pattern. If you really wanted to, you could always just set the package to a session variable on load at the target pages from the comparison links (I hope that makes sense).

[SaranacLake]

3 hours ago, maxxd said:

Look at some sites using that method (InMotion hosting comes to mind immediately). They're mostly links to pages, not buttons in a form. It seems like you're introducing quite a bit of unnecessary complexity to a fairly simple pattern. If you really wanted to, you could always just set the package to a session variable on load at the target pages from the comparison links (I hope that makes sense).

Why am I making things complicated?

The user is on page A, then choose a membership plan in a form, and it sets a value in the session that is then used on my checkout page.

Not following you...

 

[maxxd]

It sounds like you're determined to make each package option an element of a form the sole purpose of which is to select a plan, just so you can use $_POST to get the value the user selected. My point is that you don't have to deal with form actions or button elements - just make each choice a link. Style it however you want, then pull the selection from $_GET on the target page and go from there.

It's not a huge thing, but it's slightly less typing and potential troubleshooting for you and, from a coding and semantics perspective, it makes more logical sense.

[SaranacLake]

37 minutes ago, maxxd said:

It sounds like you're determined to make each package option an element of a form the sole purpose of which is to select a plan, just so you can use $_POST to get the value the user selected. My point is that you don't have to deal with form actions or button elements - just make each choice a link. Style it however you want, then pull the selection from $_GET on the target page and go from there.

It's not a huge thing, but it's slightly less typing and potential troubleshooting for you and, from a coding and semantics perspective, it makes more logical sense.

Okay, I see what you are saying now...