Re: Re: Changing website prices based on client? (keywd: Web Software Engr)

A couple of things:

REMOTE_ADDR and REMOTE_HOST can be modified by the user. There is no guarantee that the value transmitted for these variables is correct. Therefor, these can be abused by someone attempting to gain improper discounts.
Storing an ID as a hidden on a page again leaves you open for abuse. This relates strongly to the recent rash of poorly written shopping cart systems being abused. The prices were being "hidden" in the HTML, all a would be abuser needed to do was: Save the HTML, change the price, hit the button -- Wallah! Pay $1.00 for a $100.00 item. Storing an ID for discount could be similarly abused.
Storing ID in a cookie, should be combined with sessioning to help avoid abuse. If the cookie value is indexed in such a way that it is only good for a period of time, the chance for abuse is limited. Possibly linked to IP or other identifying information as well, to make transference of the cookie ID to a different machine more problematic. This type of solution will probably lead you to have to "re-authenticate" the user periodically based on some business rules regarding latentcy and/or total visit time.

Please do not fall into the trap of believing a piece of sensitive data in a "HIDDEN" form field is secure or tamper-proof -- it simply is not, and has been abused significantly, regularly, and recently.

Comment on Re: Re: Changing website prices based on client? (keywd: Web Software Engr)

Replies are listed 'Best First'.
Re: Re: Re: Changing website prices based on client? (keywd: Web Software Engr) by knobunc (Pilgrim) on Jun 08, 2001 at 00:50 UTC
Good points. I guess I should have mentioned more about security of each method. REMOTE_ADDR and REMOTE_HOST are pretty safe since they come from the sockaddr struct that relates to the connection, so you are somewhat succeptible to a man-in-the-middle attack if the sender can spoof the IP address and catch the return packets (assuming that there is no TCP sequence number bug that allows him to predict the excact set of packets to send from elsewhere). Of course you are succeptible to a DNS attack if the attacker can spoof the reverse IP address lookup, and DNS is notoriously unsafe. Storing the ID on each page is relatively safe iff (sic) the discount ID refers to a token ID stored in the DB that is generated randomly (assuming your random number generator is sufficiently random) from a large search space. Really cookies and hidden form variables are equivalent since they are both submitted on each request and the user can munge them both. Since this is discounts you have to decide if you want the user to log in to the site. Personally I despise logging in until I am actually ready to order. It might be more productive for a site to give a 5% discount to a handful more people if they get more sales in general. Remember that stores often see 30 - 60% markups so they are making a profit even if they offer substantial discounts. -ben	[reply]

Replies are listed 'Best First'.

Re: Re: Re: Changing website prices based on client? (keywd: Web Software Engr)
by knobunc (Pilgrim) on Jun 08, 2001 at 00:50 UTC

Good points. I guess I should have mentioned more about security of each method.

REMOTE_ADDR and REMOTE_HOST are pretty safe since they come from the sockaddr struct that relates to the connection, so you are somewhat succeptible to a man-in-the-middle attack if the sender can spoof the IP address and catch the return packets (assuming that there is no TCP sequence number bug that allows him to predict the excact set of packets to send from elsewhere). Of course you are succeptible to a DNS attack if the attacker can spoof the reverse IP address lookup, and DNS is notoriously unsafe.

Storing the ID on each page is relatively safe iff (sic) the discount ID refers to a token ID stored in the DB that is generated randomly (assuming your random number generator is sufficiently random) from a large search space. Really cookies and hidden form variables are equivalent since they are both submitted on each request and the user can munge them both. Since this is discounts you have to decide if you want the user to log in to the site.

Personally I despise logging in until I am actually ready to order. It might be more productive for a site to give a 5% discount to a handful more people if they get more sales in general. Remember that stores often see 30 - 60% markups so they are making a profit even if they offer substantial discounts.

-ben

[reply]