Testing Your Forms for Hijacking Vulnerability
By Will Bontrager2005-10-07
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.
Tutorial Pages:
» Testing Your Forms for Hijacking Vulnerability
» Want To Skip Testing?
» Is a Spammer Spider On the Loose?
» Why Should I Test?
» Won't Spammers Use this Article To Find Vulnerable Forms?
» How Do I Test?
» Now What?
Copyright 2004 Bontrager Connection, LLC
