|
|
Posted by Gordon Burditt on 03/10/06 02:55
>I've been trying to come up with a way to ensure user input is coming
>from the form on my site, and not auto-submitted from elsewhere, and I
Why? What are you *really* trying to accomplish?
If the original objective was to drain the swamp, and you find
yourself assigning Social Security numbers to alligators chomping
your ass to limit them to one bite each, you need to step back and
re-evaluate what you are doing.
Remember, if a browser can return the values of hidden fields and/or
cookies, so can bots. CURL is pretty good at this.
If the original objective is for the browser to not bypass
the input field checking done by Javascript, you're toast anyway,
as Javascript can be Turned Off(tm). You need the checks
server-side anyway.
Captchas can be defeated by outsourcing the task to humans (often
unwitting dupes). The bot writer puts up a web page offering
something "valuable", say, free porn, and sends responders the same
captcha you sent the bot. They respond with the code to get their
free porn. Actually providing the porn is optional. I believe I
have heard of spammers actually using this technique. But for
someone to bother with this, you have to be protecting something
valuable to the bot.
I didn't see any code to prevent the bot from doing the equivalent
of "SUBMIT, BACK, repeat". Even if you put that code in, you still
have a problem. If the original objective is to stop the bots from
pounding your server, there's nothing preventing them from getting
a new page from your server with the funky code on that, then
submitting it, thereby doubling the number of hits on your server.
You're really going to have trouble if the bot does the equivalent
of Go to URL, get page, submit it with values filled in, forget
all session cookies, and repeat. This looks like a bunch of people
with different browsers all visiting your page.
If the original problem is to prevent ballot-box stuffing in a vote
or a poll, you're stuck with one of two basic methods: (a) issue
credentials to voters and make sure credentials can only be used
once, or (b) try to identify users on the fly by some characteristic
of their computer, such as IP address, browser ID string, cookie,
or some combination of these, all of which have problems with both
excluding legitimate voters and allowing cheaters. It's going to
be difficult to get a reliable vote or survey if you don't use
method (a), but this may require effort like a professional survey
firm uses. (b) is doomed to failure, but you can try to make
cheating non-trivial. Remember, a dedicated fan determined to stuff
a ballot box can cast thousands of ballots a day MANUALLY.
>don't want to use the "enter the code shown in the image" method. I know
>the $_SERVER['HTTP_REFERER'] contents can be spoofed, so I thought of
The most serious problem with 'HTTP_REFERER' is that there are lots
of users who can't UN-block it to save their lives. Perhaps it's
their own firewall, but they don't know how to configure it. Perhaps
it's an office firewall.
Then there's the hardcore bad guys who can spoof it.
>doing something similar to this:
>
><?php
>session_start();
>$code = mt_rand(0,1000000);
>$_SESSION['code'] = $code;
>?>
>
>Then in my form have:
><input type="hidden" name="originator" value="<?=$code?>">
>
>On the page receiving the form:
>
><?php
>session_start();
>if(isset($_POST['originator'])) {
> if($_POST['originator'] == $_SESSION['code']) {
> // process the form
> }
>}
>?>
>
>I'm looking for feedback on this method. Do you think this is an
>effective way to ensure the input you're receiving is indeed from your
>form?
Ensuring that the input is from your form is meaningless, a lot
like preventing air disasters by permitting only *LICENSED* bombs
on board. WHat are you REALLY trying to accomplish?
>Obviously, the random code key will be visible to the client, but
>without the matching session variable, it will be useless.
The client can submit both the random code key with the form AND
pass through the session cookie. Browsers do this quite well.
It's not that hard for a bot to do it (see CURL).
>Your thoughts?
CURL is very good at fetching a URL, picking up a cookie from it,
and using it to submit the form it fetched.
Gordon L. Burditt
Navigation:
[Reply to this message]
|