Best way to stop form abuse?

theMAD2 · 13 Jun 2006 at 10:42

I want to add an email field to my form on my website which will email the user back with a confirmation email, as well as me. Just wondered what's the best way to stop people abusing this?

Thanks

theMAD2 · 15 Jun 2006 at 10:48

anyone?

riddlermarc · 15 Jun 2006 at 11:12

Abuse in what way? As in people putting in other people's email addresses for a joke etc?

theMAD2 · 15 Jun 2006 at 11:15

Sort of. I can't really stop someone putting someone elses email address in, but I would like to limit people to only being able to send 1 email every 10 minutes or something to stop people sending loads out. Any ideas mate?

riddlermarc · 15 Jun 2006 at 12:36

You could log the time/ip address of the visit to a database, so that every time the form page is loaded it will check the current ip address against logged ones.. if there's a match within ten minutes then silently redirect to another page or show up a warning on the form page.

theMAD2 · 15 Jun 2006 at 12:42

Sounds like a good option. Are there any other ways of doing this without using a database? I was thinking about putting a pause in the php script before the message is sent.

riddlermarc · 15 Jun 2006 at 12:47

Other than putting the ip addresses/times in a flat text file, probably not.

HTMLHugo · 15 Jun 2006 at 15:10

use session variables ?

at least limit them to one form submit every 20 minutes

which generally means that people arent going to wait about for 20 minutes.

robmiller · 15 Jun 2006 at 15:30

Just use a session:

PHP:

session_start();

if( $_SESSION['lastMailed'] + 600 < time() ) {
    echo 'Wait 10 minutes before mailing again!';
    die;
}

// Mail here

$_SESSION['lastMailed'] = time();

riddlermarc · 15 Jun 2006 at 16:29

robmiller said:
Just use a session:

.. did think that but it won't stop people closing/re-opening their browser to break the session..

Sinque · 15 Jun 2006 at 16:47

riddlermarc said:
.. did think that but it won't stop people closing/re-opening their browser to break the session..

Why would someone waste their time to do that? :confused:

Beansprout · 15 Jun 2006 at 17:35

riddlermarc said:
.. did think that but it won't stop people closing/re-opening their browser to break the session..

The aim of this isn't to protect against people, it's to protect against bot spam.

Trying to protect against people is incredibly difficult and can never be effective without harming the experience of your legitimate visitors, which is an absolute no-no

riddlermarc · 16 Jun 2006 at 09:17

Beansprout said:
The aim of this isn't to protect against people, it's to protect against bot spam.

Trying to protect against people is incredibly difficult and can never be effective without harming the experience of your legitimate visitors, which is an absolute no-no

You can intercept session details using a sniffer and subsequently spoof the contents of the form/$_SESSION['lastMailed'] values to infinitely loop the mail sending.

I know this sounds a bit extreme, but the spammers have a pretty good arsenal at their disposal and if they find a site that's allowing emailing via a form they will have no qualms about abusing it

Think how easy it would be for them to intercept session details via an intermediary box, alter them (change the "lastMailed" value by 10mins less) and then send them on their way.. it's a fairly simple job, unfortunately.

I agree it's a trade-off between usability and security though

Sic · 16 Jun 2006 at 09:28

robmiller said:
Just use a session:

i'd do that, but make it a day.

could you do it with a cookie? or are cookies a big no-no now? i know they've been subject to abuse, but for this sort of thing, they'd work wouldn't they? that way, if they close the browser, it won't make a difference. i'd also be inclined to set the form to only accept an email daily. there's no need for it to be as low as 10 minutes.

Beansprout · 16 Jun 2006 at 10:40

riddlermarc said:
You can intercept session details using a sniffer and subsequently spoof the contents of the form/$_SESSION['lastMailed'] values to infinitely loop the mail sending.

I know this sounds a bit extreme, but the spammers have a pretty good arsenal at their disposal and if they find a site that's allowing emailing via a form they will have no qualms about abusing it Think how easy it would be for them to intercept session details via an intermediary box, alter them (change the "lastMailed" value by 10mins less) and then send them on their way.. it's a fairly simple job, unfortunately.

I agree it's a trade-off between usability and security though

How can you sniff session values :confused:

You can sniff IDs sure...infact I'm not sure bots would even take heed of sessions so it may be pointless?

CAPTCHAS are probably the best method against the spambots I think. But I think they're only obsessed with blog comments....I get at least 20x the amount of spam through my blog than all my 'send us a message' boxes

riddlermarc · 16 Jun 2006 at 11:26

Intercepting session information passing between client and server is a piece of cake.

Packet sniff the information passing from the client to the server (yes, you can even do this if HTTPS encrypted) either using a straight packet sniff or a "Man In The Middle" attack. The attacker could use a box to connect to the server and create a session id, which as it is transmitted is picked up by the attacker's second box that sits between the first box and the server.

(We've used packet sniffing and interception at work to read alert emails as they are transmitted across the lan, trying to debug the output of a dodgy web server, we can even read encrypted cookie information in much the same way.)

If the server allows session authentication using the type http://mysite.com/form.php?PHPSESSID=abc1234 then you can easily falsify the $_SESSION['lastMailed'] value and re-submit the page. This is called sesison fixation, a good read is the "A Simple Attack" example, shown here: http://shiflett.org/articles/security-corner-feb2004

With a different browser, or even an entirely different computer, go through the exact same initial steps. Upon visiting the URL for the first time, you will notice that you do not see 0. Rather, it recalls your previous session. Thus, you have impersonated the previous user. Now, if you consider that this all began with a session identifier being passed in the URL, you should see the basic danger that session fixation presents. Unlike a typical scenario, PHP did not generate the session identifier.

There are a few shortcomings to this simplistic type of attack. The most important shortcoming is that the target application must use the session identifier passed to it, otherwise this attack will fail. If your session mechanism is nothing more than session_start(), your applications are vulnerable, as the previous demonstration illustrates

.. check out the last paragraph.

Never, never trust anything on the client side for your security.

A good read is "Innocent Code: A Security Wake-Up Call for Web Programmers", also:
http://www.webappsec.org/projects/threat/classes/session_fixation.shtml

I'm definitely not dissing ANY of the advise/suggestions in this thread, it's just when you've had to do this to to get an extranet portal accredited to NSA-happy levels you sadly/interestingly learn a lot about interception and spoofing..!