Jump to content

Recommended Posts

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.

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!

 

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.

 

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.

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

 

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).

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...

 

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.

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...

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.