PROTECT YOURSELF
In part 2 of this 4 part article on information security, the CISP policy (Cardholder Information Security Policy) being mandated by financial acquiring networks was covered. These mandates were mainly about protecting the credit cardholder and the acquiring merchant bank from having vital information fall into the wrong hands.
It is essential to protect yourself from malicious and inadvertent attacks that can corrupt data, provide misinformation, and even bring down a server. This third installment covers steps you can take to minimize these risks through good design practices with forms and site operation.
USING FORMS
Forms are one of the great features introduced to the HTML document standard. Without them, it would not be nearly so easy for clients and customers to communicate through sites on the Internet. However, forms were introduced to the HTML markup language very early in the development of HTML standards when the Internet was a benign and friendly place and not much concerned with e-commerce. For this reason, little or no attention was paid to maintaining the integrity of form information.
In today’s environment, where on-line storefronts are collecting vital customer information through form fields, one must reconsider how to handle form information. Forms are a big target of opportunity for even the least sophisticated of hackers and malicious mischief makers as well as being vulnerable to innocent mistakes made by legitimate customers during data entry.
FORM VULNERABILITY
Forms are vulnerable in several ways:
1) Forms are subject to the simple human error of entering bad information and the malicious intent of entering bogus information.
2) Forms are easily redirected to an unintended receiving server.
3) Form information can be easily altered.
4) Forms are subject to repeated submits.
5) Forms can be used to introduce malicious code into a server.
Item 1, human error Probably the most common piece of information subject to human error submitted by a form is the e-mail address. There are two places where an e-mail address can be tested for validity: the client machine by using JavaScript and at the server machine using one of the resident scripting languages. How through a test you make will depend on how critical the e-mail address is to your application.
A quick test should be performed on the client machine. This test can be used to prevent a form from being submitted to a server where there is an obvious error. The test should make sure there is an at sign (@) and a dot (.) in the e-mail address and that the address is at least six characters in length. You’ll be surprised how many times people forget the dot information.
A more through test can be performed at the server using a little script to ping a mail server indicated by the e-mail address to see if a valid connection is possible. This still won’t guarantee that the identified party has a mail box on that server, but as mentioned earlier, 100% guarantees in information security are going to be astronomically expensive.
Naturally you can test other form fields as well. Normally though, it’s safe to assume that a legitimate customer is going to try and get entries right and that a bogus customer will be found through other methods.
The credit card number entry is an exception. Here a petty thief may want to try random entries to see what happens. Credit card numbers are not random. The first two or four digits indicate the acquiring network (Visa, MasterCard, etc.) and the full series of numbers must obey a checksum rule. There are numerous JavaScript sources for functions that will perform credit card checks on the client machine. This validity check is highly recommended. Why let a hacker use your servers to submit obviously bogus numbers to a gateway for processing. With this validity check you can block the form from being submitted.
Item 2, redirection Remember, HTML pages are open source code. The form information on a page is no exception. Anyone can view form information by using the “view Source” utility in a browser. This includes forms that have been returned to the browser using the SSL protocol. The form page is entirely decrypted before being presented to the browser for rendering and hence can be read by anyone.
Two of the parameters in the form command line are “method” and “action”. “The “action” value tells the browser where to send the form and the “method” value determines how the form information is sent. It is very easy for anyone to “view source”, save the file, change the “action” parameter, reload the form to their browser, and submit the form to a new URL. If the “method” for submitting the form is “get”, all of the form information will show up in the browser address field for anyone to change without even having to view the source.
Item 3: form altering Any of the information in the form can be changed just as easily as the examples above and the form sent to the intended URL ….except maybe this time the purchase price on a credit card information form has been changed.
Hidden fields in a form are no exception to the altering vulnerability. Hidden means that the form information isn’t shown in the browser presentation. Nonetheless, the hidden values are still visible when you “view source” and still subject to change.
Item 4: repeated submits Repeated submits of forms occur frequently, especially where connections are slow. Want to bet you’ve done it yourself: click, wait 4 or 5 seconds, click, click, click. If the receiving script isn’t prepared for this, things can start to go bad fast; multiple submits can even bring down a server in some instances.
To prevent multiple submits, use some submit count method. This is best done in JavaScript at the client machine so that the server doesn’t have to deal with such problems. A favorite method of ours is to replace the message on the submit button when the form is submitted to something like, “Processing, Please Wait”. This message is then used to disable any subsequent submits.
Item 5, malicious code It’s little known, except to certain hackers, that executable code can be introduced to a server through form fields. This is potentially a very nasty vulnerability. Prevent this from happening by declaring a character type in the head of the form document and use JavaScript before submitting the form to check entries for unwanted characters. For instance a back slash () entry might be indicative of an attack.
FORM AND SITE DESIGN
At this point it should be evident that forms of themselves cannot be used as a trusted source of information, hidden form fields and SSL not withstanding.
Credit card information gathering forms especially should never, ever be submitted directly to a gateway for card processing. Such a form would have to have the merchant ID numbers in it exposing vital information to anyone wanting to take a look. A hacker could make a couple of minor revisions to the form and submit it as a return credit transaction rather than an authorization. Naturally the hacker will be returning money from your merchant account to his own account.
To prevent this security breach, you must submit the form to an interim script on your host server and the form should only include information being provided by your customer. The interim script is used to configure and send the information that has to be passed to the processing gateway. In this way, the actual gateway transaction is hidden from the client, preventing any altering.
Information that has to go to the gateway, but is generated earlier in a session, should be available to the interim script using server side variables, single threaded to the customer session. This cannot be stated too strongly. Nothing should be in the credit card form except the specific customer card information and a script for checking the validity of the form content and blocking multiple submits.
CREDIT CARD FORM EXAMPLE
As an example, at ImagineNation we use an interim script to call up the gateway and at the same time return an “in process” page to the customer when a credit card form is submitted. This interim page contains no vital information and is delivered to the client browser using a window replace method so that there in no browser history of the page.
When the gateway transaction concludes, an action message is presented to the customer. If the transaction is approved, the message is a confirmation and the session is killed. At this stage, should the customer try the browser back button, they will be returned to the credit card form. However, resubmitting the form will result in an “access denied” message because the session is no longer active.
If the transaction is declined, we return a declined message page with the reason and allow the customer two more tries using a link on the page back to the credit card form. There they can change information or try using another card. This method protects us and keeps the customer happy.
Often a customer will make a mistake entering a card expiration date. There is no client or server side way to check that this is the correct card date before submitting to the gateway to process. Therefore, in the interest of customer relations, we allow a limited number of retrys on declined cards while at the same time preventing a hacker from trying many random entries until finding one that works.
CONCLUSIONS
You may begin to see a pattern developing here. Protecting information is a matter of creating layers of security policies, procedures, and methods. No one thing you do is adequate in itself. Your job is to make access to vital information increasingly difficult for the hacker and unlikely for the inadvertent user and mischief makers.
Forms are great, but without certain combined form and site design considerations, they represent an easy target of opportunity for even the unsophisticated hacker. They are also subject to innocent human error during information entry. Take a little time and think about the risks when creating a site using forms. Reducing the risks is not hard; it just takes a little thoughtfulness in the design.
COMMING UP
The final installment of this article will draw some overall conclusions, look to the future, and explore myths about securing information, including a big one that’s pervasive throughout Internet.
Mel Davey is the creator of ImagineNation (http://imaginenation.com/), a full service E-Commerce Application Service Provider, offering Storefronts, Order Management Utilities, and 3rd party credit card processing.
