homepage Welcome to WebmasterWorld Guest from 54.196.57.4
register, free tools, login, search, subscribe, help, library, announcements, recent posts, open posts,
Subscribe to WebmasterWorld
Visit PubCon.com
Home / Forums Index / Code, Content, and Presentation / PHP Server Side Scripting
Forum Library, Charter, Moderators: coopster & jatar k

PHP Server Side Scripting Forum

    
Sruggling with form security
Have I got the right ideas?
kiwibrit




msg:3363788
 9:26 pm on Jun 10, 2007 (gmt 0)

I have been struggling to work out what should be happening, using this forum and Google, for good web form security. I think the information I need has been there, but it has been a question of taking it in. I don’t like Capcha, or questions required before filling the form, since I believe it deters potential genuine customers because of the hassle. I take it for granted the form attributes should be something like this:

<form name="contact_form" action="feedback.php" method="post">

At the receiving end, I check that method=”post” has been used, and that the form has been posted from my website.

As I understand it, though, the form still has types of vulnerability:

Firstly, the email field can be injected with code, so that the web server may be used to send out spam mail. One way I have seen of dealing with the problem is this function:

function injection($text) {
$text = strtolower($text);
if (preg_match('#(content\s*-\s*disposition)¦(bcc\:)¦(cc\:)¦ (content\s*-\s*transfer\s*-\s*encoding)¦(mime\s*-\s*version)¦ (multipart\s*/\s*mixed)¦(multipart\s*/\s*alternative)¦ (multipart\s*/\s*related)¦(reply\s*-\s*to)¦(x\s*-\s*mailer)¦ (x\s*-\s*sender)¦(x\s*-\s*uidl)#is',$text))
{ return true; }
else
{ return false;}
}

I am not clear whether text input fields other than the email one have to be checked for injection. I cannot understand how they could be, but I check them anyway. Do I need to? Is there any other code I should be looking for?

Secondly, spammers will probably drop hyperlinks into my form in he hope of being able to broadcast them by spam mail through my server, but at least to tempt the from mail recipient. To deter that (having advised in my contact page that hyperlinks are not acceptable in any field) I use the following code:

$outitgoesbb = '[/url]';
if (strpos(strtolower($Comments), $outitgoesbb)!== false) {
header("Location: $errorurl"); // rejects messages with [/url] in them
exit;
}
$outitgoeshtml = 'http';
if (strpos(strtolower($Comments), $outitgoeshtml)!== false) {
header("Location: $errorurl"); // rejects messages with http in them
exit;

Is there better code you would recommend for stopping hyperlinks?

Are there any other likely threats I should be allowing for?

[edited by: eelixduppy at 9:40 pm (utc) on June 10, 2007]
[edit reason] fixed side-scroll [/edit]

 

CDNQuilter




msg:3363914
 1:30 am on Jun 11, 2007 (gmt 0)

I have seen a lot of what I regard as overkill because folks don't understand what has to be eliminated.

The fields to worry about are textbox fields which will be sent the headers, before the message, and are therefore vulnerable to header injections.

In order for an additional header to be injected, you need the newline characters (\n\r) and you also need the colon: to follow cc or bcc.
If I am going to allow the entry of punctuation in the Subject field, e.g, I use a little function:

function spamWash(&$string)
{
$badstrings = array(
"to:",
"cc:",
"bcc:",
"%20","%0a","%0d",
"content-type:","mime-version:","multipart/mixed","boundary=",
"content-transfer-encoding","content-disposition:");
$replacements = array(
"to ",
"cc ",
"bcc ");
return str_ireplace($badstrings,$replacements,$string);

This just gets rid of the colon from to, cc, bcc and the header and then replaces theremaining stuff (which is my overkill lol!) with nulls. I probably only need to remove the colons from the rest of them also but it was easier to just get rid of the whole bunch. By leaving in the cc, bcc etc, it is VERY obvious if I were to receive the mail that the sender was trying to hijack the form so I wouldn't reply (and could choose to ban their ip address, which i don't bother with)
I do collect the ip address, though, and when I report back that the form was sent, I report the ip address along with it so that they will be likely to give up after one try.

I use a regex validation with preg_match() for their email address but I have had to loosen it up because many of them are too restrictive.

$regex['email'] = "/^[A-Z0-9\._-]+@[A-Z0-9\._-]+\.[A-Z]{2,4}$/i";

allows simple email addresses - not every long, complex one. To get around that, I make the email address optional and tell them that if the edit rejects it, they can include it in the body of the email message.

$regex['fullname'] = "/^([A-Z '-\.]+)$/i";

This is pretty good for names - it will allow Jill St. John Smith-O'Toole which pretty well covers names and their punctuation.

With this validation I don't need to bother with the spamwash function because the offending stuff would never get by the regex edit.

Where possible, I have a drop down box to select the subject rather than having the user type it in -- then I verify that $_POST['subject']is in my array of valid subjects. Then I don't have to worry about cc: etc. at all

Because the message itself is sent last, I don't believe that it can be used for header injection purposes so all you have to worry about is hyperlinks. Most of my forms are strictly text so I just use the striptags() function on the message. The person can still send a link but you would have to click on the link - it wouldn't be automatic as it could be if you allowed the <a></a> tags. Whether to allow a link at all or not will vary from one application to the next - you seem to have decided not to allow them. A clickable link needs http:// so you could just to str-ireplace() to get rid of that portion and the link will no longer be clickable. In fact, again, the link will not be 'live' if you just clobber the colon!

Also, I stopped exiting on suspicious characters - I just re:display the form after my edit with the suspicious characters removed. Spam bots give up submitting the form after a few tries, I think.

On one form I implemented, I sent mail that failed the spam editing to a different email address because the customer wanted to collect the ip and email addresses to add to their list of senders to block. (Though they said that they actually received very few and stopped just automatically threw those emails away.)

Just a few thoughts - I'm sure that others have lots more experience than I do!
cheers

Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Code, Content, and Presentation / PHP Server Side Scripting
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About
© Webmaster World 1996-2014 all rights reserved