Sign in:
Username:
Password:  
»Forgot your password?

Home | Forum | How to Protect Your Web Form | How to Protect Your Email | Sign Up

Insure yourself from spam! The Anti Spam Insurance Company - ProtectWebForm!

Forum - Security hole in the Perl code

PostMessage
Pseudonym
2006-09-23 06:02:48
Greetings everyone, and thanks for the great service.

We're still getting some spam through one of our web forms. I took a
look at your code, and I've discovered what the problem is. (We're
only using the Perl code; it's possible that the other versions have a
similar problem.)

This is the logic of the code:

use LWP::Simple;

my $protectwebformresult =
get("http://protectwebform.com/verify/number_code_".$ENV{'REMOTE_ADDR'}."/".$in{'protectwebformcode'});

if ($protectwebformresult contains the code which says that you are
not authorised) {
# Not authorised error
}
if ($protectwebformresult contains the string which says that you were
not authorised) {
# Captcha mismatch error
die;
}
# Fall through

Putting something like this in the protectwebform field:

I am a spammer, <a href="http://foo.com/bar?baz">buy</a> my scammy
product

will make the fragment always pass.

There are actually three (!) security holes in this fragment which all
happen to line up.

The first is that the contents of the protectwebform field are
appended to a URL, no matter what was typed into this field. (Rule 1:
Never trust data from untrusted source.)

The second problem is that LWP::Simple::get returns undef if it fails,
as happens if the URL is malformed, and this is not checked for.
(Rule 2: Always check for error conditions.)

The third problem is that the fragment checks for the presence of a
string which says "this failed". If it's NOT present, as happens if
LWP::Simple::get returns undef, the check effectively succeeds. (Rule
3: Fail safe. Err on the side of not letting people in.)

To fix point 1, I suggest passing the field data through uri_escape
before appending it to the URL.

To fix point 2, add a check to look for undef, and bomb out in that
case.

To fix point 3, look for the absence of the success check rather than
the presence of the fail check.

Someone might like to audit the other versions to see if it suffers
from the same problems.
oleg
2006-09-23 11:30:17
Thanks Pseudonym,
we will take care of this problem and update all required versions
shortly.
bonni
2006-09-24 02:07:36
Fixed it. :) (This isn't Pseudonym; it's Pseudonym's wife, though).

It was a very simple and easy fix:

Original line:

if($protectwebformresult =~ m/<verification result="no"/) {

Should be:

if($protectwebformresult !~ m/<verification result="yes"/) {

We've tested this considerably and it definitely appears to work
perfectly. :)

Thanks very much for providing this service, it's a really good thing.
:)

bonni






Post Reply:

You must be logged in to reply.
Post message
Name: 
Email: 
Url: 




Registered users: 87901

Forms protected: 48551

Further Reading & Anti Spam Resources:

Directory


    ©Copyright 2006 ProtectWebForm.com. All rights reserved. Read our Privacy Policy

Page copy protected against web site content infringement by Copyscape