Network Security Consulting Blog

One of our readers wrote in to ask, “My website has forms in it and I want to know how to tell if they can be hacked.” The website is using a standard processing language and a back-end MySQL Database. Multiple forms exist in the website including a newsletter form, a user fedeback form, and a New Membership signup form. Although versed in programming, the reader does not have a background in security programming or network security in general. Realizing that web forms can be a port of entry for hackers, the question of website application security arose and inspired contacting me. Lets discuss web form application security for your network.

Web forms are a big security issue for any website, especially if the website framework was not developed with security programming in mind. The major purpose of a web form is to allow a visitor to submit information to your web server for processing of some sort. Simple programming would assume the visitor would enter data into the form fields as expected and desired, and all would be processed without a hitch. Unfortunately, hackers and malicious users do not always submit the expected or desired field data. A malicious user may want to submit rude or useless jibberish just to waste everyone’s time. FormBots will submit advertising for Viagra or reduced mortgage rates, hoping that somewhere an admin will rush to buy… who responds to spam anyway? On the more extreme end of the scope, hackers will submit more than simple jibberish.

When a hacker discovers a form that was not programmed with security in mind, the wheels of misdeed start to speed. The goal of a hacker is to discover paths of entry into your applications and into your network. Gaining control over the server is a major goal, while causing modifications to the server or database are still quality goals. The hacker will start by testing the waters to see what the server is doing with the data and how rejections or mis-processing results. This leads us down the path of how hackers work, which is not entirely within the scope of this article. Our focus here is whether the web form in a site is vulnerable or not.

Lets use the newsletter signup form as an example. The form has a single field and a single button. The web programmer designed the email address field to allow only up to 125 characters and used Javascript to check the format of the data entered before it can be submitted to the web server. As fancy ass that sounds, using Javascript and user-end restrictions is essentially useless in the battle against being hacked. They provide some gudance to the user and perhaps release some burden of processing from the web server, yet in terms of security can be ignored as such. A hacker can bypasss these altogether, and in most cases can submit the data without using the web form, web page, or web site at all! hackers can POST or GET form data to your server directly with some serious repetition and automation, sensing thousands of submissions, each trying new variations on the data submitted.

Setting any Javascript or web page programming, we must turn to the server-side processing for real security measures, in the scope of the web server and the chosen processing language (PHP, ASP, CFM…). An experienced security programmer thinsk in terms of what can go wrong more than what can go right. What if No Data is submitted and the email address variable is empty? What if the data submitted is a web address instead of an email address? Holy Cow, what if the user submits an SQL Injection targeting the database to extract all our records or even delete every record? These are good questions for the programmer to consider when creating the web form in the first place, not later when the owner freaks out and asks, “Where did the 63,756 email address records all disappear to?”

If your web programmer cannot define the strict measures for protecting your server against form attacks, you must inspect your code, evaluate your entire site, and make sure you are not a target for attack. With multiple programmers on a team, you may find one form on the left is secure, but the form over on the righ tis completely insecure. You only need one hole in your boat to sink the entire crew. Lets review some major methods of attack and the two major programming requirements to prevent them.

Attacks come in a few general flavors with specific intentions:

• Low Threats – Idiots or malicious users submit garbage data.
• Medium Threats – Idiots or FormBots submit advertising or large volumes of submissions to cloud your records.
• High Threats – Hackers submit SQL Injections or Code Injections while trying to gain control of your server or applications.

There are two major methods for preventing these and other attacks, plus optional methods:

• Data Cleansing – Remove/replace undesired/illegal characters or strings form the submitted data.
• Data Validation -Inspect the data to assure it meets satisfactory requirement for the variable type expected.
• Data Testing – In some cases, the data may be tested to determine if it is truly useful data.

Data Validation can save you a lot of headaches from the Low to Medium threats, as well as the High Threats. If the data expected is supposed to be an email address, it should look like an email address, nothing else. There are many ways to paint this picture, but the essential approach is the same. If the value does not meet “email address criteria” it is simply not valid. Regular expression filtering will match the submitted value against a pattern meeting email address format specifications, and provide the best filtering possible. On the simplistic end, an email address should contain a single @ symbol, and at least one period, etc.Hackers can get past simple filtering and use of regular expression filters is advised.

Data Cleansing is most effective when combined with Data Validation, but can in itself prevent a significant percentage of attacks. An email address should not contain various illegal characters, which may be perceived by your parser (your programming language’s server-side evaluator) as code rather than form data. If you find illegal or unexpected characters in the submittedd data, you can remove or replace the characters, or simply reject the entire form. Data Cleansing and Validation are your best defense against web form attacks and there is both an artistic and scientific approach to usage.

Now, lets say the user is malicious and wants to submit the same email address a zillion times. Your application should inspect previously submitted email addresses and reject the addition as a repeat. But what happens when the attacker uses an automated attack that increments or iterates the alphabet submitting endless numbers of correctly formatted, but non-existent, email addresses? Your server should throttle the number of submissions allowed from any single IP Address to start, which mut be a server-side restriction rather than using cookies/sessions to manage the throttling. You may at this point opt to include Data Testing to make sure the address really exists.

Data Testing is less frequently applied in web applications, but the email address data type is one that may mandate its use. The server first cleanses and validates the address. Given that the address has a valid format, the application continues and parses the address into the doain portion and the name portion. A simple MX Record lookup will list the possible Mail Exchange DNS Records fgor the parsed domain portion, and if they exist, the application moves on the the next test. DNS records may be faked, so the application should attempt to connect to the Mail Exchange Servers, in sequence, to see if any of them respond. If any of the Mail Echange servers respond, the application moves on, and using the entire address, the application asks the Mail Exchange server if it would be willing to receive email for the name portion of the address. If the Mail Exchange server accepts the email, it is likely a valid address, but if it is rejected, the address is surely invalid. The reason the address may still be invalid despite being accepted by the Mail Exchange server is because it may be configured to accept ALL emails and deliver the invalid addresses to the Postmaster or server admin.

The process of testing an email address described above is simplistic for reading. Programming this as a security feature is not as easy as describing it, but still not difficult for the security programmer. This is only to screen and test an email addres, where there are many data types and formats you must test for. EVERY SINGLE FIELD of a form is a possible port of entry for a hacker, and thay must EACH AND EVERY ONE be filtered. Iterative loops may filter same data types, such as last name, first name, middle name. But different data types should be handled separately for the best network security results.

With various methods for attacking a web form, and the serious need for web application security for your network, knowing that security programming was part of your project has become mandatory. If you are about to start a project, make sure you have at least one security programmer in the programming team. If your project is underway, and you lack security programmers, be prepared to start a Secure Code Audit upon completion with possible re-programming if errors are found. The same Secure Code Audit is necessary if your project has already been launched and nobody assured secure programming in the design. Beware “Programming Frameworks” that give a misleading sense of capability and efficiency to faux-programmers. Franmeworks are constructed by other programmers who may not be as security-minded as you need, and introduce security vulnerabilities that are easily overlooked. There is no true substitute for an experienced security programmer proving the safety of your web applications and network!

Bear in mind that a radio, checkmark, dropMenu or List field object may easily be converted to any other field object type by a hacker. Form objects that appear to only allow a Yes/No submission are still major points of attack, while deceiving programmers who are not security-minded. A majority of programmers overlook the intricacies of security programming while maintaining a stance of being security-minded in their programming. The litmus test for their products is generated by scanning their applications with vulnerability scanners and doing  independent secure code audits.