Submitting a form with product price

[SaranacLake]

I am getting ready to code my e-commerce module, and could use some helping figuring out how to submit the product price.

On the product details page, if I have a button called "Add to Cart", would I want to use a hidden HTML field to submit the "product_price"?

[benanamen]

47 minutes ago, SaranacLake said:

would I want to use a hidden HTML field to submit the "product_price"

No, it is trivial for a user to change the price submitted.

[SaranacLake]

I guess when the user chooses a product and clicks "Add to Cart" it would be better to send a "product_id" instead, right?

 

[benanamen]

That would be better. You would look up the price from the db when you need to actually do something with it.

[SaranacLake]

The only time I need to use a hidden HTML field is if I have to submit multiple values or some special value related to the form itself, rigt?

So I think I can just submit the "price_id" using the name= in the HTML form control and that will get passed with my $_POST array, right?

(Sorry, I have been away from all of this for like 4 years!!)

 

[maxxd]

Pass a product ID and quantity to the order form, then get the product price from the database and calculate the total price at that point. These fields should both be visible to the user. You can use a hidden honeypot or nonce field if you really want to, but if you're charging money I'm not sure many bots would actually pay for something at random (though I could be wrong so don't quote me on that).

The only time you should deal with the price on the server-side (other than for output purposes) is when the order is being completed - you need to make sure the user doesn't use the developer tools to change the price during the sale, but once the sale is made you need to track how much the product cost at the time of the purchase in case the price changes in the future (which it will).

[SaranacLake]

6 minutes ago, maxxd said:

Pass a product ID and quantity to the order form, then get the product price from the database and calculate the total price at that point. These fields should both be visible to the user. You can use a hidden honeypot or nonce field if you really want to, but if you're charging money I'm not sure many bots would actually pay for something at random (though I could be wrong so don't quote me on that).

I'm sorry I'm asking such newbie questions, but I have even forgotten HTML?!

As I recall, when you submit an HTML form, each field/control have a "name=" attribute, right?

So if your had a form with "First Name" and "Last name", then you'd have two fields, each with it's own "name=" right?

 

In this case, I guess I might have a text-box where the user would enter a "Quantity" so that will have a "name=", right?

And then there will be my "Add to cart" button.  Now does that have a "name=" as well where I can pass the "Product ID" or would I need to use a hidden field to help pass the "Product ID"?

(I'm not trying to decive the customer, I am just trying to recall how and where to pass the values so they show up in my $_POST array.

 

6 minutes ago, maxxd said:

The only time you should deal with the price on the server-side (other than for output purposes) is when the order is being completed - you need to make sure the user doesn't use the developer tools to change the price during the sale, but once the sale is made you need to track how much the product cost at the time of the purchase in case the price changes in the future (which it will).

Can you explain a little more how they would do that if I had a hidden "Price" field?  (Not trying to be a hacker, just to understand how hackers would take over!)

 

Also, if a user or hacker could manipulate a hidden "Price" field, then couldn't they do the same thing with the "Product ID"?

 

[maxxd]

Yes, every field has to have a name attribute for PHP to recognize it. So, yeah - it's a good point, depending on how you're pages are set up you'll probably want a hidden field to pass the product ID. My point was mostly don't pass the price for the product and assume that it hasn't been modified by the user. Which leads us to the next question:

26 minutes ago, SaranacLake said:

Can you explain a little more how they would do that if I had a hidden "Price" field?

Sure - put this on your local dev environment:

<?php
if(!empty($_POST)){
	print("<p>{$_POST['hidden_field']}</p>");
}else{
	print("<p>not set</p>");
}
?>
<!DOCTYPE html>
<html lang="en">
<head>
	<meta charset="UTF-8">
	<meta name="viewport" content="width=device-width, initial-scale=1.0">
	<title>Document</title>
</head>
<body>
	<form method="post">
		<input type="hidden" name="hidden_field" value="originally set!" />
		<input type="submit" />
	</form>
</body>
</html>

Load the script into your browser and click the submit button; see where 'not set' changes to 'originally set!'? Groovy - now, open your developer tools from the browser and select the field with the 'hidden_field' name attribute and change the value attribute on that field to 'hacked, yo!'. Now click the submit button again. Without any sort of validation or server-side checking, the form happily passes 'hacked, yo!' to the processing script, and if that script processed a product price the user could easily change it to 0.00 or less.

*edit* If they mess with the product ID.... well, honestly who cares? They'll just end up paying the correct price and getting a different product. It doesn't really help them out at all.

Edited May 7, 2020 by maxxd
typos

[SaranacLake]

@maxxd

9 minutes ago, maxxd said:

Load the script into your browser and click the submit button; see where 'not set' changes to 'originally set!'?

Groovy - now, open your developer tools from the browser and select the field with the 'hidden_field' name attribute and change the value attribute on that field to 'hacked, yo!'.

Now click the submit button again. Without any sort of validation or server-side checking, the form happily passes 'hacked, yo!' to the processing script, and if that script processed a product price the user could easily change it to 0.00 or less.

I don't have access to my dev environment right now, but it sounds like you are saying that in Firefox Developer Tools I would be able to see all of the HTML form elements in the tool?

Because if a field is "hidden" you wouldn't be able to see it on the actual form.

Is that what you are saying?

(I'll try your example later, just wanted to clarify while you are here.)

 

9 minutes ago, maxxd said:

*edit* If they mess with the product ID.... well, honestly who cares? They'll just end up paying the correct price and getting a different product. It doesn't really help them out at all.

Yeah, good point.

 

Is there a way to make it so they cannot discover things like the "product_id" in a hidden field?

Any ways to protect things better?

 

 

 

[maxxd]

7 hours ago, SaranacLake said:

Because if a field is "hidden" you wouldn't be able to see it on the actual form.

You can see and alter any of the page's html in the inspector tab of your developer tools.

7 hours ago, SaranacLake said:

Is there a way to make it so they cannot discover things like the "product_id" in a hidden field?

No.

[SaranacLake]

12 hours ago, maxxd said:

Load the script into your browser and click the submit button; see where 'not set' changes to 'originally set!'? Groovy - now, open your developer tools from the browser and select the field with the 'hidden_field' name attribute and change the value attribute on that field to 'hacked, yo!'. Now click the submit button again. Without any sort of validation or server-side checking, the form happily passes 'hacked, yo!' to the processing script, and if that script processed a product price the user could easily change it to 0.00 or less.

Just tried this out, and that is pretty cool!! 😃

So you can edit the HTML with Firefox's Developer Tools, but is there a way to fiddle with the PHP?  (Presumably not, because the PHP is on the server...)

Also, is there a way to reset the $_POST variable?

 

12 hours ago, maxxd said:

*edit* If they mess with the product ID.... well, honestly who cares? They'll just end up paying the correct price and getting a different product. It doesn't really help them out at all.

So with this hack, they can alter what information gets submitted in the form, but it's not like they can read what was submitted, right?

[benanamen]

8 minutes ago, SaranacLake said:

it's not like they can read what was submitted, right?

"They" sure can! Not only read it, but manipulate it and even send parameters that are not in your form. This is why you need a whitelist of expected/allowed fields and validation.

[kicken]

52 minutes ago, SaranacLake said:

So with this hack, they can alter what information gets submitted in the form, but it's not like they can read what was submitted, right?

If you go to the network tab of the dev tools and look at the requests it will show you exactly what was submitted by the form.  Nothing on the client side of things is safe from tampering.

I used all these tools/techniques a couple weeks ago to "hack" my way into my nieces school platform as their javascript QR code reader wasn't working and that's the only way she had to log in.  I submitted a few bad login attempts with the dev tools open to see how they were submitting the data.  After that I scanned her QR code with my phone to get the data then used the dev tools to change the data prior to submission so it was correct and get her logged in.

 

[SaranacLake]

11 minutes ago, kicken said:

If you go to the network tab of the dev tools and look at the requests it will show you exactly what was submitted by the form.  Nothing on the client side of things is safe from tampering.

I went under Firefox > Developer Tools > Network and then I clicked the "Submit Query" button on my form and Firefox shows a POST and a GET method.

Where do I go to see what was submitted?

And how would I change that?

 

11 minutes ago, kicken said:

I used all these tools/techniques a couple weeks ago to "hack" my way into my nieces school platform as their javascript QR code reader wasn't working and that's the only way she had to log in.  I submitted a few bad login attempts with the dev tools open to see how they were submitting the data.  After that I scanned her QR code with my phone to get the data then used the dev tools to change the data prior to submission so it was correct and get her logged in.

 

So where did you learn how to do that?

 

[kicken]

1 hour ago, SaranacLake said:

Where do I go to see what was submitted?

Click on the request and it will open all the details in a side panel.  One of the tabs of that panel is Params that shows the data that was submitted.  There's lots of other info in the other panels that may be useful too.

1 hour ago, SaranacLake said:

And how would I change that?

That depends a bit on how things are setup and what you want to do.   

Firefox has an Edit and Resend button you can use to craft a new request.  This just sends the request and shows the response in the dev tools, it won't cause the page to change or trigger and result processing in javascript.

If the form is a standard HTML form, just inspect it in the dom and modify the values then submit it.

In the case of the schools site, the request was done via XHR so I set a break point on XHR requests (Debugger -> XHR Breakpoints) to find where the request originated from, then set another break point before the XHR request so I could modify the variables used to generate the request.

 

1 hour ago, SaranacLake said:

So where did you learn how to do that?

No where in particular.  It's just something you learn to do after being a web developer for years.

 

[SaranacLake]

37 minutes ago, kicken said:

Click on the request and it will open all the details in a side panel.  One of the tabs of that panel is Params that shows the data that was submitted.  There's lots of other info in the other panels that may be useful too.

That depends a bit on how things are setup and what you want to do.   

Okay, I see that now, but I don't have a do/type/lastSessID/csrf key.

I just see hidden_field

 

37 minutes ago, kicken said:

Firefox has an Edit and Resend button you can use to craft a new request.  This just sends the request and shows the response in the dev tools, it won't cause the page to change or trigger and result processing in javascript.

If I change the <input value== > using the Inspector and resubmit the form, then I assume it would submit that new value to the server, right?

 

37 minutes ago, kicken said:

If the form is a standard HTML form, just inspect it in the dom and modify the values then submit it.

I looked under DOM, but there were tons of attributes and things seem to repeat several times - it was impossible to fugure out what was of value or where to change things!

 

37 minutes ago, kicken said:

In the case of the schools site, the request was done via XHR so I set a break point on XHR requests (Debugger -> XHR Breakpoints) to find where the request originated from, then set another break point before the XHR request so I could modify the variables used to generate the request.

How would I add a breakpoint and mimic what you did on your niece's school site on the code @maxxd provided?

(I know how to step though my PHP using NetBeans, but not in Firefox Dev Tools.)

 

37 minutes ago, kicken said:

No where in particular.  It's just something you learn to do after being a web developer for years.

I thought maybe you were an ethical hacker or something?

 

Also, I thought when I was poking around - forget where now - that I saw the Session ID.

What is to stop a user or hacker from screwing with that?

 

[kicken]

1 hour ago, SaranacLake said:

but I don't have a do/type/lastSessID/csrf key

Because those are the name/value pairs for the form.  Every form is going to have something different there.   The one in my image is from a XHR request that this site uses to check for new replies to a thread.

 

1 hour ago, SaranacLake said:

If I change the <input value== > using the Inspector and resubmit the form, then I assume it would submit that new value to the server, right?

Yes.

 

1 hour ago, SaranacLake said:

How would I add a breakpoint and mimic what you did on your niece's school site on the code @maxxd provided?

That example doesn't need break points, it's a simple form where you'd just modify the DOM with the inspector tool like you mentioned above.  Find the <input> tag you want to change and modify it's value attribute.

The school's website used a JS library to scan a QR code using a webcam and took then made an XHR request with the data to perform the login.  That type of situation is where you need to use break points and it's done via the Debugger tab in the XHR Breakpoints panel.  Click the  + to add one and enter some URL text to stop on.

1 hour ago, SaranacLake said:

Also, I thought when I was poking around - forget where now - that I saw the Session ID.

What is to stop a user or hacker from screwing with that?

You probably saw it in the Cookies panel.  Like everything else, there's nothing to stop someone from modifying that value to whatever they want.  Like the product ID though, it doesn't matter much if they do.   Most likely whatever they change it to would be invalid and just result in them starting a new session.  If they did happen to change it to another valid session ID then they'd inherit that session.  This is why session IDs need to be long, random and should not shared.

 

[SaranacLake]

4 minutes ago, kicken said:

Because those are the name/value pairs for the form.  Every form is going to have something different there.   The one in my image is from a XHR request that this site uses to check for new replies to a thread.

Aha.

 

4 minutes ago, kicken said:

Yes.

That example doesn't need break points, it's a simple form where you'd just modify the DOM with the inspector tool like you mentioned above.  Find the <input> tag you want to change and modify it's value attribute.

Okay.

(So if user went to an e-commerce site that just submitted the product_price to the server and had no validation (e.g. <> 0), then he/she could get a hell of a deal on something, right?)

 

4 minutes ago, kicken said:

The school's website used a JS library to scan a QR code using a webcam and took then made an XHR request with the data to perform the login.  That type of situation is where you need to use break points and it's done via the Debugger tab in the XHR Breakpoints panel.  Click the  + to add one and enter some URL text to stop on.

Okay.  Since I don't know Javascript, I guess that doesn't mean much to me right now, but hopefully some day it will?!

 

4 minutes ago, kicken said:

You probably saw it in the Cookies panel.  Like everything else, there's nothing to stop someone from modifying that value to whatever they want.  Like the product ID though, it doesn't matter much if they do.   Most likely whatever they change it to would be invalid and just result in them starting a new session.  If they did happen to change it to another valid session ID then they'd inherit that session.  This is why session IDs need to be long, random and should not shared.

So, presumably, PHP's choice of session variable length is sufficiently long to prevent that issue, right?

Are there other things you can do to protect session data?

And would using https help in any way?

 

[maxxd]

1 hour ago, SaranacLake said:

So if user went to an e-commerce site that just submitted the product_price to the server and had no validation (e.g. <> 0), then he/she could get a hell of a deal on something, right?

Yes, and that's what we've been saying since the beginning - don't pass the price from the form. Pass the product ID and use that to look up the price.

4 hours ago, kicken said:

Firefox has an Edit and Resend button you can use to craft a new request.  This just sends the request and shows the response in the dev tools, it won't cause the page to change or trigger and result processing in javascript.

Not gonna lie, I did not know that - thanks for the heads-up!

[benanamen]

1 hour ago, maxxd said:

Firefox has an Edit and Resend button you can use to craft a new request.  This just sends the request and shows the response in the dev tools, it won't cause the page to change or trigger and result processing in javascript.

That is incorrect. It does exactly what it says, it resends the request. If you modified the request, the modification is sent. You likely didn't test it properly. Test it on a request that updates a database record and see what happens.

Edited May 7, 2020 by benanamen

[kicken]

2 hours ago, benanamen said:

That is incorrect. It does exactly what it says, it resends the request. If you modified the request, the modification is sent. You likely didn't test it properly. Test it on a request that updates a database record and see what happens

You mis-understand what I mean.  Yes it sends the modified request, but that won't cause the currently displayed page to change (if you edit and re-send the document request) or trigger any javascript handlers related to the original request (if you edit and re-send an XHR request).

Using that check for notifications request as an example again, if I edit and resend that request, it won't re-show the little popup saying there is a new notification.  

Likewise with my school example, edit and re-send wouldn't trigger the code that handles a successful login.  That's why I had to use breakpoints to modify the original request rather than just edit and resend it.

 

[benanamen]

I got mixed up on who was saying what. I thought @SaranacLakesaid that regarding what he was trying to do.