This article will, however, show you how to discover currently targeted vulnerabilities your form processing software might have, vulnerabilities mentioned in the "Web Page Form Anti-Hijacking Considerations" article found at http://willmaster.com/hijack1 (demonstrates how to modify software to close the hijacking vulnerability).
One of its trademarks is that it uses identical email addresses in all but one form field when looking for vulnerabilities, an address with the domain name where the form or the script is located. It keeps one field back to try for a vulnerability, one field at a time, and the Bcc is almost always to an AOL address where, presumably, the miscreant would be notified if the spider found a security hole.
Why Should I Test?
Because hijackers send their spew from your server. Because you could get on blacklists that are very hard to get off of. Because you could lose your hosting account. Because your hosting company could shame you.
Yes, there is a hosting company that lists the domain names of those who have had their forms hijacked. I don't know whether or not they're doing it to shame their customers, but can you imagine what kind of public relations damage that could do?
Take a look at http://www.hosting.io/ — they've had a red type on black background notice published on their front page for over a week, in the middle of the page when it first loads, publicly naming two domains they suspended because the domains had their forms hijacked.
Hosting companies don't like insecure forms. A hijack can land the IP address or even range of IP addresses into serious blacklisting trouble, requiring many hours of otherwise productive wages to repair.
Ask yourself, does your hosting company need you so badly that they would overlook it or just serve you a wink if one of your forms were hijacked?
Nowadays, it is essential to have secure forms. Otherwise, you are constantly in danger of being exploited.
How Do I Test?
The example form below has eight different types of form fields — not all those would be needed for the example, the procedure is the same regardless of what type of field, but I decided to be as thorough as I could be.
The file upload field and the "reset" button are missing from the example because I can't conceive of a way they could be used to hijack a form; thus, I don't know how to test for it.
<form
method="POST"
action="http://example.com/cgi-bin/script.cgi">
<input
type="hidden"
name="subject"
value="Someone used the contact form!">
Email Address:
<input
type="text"
name="email"
size="22">
<br />
Postal Address:
<textarea
name="postal"
cols="20"
rows="3">
</textarea>
<br />
Reason(s) for contacting us:
<select name="reasons" size="3" multiple>
<option value="1 ">To say "hi".</option>
<option value="2 ">Something wrong on your site.</option>
<option value="3 ">To ask a question.</option>
<option value="4 ">I have an idea!</option>
</select>
<br />
What color is your hair?
<select name="hair">
<option value="">- Select One -</option>
<option value="1">Red</option>
<option value="2">Green</option>
<option value="3">Normal</option>
</select>
<br />
Check all that describe you:<br />
<input
type="checkbox"
name="describe"
value=" smiley">
I'm a Smiler :)<br />
<input
type="checkbox"
name="describe"
value=" laugher">
I laugh a lot :~0}<br />
<input
type="checkbox"
name="describe"
value=" reader">
Mostly, I read<br />
<input
type="checkbox"
name="describe"
value=" partyer">
Mostly, I party<br />
What sound is your voice?<br />
<input
type="radio"
name="sound"
value="squeak">
Squeak<br />
<input
type="radio"
name="sound"
value="horn">
Bull Horn<br />
<input
type="radio"
name="sound"
value="normal">
Normal<br />
<input
type="submit"
name="submitter"
value="clicker dude">
</form>
That's the example form we'll use for the instructions. You can follow along with one of your own forms, instead, if you wish.
The source code of the form must be copied into a separate file. This separate file is what you'll use to test your form.
If your form handling software requires your form to be on your domain in order to successfully submit it, then you'll need to upload this file to your server after the form has been modified. Otherwise, it can be tested by loading the file into your browser directly from your hard 
(Note that software can be made that emulates a form being on your domain and submitted from there. We're not going to go into how to do that, suffice to say it can be done. It's mentioned to discourage thoughts that a form might be safe because the software requires the form to be on a certain domain.)
Every field of the form needs to be changed to a textarea field, including hidden fields and the submit button field. (The submit button field can be left alone if it does not have a "name" attribute.)
You'll add your own nameless/valueless submit button to the form for use while testing.
Any form fields with default values should have the values retained when the field is changed to textarea.
Here is the converted example form to use for testing:
<form
method="POST"
action="http://example.com/cgi-bin/script.cgi">
<textarea
name="subject"
cols="30"
rows="3">Someone used the contact form!</textarea><br />
<textarea
name="email"
cols="30"
rows="3"></textarea><br />
<textarea
name="postal"
cols="30"
rows="3">
</textarea><br />
<textarea
name="reasons"
cols="30"
rows="3"></textarea><br />
<textarea
name="hair"
cols="30"
rows="3"></textarea><br />
<textarea
name="describe"
cols="30"
rows="3"></textarea><br />
<textarea
name="sound"
cols="30"
rows="3"></textarea><br />
<textarea
name="submitter"
cols="30"
rows="3">clicker dude</textarea><br />
<input type="submit">
</form>
Notice the </textarea> tag is on the same line as the end of the <textarea...> tag, unless the pre-converted tag was a textarea field. The reasoning behind this is so we won't inadvertently submit a linefeed character at the end of values for fields that don't naturally contain linefeeds.
For the first submission of the converted form, fill in the textarea fields with values expected by the program. If the field was a list or checkbox or other non-text field, check the source code of your pre-converted form to see what value's you can use.
Once you've successfully submitted your converted form and you've received the expected email the form processing software sends out, then you're ready to test in earnest.
Decide on an email address that shall receive successful vulnerability tests. Please verify the email address is correct; otherwise you won't know if any vulnerabilities are found.
In the example procedure, replace This e-mail address is being protected from spambots. You need JavaScript enabled to view it with the email address you decide upon.
Do the following for each form field, one at a time, starting with the top (or the bottom, if you work better that way). Be prepared to spend some time. Although the instruction paragraphs are short, there is potentially a lot of work here.
1.
Append the following to the information already in the first form field (replace each [LB] with a physical line break, meaning a click of the enter key):
[LB]Bcc:
This e-mail address is being protected from spambots. You need JavaScript enabled to view it
[LB][LB]Ouch![LB]
When you've appended that to the first form field, submit it. Then return to the form, remove the above from the first form field and append it to the second.
Do that with each form field.
That was step one.
2.
In phase two, do step 1 all over again, except this time replace [LB] with: %0a (that's a digit zero, not a letter O). This phase is for testing forms on Unix/Linux servers.
3.
In phase three, do step 1 again, except replace [LB] with: %0d%0a (again, those are digit zeros). This phase is for testing forms on Windows servers.
Note: Let me suggest that you test both the Unix/Linux and Windows phases. Spammers would. And your form processing software might be built to recognize either version.
The %0d and %0a are hexadecimal codes for return and linefeed characters, respectively.
4. and 5.
Now, test both phase two and phase three all over again, except this time use capital letters in the replacements instead of lower-case letters, in case the form processing software recognizes only one or the other: %0A and %0D%0A
6.
Now, do step 1 again, except this time replace [LB] with the octal representation: \x012 (include the backslash)
7.
Do step 1 again, replacing [LB] with: \x015\x012
Okay, you're exactly half done with the testing.
If the previous form submissions were method="post", change it to method="get" and do all seven steps again. If the previous was method="get", change it to method="post" to repeat the seven steps.
If your form processing software will only accept method="post" or only method="get", then you won't have to do the other. But if it will accept both types of submissions, test them both thoroughly. Spammers will.
Now What?
Now, you check your email.
If you received an email at the address you used for the testing, with the word "Ouch!" anywhere in it, your form is vulnerable.
If you did not receive such an email, your form might or might not be vulnerable, but probably isn't at this time.
The above may be a more thorough test than the current crop of spammers' robots are doing. The robots will get better and better, you can count on that.
If we can all plug any vulnerabilities we find, or replace vulnerable software, and keep ahead of the robots, we might be able to frustrate spammers who have been frustrating us all these years. And keep our good names with our hosting companies as a bonus.
The "Web Page Form Anti-Hijacking Considerations" article can guide you when repairing vulnerabilities of some software. The URL is http://willmaster.com/hijack1
If you do not wish to repair, the two software titles from http://willmaster.com/scripts mentioned above both have anti-hijacking code built in. The hijack-proof form subscription service athttp://webform.flowto.info/ is also available for very little money and can provide refreshing peace of mind.
Bloggermatre - Bali Web Project
