 |
|
|
Insure yourself from spam! The Anti Spam Insurance Company - ProtectWebForm!
Forum - Security hole in the Perl code
| 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. |
|
|
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
|
Registered users: 86657
Forms protected: 48551
Further Reading & Anti Spam Resources:
Directory
|
|
