Jump to content
SaranacLake

Securing 'hidden' form values

Recommended Posts

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?

 

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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!

 

Share this post


Link to post
Share on other sites

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.

 

Share this post


Link to post
Share on other sites

@kickin

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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...

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×

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.