|Problems? Is your data what you think it is?|
Re(4): The danger of hidden fieldsby cjf (Parson)
|on Jul 24, 2002 at 01:13 UTC||Need Help??|
Okay, Let's review:
All the customer data that is submitted to the script is as well as being emailed to us, stored in a text file. However the text file to store the data in is passed as a hidden field from the html, and there is no check to make sure that the referring page is the correct one.
So customer comes to the site, logs in, and currently their information (or more accurately, the location of the file containing the information) is passed via a hidden form field. There's no need for this really. The customer could just be passed a session identifier and all the remaining data would be stored on the server. This should be a relatively simple switch.
Now as for this:
cracker that saw his append and tracked him, or had been "casing the joint" for a couple of weeks, makes his move. Several (hundred) customers credit cards get used for whatever, and who gets the blame?
That's about equivalent to saying "if he puts locks on the doors and someone breaks in the next day, who's going to take the blame?" It's completely missing the point.
First off, there's no way a cracker's going to be monitoring a website with these vulnerabilities for weeks and not do anything. Secondly, not improving the security of a system for fear of being irrationally blamed for future incidents should be cause for dismissal on its own.