|
How to Stop Digital Thieves with CGI
|
By Steve Humphrey
[Hits: 24923]
|
|
I'm going to assume you're serious about your business. Ifyou're not, I can't help you anyway. You've gone as far asgetting a real merchant account to accept credit card paymentsonline.
You know that this was neither easy or cheap. So does everyoneelse! So, a merchant account shows that you've made a seriouscommitment to your business. That's good for customerconfidence, which is good for business. So far so good...
Now there's the issue of selling stuff to people online. Yourorder form leads them to feed their credit card info to a securegateway, using software you bought or leased from (or through)your merchant account provider. Finally, the transaction isapproved or denied.
If approved, the software generates a receipt and emails you andthe customer each a copy. At this point, the customer isreturned to a page you specified. In the case of downloadableproducts, this is often the page where they download yourproduct. So, you've got the entire process fully automated.
For a product or service with a fairly low price point and apotential for many thousands of sales, this seems ideal. You canquite literally make sales and earn income 24 hours a day. So,what's the problem?
The form code on your order page is the problem. If someone usesthe ViewSource function of their browser, they can see all yourcode. If they have even a tiny bit of initiative and skill, theycan locate the URL of your download page. After all, it's rightthere in your form code!
CGI provides two ways of fixing this problem. One involves usinga script that makes it impossible to view the source code. Youcan find a source for such a script by searching the web. Expectto pay a lot for this technology.
Another way is to make the return path a script instead of theactual download location. The script would be used to create anddisplay the download page. It would not be visible to thesurfer, since it's not an HTML document. The script can alsorecord details of the transaction for book-keeping purposes.
I admit that I discovered this by trial and error - and a luckyguess or two. Your merchant account gateway software may haveradically different behavior than mine, but here's what I'velearned:
The gateway uses the POST method to send the customer to yourspecified return URL (which can be a script as well as a webpage). It also POSTs most of its input data items at the sametime. They are usually ignored, but your script can read them ifyou want to!
Use the names given to the form inputs. Have your script extractthe values of these "named parameters" at the time it createsthe download page. Record what you want to save about thetransaction in your orders file or database.
Now here's the real secret to foiling the thieves. Inside thescript, check to see that the variables you extract containnon-empty values. Did you get that? Here's an example:
if ($email eq "") {exit;}
In this example, the script expects to get an email address. Ifit contains no characters, the script quits instantly. Bytesting for the presence of some data in such fields as customername, email address, item #, price, etc., you can tell whetherthe script was called after a successful transaction - or by athief...
Put all your security checks prior to the code that creates thedownload page. If any test fails, the script exits and the thiefis left empty- handed. If your form-handling script can converta product name to a product ID that's never visible to abrowser, this provides even more security. This will be POSTedback to the script and you can check for it before allowing thedownload.
Close these security holes and you'll make more money. You mayeven sleep a little better knowing that people can't steal thatproduct you worked so hard to create. I know I do!
|
|
|
|
|
|
