///Testing Your Forms for Hijacking Vulnerability

Testing Your Forms for Hijacking Vulnerability

Testing Your Forms for Hijacking Vulnerability

DISCLAIMER: Experience has taught me it is impossible to know everything in cracker minds. Common sense security precautions when programming software go a long way to reducing vulnerabilities. And I’ve learned to anticipate things and reduce vulnerabilities ahead of time. But I can not, and I do not claim to, know everything software crackers have tried and will try in the future.

Look at this article as a "how-to" for testing your forms for a specific vulnerability, hijacking by inserting certain information into the header of email your form processing software sends out.

These tests may not be exhaustive. Crackers have devious minds and may even now be thinking of hijacking methods I haven’t considered.

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).

Want To Skip Testing?

If you believe you are unable to do this testing, or don’t want to take the time, or just want an easy solution that you don’t have to worry about, the hijack-proof form delivery subscription at http://webform.flowto.info/ is only a few dollars a month. (This is our own service, and I recommend it highly for anyone who wants easy copy ‘n paste implementation and peace of mind.)

If the forms delivered by the above subscription won’t fit your requirements, Master Form V4 from http://willmaster.com/mfv4 and Master Feedback from http://willmaster.com/msmf are both coded to block form hijacking. Do consider them. The first can handle almost any kind of form requirements and is $79. The second is for simple forms and is free.

Unlike the form subscription service, this software would need to be installed on your server.

A note about Master Form V4: It notifies web site owner when it spots unusual activity that might be a hijacking attempt. The notification email is cryptic and could be alarming when first received. For the last several months, I’ve been hearing from various Master Form V4 owners asking about these emails.

Is a Spammer Spider On the Loose?

Yes, it seems a spammer’s spider is on the loose, trying every form it encounters.

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.

Note to owners of Master Form V4, "No need to worry about those notices when you get them. The software is tight against this kind of probe."

To those using Master Feedback, "The software won’t send you a notice of hijacking attempts. But I’m reasonably certain it, too, is tight against this kind of probe — provided you’re using the latest version."

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.

Won’t Spammers Use this Article To Find Vulnerable Forms?

Maybe.

For over a year, I’ve resisted the dissemination of how to test forms for vulnerabilities because of this very reason; spammers could use it to test their neighbor’s forms. With the release on the Internet of the auto-vulnerability testing robot, however, my resistance vanished.

At this time, lack of knowing how to test forms might be more damaging than making the knowledge publicly available where those who would misuse it can find it.

How Do I Test?

It’s rather simple, really; like most things, once you know how.

I’ll show you by example.

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 drive.

(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 name@example.com 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: name@example.com[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 at http://webform.flowto.info/ is also available for very little money and can provide refreshing peace of mind.

2010-05-25T23:06:36+00:00 October 7th, 2005|HTML|0 Comments

About the Author:

Leave A Comment