By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
464,545 Members | 869 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 464,545 IT Pros & Developers. It's quick & easy.

Form Security

P: n/a
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
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
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? Obviously, the random code key will be visible to the client, but
without the matching session variable, it will be useless.

Your thoughts?

Scott
Mar 9 '06 #1
Share this Question
Share on Google+
27 Replies

P: n/a
Scott 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
don't want to use the "enter the code shown in the image" method. I know
Even using a captcha (enter code shown in image) you can not be 100%
certain that the form posted was from your site...
the $_SERVER['HTTP_REFERER'] contents can be spoofed, so I thought of
doing something similar to this:
<snip>
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? Obviously, the random code key will be visible to the client, but
without the matching session variable, it will be useless.


Great for protecting against CSRF, but you can still "submit" the form
without opening your site up in a browser.

The session/token can be gotten around with things like curl. This is
the same method that Chris Shiflett outlined in his Essential PHP
Security book (phpsecurity.org) in Chapter 2.

By all means, use this method, but don't forget that you also need to
check that all the fields you expect are there, that you don't use any
fields that shouldn't be there, and that you filter all input and escape
all output.
Mar 9 '06 #2

P: n/a
Scott 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
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
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? Obviously, the random code key will be visible to the client, but
without the matching session variable, it will be useless.

Your thoughts?

Scott


Yes, that's precisely what you want to do. The function uniqid() can
also be used to generate the random key.

A check on HTTP_REFERER is actually sufficient too, since ordinary
users aren't going to be spoofing the Referer headers.

Mar 9 '06 #3

P: n/a
Chung Leong wrote:

A check on HTTP_REFERER is actually sufficient too, since ordinary
users aren't going to be spoofing the Referer headers.


Anyone that is running a firewall program like Norton's Personal
Firewall won't send the referrer... There are a number of web proxies
out there that do the same. Don't even bother with the HTTP_REFERER for
anything.
Mar 9 '06 #4

P: n/a
Thanks for the feedback guys. I know not to rely on HTTP_REFERER. I
think the plan is to use a combination of the method I described
earlier, along with filtering the input with regular expressions to
ensure I'm only getting valid data.

This is for a contact form, so if you can think of any more obvious
holes I need to watch for, let me know.

Thanks again!

Scott

Scott 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
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
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? Obviously, the random code key will be visible to the client, but
without the matching session variable, it will be useless.

Your thoughts?

Scott

Mar 10 '06 #5

P: n/a

Justin Koivisto wrote:
Chung Leong wrote:

A check on HTTP_REFERER is actually sufficient too, since ordinary
users aren't going to be spoofing the Referer headers.


Anyone that is running a firewall program like Norton's Personal
Firewall won't send the referrer... There are a number of web proxies
out there that do the same. Don't even bother with the HTTP_REFERER for
anything.


If HTTP_REFERER is empty, then bypass the test. Really, one should
consider each scenario carefully instead of just blindly repeating some
axiom. In this case, making cross-site posting not functional a
majority of the times is sufficient in deterring sites from doing it.

Mar 10 '06 #6

P: n/a
>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
Mar 10 '06 #7

P: n/a
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

Mar 10 '06 #8

P: n/a
Chung Leong wrote:
Scott 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
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
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? Obviously, the random code key will be visible to the client, but
without the matching session variable, it will be useless.

Your thoughts?

Scott

Yes, that's precisely what you want to do. The function uniqid() can
also be used to generate the random key.

A check on HTTP_REFERER is actually sufficient too, since ordinary
users aren't going to be spoofing the Referer headers.


In addition to what Justin said - if someone DOES want to spoof your
site, they will set HTTP_REFERER to your site. That check is worthless.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Mar 10 '06 #9

P: n/a
Jerry Stuckle wrote:
In addition to what Justin said - if someone DOES want to spoof your
site, they will set HTTP_REFERER to your site. That check is worthless.


I think you misunderstand the problem. Here's how an
auto-form-submission attack works:

1. Victim logs into site A
2. Victim is fooled into going to site B
3. Page at site B has a prefilled form targetting a script at site A.
Through Javascript the form is submitted without any intervention from
the victim.
4. The POST request arrives at site A and is processed as though the
victim has filled and submitted.

The solution proposed by the OP would stop this type of attacks but it
has to be implemented on every form. A check on the referer header
offers incomplete protection but can be easily implemented as a global
check.

In this scenario, it's the victim's computer which is making the POST,
thus spoofing isn't a real concern.

Mar 10 '06 #10

P: n/a
Chung Leong wrote:
Jerry Stuckle wrote:
In addition to what Justin said - if someone DOES want to spoof your
site, they will set HTTP_REFERER to your site. That check is worthless.

I think you misunderstand the problem. Here's how an
auto-form-submission attack works:

1. Victim logs into site A
2. Victim is fooled into going to site B
3. Page at site B has a prefilled form targetting a script at site A.
Through Javascript the form is submitted without any intervention from
the victim.
4. The POST request arrives at site A and is processed as though the
victim has filled and submitted.

The solution proposed by the OP would stop this type of attacks but it
has to be implemented on every form. A check on the referer header
offers incomplete protection but can be easily implemented as a global
check.

In this scenario, it's the victim's computer which is making the POST,
thus spoofing isn't a real concern.


I know *exactly* how auto-form-submission works. In fact, from your
posts here I expect I know a lot more about it than you do. I've been
in this field too many years. What you describe is only *one way* it can
happen. And it's not even the most common.

Much more common or 'bots which fake the user and post forms. They can
set anything they want in the headers, including HTTP_REFERER.

Another way is to act as a kind of proxy - intercepting the data as it
flows between the user and the site, changing the HTTP_REFERER and
anything else they want (unless you're using SSL).

And this is only the beginning of the number of ways it can be spoofed.
It is NOT a reliable source of information!
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Mar 10 '06 #11

P: n/a
Jerry Stuckle wrote:
I know *exactly* how auto-form-submission works. In fact, from your
posts here I expect I know a lot more about it than you do. I've been
in this field too many years. What you describe is only *one way* it can
happen. And it's not even the most common.


What I described was a vulnerability that can be countered by the
method proposed by the OP. Thus I assumed that is in fact what he is
referring to when he said auto-submission and responded accordingly. I
don't really feel the need to interpret other people's statements in
the worst light in order to show that I'm more knowledgeable.

Mar 10 '06 #12

P: n/a
Chung Leong wrote:
Jerry Stuckle wrote:
I know *exactly* how auto-form-submission works. In fact, from your
posts here I expect I know a lot more about it than you do. I've been
in this field too many years. What you describe is only *one way* it can
happen. And it's not even the most common.

What I described was a vulnerability that can be countered by the
method proposed by the OP. Thus I assumed that is in fact what he is
referring to when he said auto-submission and responded accordingly. I
don't really feel the need to interpret other people's statements in
the worst light in order to show that I'm more knowledgeable.


And I wasn't interpreting it in the "worst of light". I was
interpreting it in the light of simple security.

What he's proposing is false security - which is worse than no security
at all. At least with the latter you know you have potential
vulnerabilities.

And no, this isn't great security - but what he's proposing will NOT
stop auto-submission by any means.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Mar 11 '06 #13

P: n/a
Jerry Stuckle wrote:
And I wasn't interpreting it in the "worst of light". I was
interpreting it in the light of simple security.

What he's proposing is false security - which is worse than no security
at all. At least with the latter you know you have potential
vulnerabilities.


I really don't know what to say. The OP proposed a method for stopping
one type of cross-site scripting attack and here you are insisting that
it's crap because it doesn't stop bots.

Mar 11 '06 #14

P: n/a
Chung Leong wrote:
Jerry Stuckle wrote:
And I wasn't interpreting it in the "worst of light". I was
interpreting it in the light of simple security.

What he's proposing is false security - which is worse than no security
at all. At least with the latter you know you have potential
vulnerabilities.

I really don't know what to say. The OP proposed a method for stopping
one type of cross-site scripting attack and here you are insisting that
it's crap because it doesn't stop bots.


And it doesn't stop what he's trying to stop!

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Mar 11 '06 #15

P: n/a

Jerry Stuckle wrote:
Chung Leong wrote:
Jerry Stuckle wrote:
And I wasn't interpreting it in the "worst of light". I was
interpreting it in the light of simple security.

What he's proposing is false security - which is worse than no security
at all. At least with the latter you know you have potential
vulnerabilities.

I really don't know what to say. The OP proposed a method for stopping
one type of cross-site scripting attack and here you are insisting that
it's crap because it doesn't stop bots.


And it doesn't stop what he's trying to stop!


How so? Because...it doesn't stop bots?

Mar 11 '06 #16

P: n/a
Chung Leong wrote:
Jerry Stuckle wrote:
Chung Leong wrote:
Jerry Stuckle wrote:
And I wasn't interpreting it in the "worst of light". I was
interpreting it in the light of simple security.

What he's proposing is false security - which is worse than no security
at all. At least with the latter you know you have potential
vulnerabilities.
I really don't know what to say. The OP proposed a method for stopping
one type of cross-site scripting attack and here you are insisting that
it's crap because it doesn't stop bots.


And it doesn't stop what he's trying to stop!

How so? Because...it doesn't stop bots?


You can't see your solution is total trash? I'm sorry for you - and
even more so for your customers. I hope I never have to take over a
site you've worked on.

I'm not even going to bother to continue this discussion.

You go ahead and give people a false sense of security. I hope no one
gets hurt by your poor advice.

Meanwhile - I'll continue a conversation with the original poster - but
you're not worth the time.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Mar 12 '06 #17

P: n/a
Ok, Guys! I didn't mean for this discussion to get so heated!! Shake
mice and make up!

Now, back to the task at hand. Here's what I have so far...

This is a simple contact form. I have the following fields:
name, company, email, phone, subject (which is chosen from a dropdown
list), and message (a textarea field). I am also using a hidden field
called originator which contains the random code, as well as assigning
that same value to $_SESSION['code'] as discussed earlier.

The form contents are to be emailed, and possibly stored in a database.
We'll just worry about email for now.

When the form is submitted, the first thing I do is ensure the hidden
field matches the session variable. If it does, the form processing begins.

The form processing script so far does the following:

1)Take each of the text fields, run them through trim() and
strip_tags(), and assign them to a variable. That variable is then
checked against a regular expression. If they do not match the
expression, an error message such as "Please re-enter your email
address." will be displayed along with the form, and with all of the
information they just entered.

2) The subject must match one of the options in the drop down list. For
now, if it doesn't, I'm just pulling the plug with exit(), because this
obviously isn't valid data.

3) With the message, I want to be fairly flexible, mainly because this
is a contact form for potential customers to contact me, and I don't
want to annoy them into going elsewhere. I am running it through trim()
and strip_tags(), but haven't decided yet on a regular expression to
use, or even if I really need to.

After all this, if no error message has been generated, the form
contents are emailed to me. Since this data is being passed to a mail()
function, spam was pretty much my main concern. However, I'm wondering
also, would you deem it necessary to use escapeshellcmd() on this data
as well? I'm no Linux guru, so I don't know what someone could do to
cause problems with this script, other than spam me.

What further steps would you take on this script?

Scott

Jerry Stuckle wrote:
Chung Leong wrote:
Jerry Stuckle wrote:
Chung Leong wrote:

Jerry Stuckle wrote:
> And I wasn't interpreting it in the "worst of light". I was
> interpreting it in the light of simple security.
>
> What he's proposing is false security - which is worse than no
> security
> at all. At least with the latter you know you have potential
> vulnerabilities.

I really don't know what to say. The OP proposed a method for stopping
one type of cross-site scripting attack and here you are insisting that
it's crap because it doesn't stop bots.
And it doesn't stop what he's trying to stop!


How so? Because...it doesn't stop bots?


You can't see your solution is total trash? I'm sorry for you - and
even more so for your customers. I hope I never have to take over a
site you've worked on.

I'm not even going to bother to continue this discussion.

You go ahead and give people a false sense of security. I hope no one
gets hurt by your poor advice.

Meanwhile - I'll continue a conversation with the original poster - but
you're not worth the time.

Mar 12 '06 #18

P: n/a
Scott wrote:
Ok, Guys! I didn't mean for this discussion to get so heated!! Shake
mice and make up!

Now, back to the task at hand. Here's what I have so far...

This is a simple contact form. I have the following fields:
name, company, email, phone, subject (which is chosen from a dropdown
list), and message (a textarea field). I am also using a hidden field
called originator which contains the random code, as well as assigning
that same value to $_SESSION['code'] as discussed earlier.

The form contents are to be emailed, and possibly stored in a database.
We'll just worry about email for now.

When the form is submitted, the first thing I do is ensure the hidden
field matches the session variable. If it does, the form processing
begins.

The form processing script so far does the following:

1)Take each of the text fields, run them through trim() and
strip_tags(), and assign them to a variable. That variable is then
checked against a regular expression. If they do not match the
expression, an error message such as "Please re-enter your email
address." will be displayed along with the form, and with all of the
information they just entered.

2) The subject must match one of the options in the drop down list. For
now, if it doesn't, I'm just pulling the plug with exit(), because this
obviously isn't valid data.

3) With the message, I want to be fairly flexible, mainly because this
is a contact form for potential customers to contact me, and I don't
want to annoy them into going elsewhere. I am running it through trim()
and strip_tags(), but haven't decided yet on a regular expression to
use, or even if I really need to.

After all this, if no error message has been generated, the form
contents are emailed to me. Since this data is being passed to a mail()
function, spam was pretty much my main concern. However, I'm wondering
also, would you deem it necessary to use escapeshellcmd() on this data
as well? I'm no Linux guru, so I don't know what someone could do to
cause problems with this script, other than spam me.

What further steps would you take on this script?

Scott

Jerry Stuckle wrote:
Chung Leong wrote:
Jerry Stuckle wrote:

Chung Leong wrote:

> Jerry Stuckle wrote:
>
>
>> And I wasn't interpreting it in the "worst of light". I was
>> interpreting it in the light of simple security.
>>
>> What he's proposing is false security - which is worse than no
>> security
>> at all. At least with the latter you know you have potential
>> vulnerabilities.
>
>
>
>
> I really don't know what to say. The OP proposed a method for stopping
> one type of cross-site scripting attack and here you are insisting
> that
> it's crap because it doesn't stop bots.
>

And it doesn't stop what he's trying to stop!


How so? Because...it doesn't stop bots?


You can't see your solution is total trash? I'm sorry for you - and
even more so for your customers. I hope I never have to take over a
site you've worked on.

I'm not even going to bother to continue this discussion.

You go ahead and give people a false sense of security. I hope no one
gets hurt by your poor advice.

Meanwhile - I'll continue a conversation with the original poster -
but you're not worth the time.


First of all, you aren't going to stop spam from coming through your
mail form without stopping people from sending you mail.

But if all you're trying to do is stop someone from spamming you through
your form, I think you're overly concerned about a problem which doesn't
currently, and most probably won't exist.

Spammers get their money by sending millions of emails to millions of
different people. Sending one or two (or even a million) emails to one
person just isn't productive for them.

I have yet to see any significant SPAM come through contract forms which
have good checking against injection attacks. And the SPAM I have seen
go through those forms are all entered manually anyway.

My suggestion - just worry about the injection attacks. Don't worry
about anything else unless you see a problem.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Mar 12 '06 #19

P: n/a
Scott 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
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
doing something similar to this: .... Your thoughts?


Several people have discussed how it might be possible to use cURL as a
means to simulate user input. And the conclusion was essentially that
it is a somewhat moot point since one doesn't tend to get much spam via
forms.

There's another way that is perhaps not so fast as cURL which I find
quite convenient in automating browser simulation: it's an extension to
Firefox called GreaseMonkey. The standard usage, which I'm sure many
people already know, is that when you bring up a specific web site in
your browser (FF), it will customize the page (e.g. I just *might* have
a two line script that removes the ads at the top of the page on yahoo
mail).

However, this customization extends fairly far. For example, I can
schedule a FF to regularly start (hidden) in the background and
sequence through a series of pages (and if there are passwords, I don't
have to put them in the code since FF is storing them for me (though
the security on stored passwords is bad. If other people have access
to your machines, they have access to those stored passwords)).

The point is that if you want to access pages on an automated basis, FF
allows you to do it in a way that completely simulates using a browser
since you ARE using a browser. It may not be as fast (since the DOM
has to be built - heck, you're running an entire browser), and it may
not be at the same level of granularity (such as controlling the number
of redirections), and it's strictly client based (whereas cURL can be
run in a web server), but for most tasks it's more powerful and easier
to use.

Csaba Gabor from Vienna

Mar 12 '06 #20

P: n/a
Scott wrote:
This is a simple contact form. I have the following fields:
name, company, email, phone, subject (which is chosen from a dropdown
list), and message (a textarea field). I am also using a hidden field
called originator which contains the random code, as well as assigning
that same value to $_SESSION['code'] as discussed earlier.
As I said, the random code will indeed stop cross-site form submission.
That's not a useful exploit though in this instance, unless your script
is vulnerable to e-mail header injection.
1)Take each of the text fields, run them through trim() and
strip_tags(), and assign them to a variable. That variable is then
checked against a regular expression. If they do not match the
expression, an error message such as "Please re-enter your email
address." will be displayed along with the form, and with all of the
information they just entered.
Sensible enough, although strip_tags() is a rather blunt instrument.
2) The subject must match one of the options in the drop down list. For
now, if it doesn't, I'm just pulling the plug with exit(), because this
obviously isn't valid data.
That should stop mail injection, as the subject is presumably the only
field which goes into the header.
3) With the message, I want to be fairly flexible, mainly because this
is a contact form for potential customers to contact me, and I don't
want to annoy them into going elsewhere. I am running it through trim()
and strip_tags(), but haven't decided yet on a regular expression to
use, or even if I really need to.
I'm not aware of any exploit that can be triggered by contents in the
mail body.
After all this, if no error message has been generated, the form
contents are emailed to me. Since this data is being passed to a mail()
function, spam was pretty much my main concern. However, I'm wondering
also, would you deem it necessary to use escapeshellcmd() on this data
as well? I'm no Linux guru, so I don't know what someone could do to
cause problems with this script, other than spam me.
PHP pipes data to Sendmail through the standard input. There is not
need to call escapeshellcmd().
What further steps would you take on this script?


Don't see any. Seems like you're already getting more precautions that
you have to.

Mar 12 '06 #21

P: n/a
Scott wrote:
Ok, Guys! I didn't mean for this discussion to get so heated!! Shake
mice and make up!

Sounds like a Monty Python sketch. τΏΤ¬

--
*****************************
Chuck Anderson • Boulder, CO
http://www.CycleTourist.com
Integrity is obvious.
The lack of it is common.
*****************************
Mar 12 '06 #22

P: n/a
Pardon my intrusion, but I hope to clarify the topic being disputed.

Jerry Stuckle wrote:
I know *exactly* how auto-form-submission works. In fact, from your
posts here I expect I know a lot more about it than you do. I've been
in this field too many years. What you describe is only *one way* it can
happen. And it's not even the most common.


I'm always disappointed to see ego impact professional discourse. More
importantly, the "one way" Chung Leong describes is a type of attack
called cross-site request forgeries (CSRF), and the safeguard he
recommends is better than you seem to think.

Code can offer clarity, so consider a simple HTML form:

<form action="http://example.org/fire.php" method="POST">
<input type="text" name="employee" />
<input type="submit" value="FIRE" />
</form>

If I am authorized to fire employees, then a request sent by me to fire
a particular employee is successful. A CSRF attack would cause me to
send such a request without my knowledge.

Now, imagine that either of the following safeguards are implemented:

1. A unique, one-time token is included in the form as a hidden form
field as well as stored in my session. A request to fire an employee is
only considered valid if the token in the request matches the one in
the session.

2. Referer is checked. An optimal implementation would take into
account whether my browser typically includes Referer, but let's assume
it does.

Now, if you really think Chung Leong is wrong, you should be able to
demonstrate a CSRF attack that is successful despite such safeguards.
You might be right, but only proof will convince me.

Mar 22 '06 #23

P: n/a
Chris Shiflett wrote:
Pardon my intrusion, but I hope to clarify the topic being disputed.

Jerry Stuckle wrote:
I know *exactly* how auto-form-submission works. In fact, from your
posts here I expect I know a lot more about it than you do. I've been
in this field too many years. What you describe is only *one way* it can
happen. And it's not even the most common.

I'm always disappointed to see ego impact professional discourse. More
importantly, the "one way" Chung Leong describes is a type of attack
called cross-site request forgeries (CSRF), and the safeguard he
recommends is better than you seem to think.

Code can offer clarity, so consider a simple HTML form:

<form action="http://example.org/fire.php" method="POST">
<input type="text" name="employee" />
<input type="submit" value="FIRE" />
</form>

If I am authorized to fire employees, then a request sent by me to fire
a particular employee is successful. A CSRF attack would cause me to
send such a request without my knowledge.

Now, imagine that either of the following safeguards are implemented:

1. A unique, one-time token is included in the form as a hidden form
field as well as stored in my session. A request to fire an employee is
only considered valid if the token in the request matches the one in
the session.

2. Referer is checked. An optimal implementation would take into
account whether my browser typically includes Referer, but let's assume
it does.

Now, if you really think Chung Leong is wrong, you should be able to
demonstrate a CSRF attack that is successful despite such safeguards.
You might be right, but only proof will convince me.


That's fine if you use data kept in a session. But just using
HTTP_REFER is not a good way to do it. Whether it's set or not is
immaterial - it may be missing, or it can be forged quite easily.

I can easily write some PHP code (or Java, C/C++ or whatever) which will
simulate submission from your page. Not hard to do at all.

And BTW - I'm disappointed in the tone used by Chung Leong. I suspect
I've been doing this a hell of a lot longer than he has - and been
programming longer than he's been alive. I don't like people who talk
down to me. But it's also not the first time I've seen him do this to
people who disagree with him.

As for actually writing the program to do it - it's not worth my time or
bother. But I've written similar programs to run performance tests on
web servers. It's not hard to do at all if you understand the protocol.
You don't even need to use Curl.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Mar 22 '06 #24

P: n/a
> I can easily write some PHP code (or Java, C/C++ or whatever) which will
simulate submission from your page. Not hard to do at all.
Sure, but the important difference is that your PHP script is not me.
It can't fire people. In fact, your PHP script can't do anything more
than what you can already do with a browser. You've gained nothing.

A CSRF attack would cause me to send a request to fire someone.
I'm disappointed in the tone used by Chung Leong.
I won't pretend to know any history. I just prefer to ignore "tone" and
focus on technical details.
As for actually writing the program to do it - it's not worth my time or
bother.


I only suggested this, because I'm quite sure you can't do it. I'm not
trying to challenge you, because I'm sure you can write code to do
exactly what you're thinking, but that won't achieve anything. However,
if I'm wrong, an example would both clarify and prove your point.

Mar 22 '06 #25

P: n/a
Chris Shiflett wrote:
I can easily write some PHP code (or Java, C/C++ or whatever) which will
simulate submission from your page. Not hard to do at all.

Sure, but the important difference is that your PHP script is not me.
It can't fire people. In fact, your PHP script can't do anything more
than what you can already do with a browser. You've gained nothing.

A CSRF attack would cause me to send a request to fire someone.

I'm disappointed in the tone used by Chung Leong.

I won't pretend to know any history. I just prefer to ignore "tone" and
focus on technical details.

As for actually writing the program to do it - it's not worth my time or
bother.

I only suggested this, because I'm quite sure you can't do it. I'm not
trying to challenge you, because I'm sure you can write code to do
exactly what you're thinking, but that won't achieve anything. However,
if I'm wrong, an example would both clarify and prove your point.


Go back and look at the original problem:

"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 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 doing
something similar to this: <snip>"

And Chung's response:

"<snip> A check on HTTP_REFERER is actually sufficient too, since ordinary
users aren't going to be spoofing the Referer headers."

This is the statement I was arguing. And it's something which can be done quite
easily. And the code for it is actually quite simple.

Quite frankly, I don't care about whether you fire someone or not. It was not
part of the original problem.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Mar 22 '06 #26

P: n/a
Jerry Stuckle wrote:
Chris Shiflett wrote: <snip> Go back and look at the original problem:

"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 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 doing
something similar to this: <snip>"

And Chung's response:

"<snip> A check on HTTP_REFERER is actually sufficient too, since ordinary
users aren't going to be spoofing the Referer headers."

This is the statement I was arguing. And it's something which can be done quite
easily. And the code for it is actually quite simple.

<snip>

FWIW, I also think, by "auto-submitted" OP actually meant bots (not
CSRF) as he is also referring Captcha.

Anyway, glad to see Chris here in c.l.php; we have one more security
expert here now along with Chung.

--
<?php echo 'Just another PHP saint'; ?>
Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com/

Mar 23 '06 #27

P: n/a

R. Rajesh Jeba Anbiah wrote:
FWIW, I also think, by "auto-submitted" OP actually meant bots (not
CSRF) as he is also referring Captcha.


It's a stretch to interpret "from the form on my site, and not
auto-submitted from elsewhere" can be interpreted as "by a real user
and not by a bot." The construction "from elsewhere" is locative. We
don't use it to signify a different instrument or measure. In the
context of the original statement it clearly means "a form on a
different site" (as opposed to "the form on my site").

Mar 23 '06 #28

This discussion thread is closed

Replies have been disabled for this discussion.