Posted by Scott on 03/10/06 04:55

It's just a contact form. The end result will be emailed, and possibly
stored in a database. It's no gateway into bank accounts or anything
along those lines. I had already planned on filtering the data with
regular expressions, strip_tags(), etc. when I thought of the
aforementioned $_SESSION['code'] method, and just wanted to bounce the
idea off of the group.

I liked your alligator analogy, though. Thanks for that!

Scott

Gordon Burditt wrote:
>>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

[Back to original message]