Attack detection

[Richard KImber]

I have:-
define("ATTACK_DETECTION_MANY_URLS",7);
in formmail.php
yet if anyone enters a URL the form is rejected as having too many URLs

Can this be a bug?

The form is at:
http://www.politicsresources.net/search/suggest.php

[russellr]

Hi,

I just submitted your form with a URL, and then a second time with 2 URLs.

Is the problem resolved?

[Richard KImber]

Thanks for replying.

I got both your messages, but I just tried again myself and it rejected one with http://www.bbc.co.uk/ . It had also rejected a test by jzieba when I first asked in the support forum, and I was first alerted to the problem by a website user, so it's not just me.

It's bizarre.

[russellr]

Hi,

Yes, just tried it with that URL and got the problem.

Can you please email your copy of FormMail to supportstaff AT tectite DOT com?

I'll check it out.

[russellr]

Hi,

OK, your FormMail checks out fine.

So, this means there's something strange going on on your server (or you sent me the wrong copy of your FormMail).

I did find one oddity in your HTML.

You have:


action="http://www.politicsresources.net/search/formmail.php?PHPSESSID=bca7dc5f5458df5744a9ca1f8a6b23e8"
This is not correct.

It should be:


action="http://www.politicsresources.net/search/formmail.php"
You don't want to be passing a PHP session ID.

Make that change and test again.

If you're still having the problem, I'll need to login to your server to run some tests
to figure out what's going on.

You can send access details to your server using this secure form:
https://secure.rootsoftware.com/~tectite/sendsecret.php

But first, please subscribe for support noting our standard guarantee (http://www.tectite.com/vbforums/showthread.php?t=1567).

[Richard KImber]

Thanks. I've changed
http://www.politicsresources.net/search/formmail.php?<?php if (defined("SID")) echo SID; ?>
to
http://www.politicsresources.net/search/formmail.php

but there was no change in the issue: it occasionally works, but mostly it doesn't. There are actually two forms that use the same formmail.php
http://www.politicsresources.net/search/suggest.php
http://www.politicsresources.net/search/email.php

I have subscribed for support, as suggested.

[russellr]

Hi,

OK, I'm looking into the problem now.

I misunderstood. It's probably OK to have this:


http://www.politicsresources.net/search/formmail.php?<?php if (defined("SID")) echo SID; ?>
However, you only need that if you've set the session name to something different.

But, in this case, you should simply use FormMail's SESSION_NAME configuration to set the session and FormMail will automatically attach to the correct session.

Put simply, you don't need the "<?php if (defined("SID")) echo SID; ?>" on the URL for FormMail.

However, you *will* need it for CaptchaCreator if you change the session name.

But, since you haven't changed the session name, it's not needed.

(Sorry, it's inherently complicated.)

[russellr]

Hi,

Mystery solved!

You have:


<input type="hidden" name="referer" value="<?php echo $_SERVER['HTTP_REFERER']; ?>" />
You're generating a field called "referer", which is fine. It will usually contain a URL.

Now you also have:


define("ATTACK_DETECTION_MANY_URL_FIELDS",2);
Which says if 2 or more fields contain a URL, it's an attack.

So, when someone goes to your suggest.php form, and enters any URL, the attack detection will trigger because they've enter a URL in your "mesg" field, *plus* you've generated a URL in the "referer" field.

And, it only happens sometimes because the "referer" field will be empty unless the user has clicked through from another web page. In other words, if you enter the URL directly in your browser, there is no referer and the field will be blank.

You can test this by creating a fresh browser window and entering the URL in the address bar. In this case, there's no referer and you'll be able to enter URLs.

But, if you click a link to get to that page, it won't work with any URL.

Also, complicating the matter is the fact that some people's browsers don't pass referers. Therefore, it always works for them.

The correct solution is not to create the "referer" field that way.

If you use "derive_fields" to create it, you won't have the problem because the attack detection is performed *before* fields are derived.

So, I've created a copy of your suggest form for you to test this:
http://www.politicsresources.net/search/suggestrr.php

Please click the link above (so there is a referring page), and test it and if all is OK, I'll move it into production for you.

You can verify that the referer field is created in the email you receive from the form submission.

[Richard KImber]

Thanks. I can confirm that your method solves the URL problem. However, I'm not getting the 'right' referrer info.

I did it the way I did originally because your method, which I originally tried, didn't give the info I wanted. What I'm after is the URL of the page from which they go to the suggestion page. Your method generates
http://www.politicsresources.net/search/suggestrr.php
as the referring page, which is actually the suggestion page itself, and not the page from which they arrived at the suggestion page, which I would take to be the referrer.

The problem arises because many people send me suggestions without indicating what they are suggestions for, and - as it's a large site - knowing the page they came from helps me understand what they might be suggesting.

- Richard.

[russellr]

Hi,



I did it the way I did originally because your method, which I originally tried, didn't give the info I wanted. What I'm after is the URL of the page from which they go to the suggestion page.


Yes, that makes sense.

So, the solution is to leave your HTML the same (with the referer hidden field you're creating), but then increase ATTACK_DETECTION_MANY_URL_FIELDS by 1 (to a value of 3) to allow for that field plus one other field to contain URLs.

[Richard KImber]

OK. I'll do that.

Thanks for identifying the problem - I would never have thought of the solution because I wasn't thinking of hidden fields being included.

Is there a case for excluding them in the count of URLs?

- Richard.

[russellr]

Hi,

When the browser submits the form data to the server it doesn't identify the type of field.

So, the server software has no way of distinguishing between "hidden" fields and other fields.

In many ways, that's actually a good thing.

But, it does mean that FormMail can only deal specially with fields it "knows" about, such as "realname", "email", "mail_options", etc.

So, in short, there is currently no way for you to identify your "referer" field to be treated differently to other form data fields.

However, we've added this to our TO DO list for a future version, so at some point you can do that and then drop the ATTACK_DETECTION_MANY_URL_FIELDS value back to 2.