security of post variables

[Marcus]

Hi All,

I was wondering if there is a way to ensure that when submitting forms
and using POST vars, the page sending the form resides on the same
server as the destination page specified in the form action.

For example, if I have a page on a live server that accepts POST
variables, I can simply create a second page on my local host or any
other server for that matter that lets me send any values I want for
these POST variables.

I have error checks on all user submitted data, but I was wondering if
there is anything else that I should do to make accepting these
variables more secure.

Thanks a bunch.

[Malcolm Dew-Jones]

Marcus (Ju********@aol.com) wrote:
: Hi All,

: I was wondering if there is a way to ensure that when submitting forms
: and using POST vars, the page sending the form resides on the same
: server as the destination page specified in the form action.

: For example, if I have a page on a live server that accepts POST
: variables, I can simply create a second page on my local host or any
: other server for that matter that lets me send any values I want for
: these POST variables.

: I have error checks on all user submitted data, but I was wondering if
: there is anything else that I should do to make accepting these
: variables more secure.

: Thanks a bunch.

What ever you do, don't use 'referer', cause it can be faked.

I must ask, since the data is only seen by your server, then what does it
matter where the form came from?

The data you receive can always be faked. In any application, you must
always validate your input. Proper validation is one of the essential
steps in ensuring you are secure.

--

This space not for rent.

[Andy Hassall]

On Fri, 01 Apr 2005 21:09:38 GMT, Marcus <Ju********@aol.com> wrote:

I was wondering if there is a way to ensure that when submitting forms
and using POST vars, the page sending the form resides on the same
server as the destination page specified in the form action.
Pages don't send forms. Clients do.
For example, if I have a page on a live server that accepts POST
variables, I can simply create a second page on my local host or any
other server for that matter that lets me send any values I want for
these POST variables.

I have error checks on all user submitted data, but I was wondering if
there is anything else that I should do to make accepting these
variables more secure.

If you check the data, does it matter where it comes from?

--
Andy Hassall / <an**@andyh.co.uk> / <http://www.andyh.co.uk>
<http://www.andyhsoftware.co.uk/space> Space: disk usage analysis tool

[Micha³ Wo¼niak]

Marcus napisa³:

Hi All,

I was wondering if there is a way to ensure that when submitting forms
and using POST vars, the page sending the form resides on the same
server as the destination page specified in the form action.

For example, if I have a page on a live server that accepts POST
variables, I can simply create a second page on my local host or any
other server for that matter that lets me send any values I want for
these POST variables.

I have error checks on all user submitted data, but I was wondering if
there is anything else that I should do to make accepting these
variables more secure.

Thanks a bunch.

Hmmm... One solution is using Sessions. But it can be a ittle overshot
for what you are looking for.

Cheers
Mike

[Marcus]

Malcolm Dew-Jones wrote:

Marcus (Ju********@aol.com) wrote:
: Hi All,

: I was wondering if there is a way to ensure that when submitting forms
: and using POST vars, the page sending the form resides on the same
: server as the destination page specified in the form action.

: For example, if I have a page on a live server that accepts POST
: variables, I can simply create a second page on my local host or any
: other server for that matter that lets me send any values I want for
: these POST variables.

: I have error checks on all user submitted data, but I was wondering if
: there is anything else that I should do to make accepting these
: variables more secure.

: Thanks a bunch.

What ever you do, don't use 'referer', cause it can be faked.

I must ask, since the data is only seen by your server, then what does it
matter where the form came from?

The data you receive can always be faked. In any application, you must
always validate your input. Proper validation is one of the essential
steps in ensuring you are secure.

--

This space not for rent.

To the best of my understanding, if I use POST and the user say, selects
an item from a menu or an array of radio buttons or something, there is
no way to fake this info as one could using GET, provided that user is
using my interface.

However, I could just create a second page with say a textbox with the
same form element name, and then upon submission my receiving script
would receive whatever the user enters instead of my predefined choices.

It just seemed to me that given this scenario, even with error checks,
it would be much easier for something to slip by (some case I did not
anticipate) rather than the smaller number of cases that could occur if
the user were forced to choose an option from a predefined list.

Am I just thinking too deeply into this? :-)

[Malcolm Dew-Jones]

Marcus (Ju********@aol.com) wrote:
: Malcolm Dew-Jones wrote:
: > Marcus (Ju********@aol.com) wrote:
: > : Hi All,
: >
: > : I was wondering if there is a way to ensure that when submitting forms
: > : and using POST vars, the page sending the form resides on the same
: > : server as the destination page specified in the form action.
: >
: > : For example, if I have a page on a live server that accepts POST
: > : variables, I can simply create a second page on my local host or any
: > : other server for that matter that lets me send any values I want for
: > : these POST variables.
: >
: > : I have error checks on all user submitted data, but I was wondering if
: > : there is anything else that I should do to make accepting these
: > : variables more secure.
: >
: > : Thanks a bunch.
: >
: > What ever you do, don't use 'referer', cause it can be faked.
: >
: > I must ask, since the data is only seen by your server, then what does it
: > matter where the form came from?
: >
: > The data you receive can always be faked. In any application, you must
: > always validate your input. Proper validation is one of the essential
: > steps in ensuring you are secure.
: >
: > --
: >
: > This space not for rent.

: To the best of my understanding, if I use POST and the user say, selects
: an item from a menu or an array of radio buttons or something, there is
: no way to fake this info as one could using GET, provided that user is
: using my interface.

But unless they are using a computer you provide, (and even then not in
practise) you cannot be sure they are using your interface.

: However, I could just create a second page with say a textbox with the
: same form element name, and then upon submission my receiving script
: would receive whatever the user enters instead of my predefined choices.

Exactly. There is no way to prevent that.

--

This space not for rent.

[Micha³ Wo¼niak]

: However, I could just create a second page with say a textbox with
: the same form element name, and then upon submission my receiving
: script would receive whatever the user enters instead of my
: predefined choices.

Exactly. There is no way to prevent that.

Just to get you completely paranoid, there are ways of submitting "POST"
data without even the use of a webclient (there's a php script doing
exactly that somewhere on www.php.net, in the section concerning POST, I
believe). So, one could write a program, php script, bash (!) script
(not to mention curl), that would send data using POST. An you have no
control over this.

IMHO, the best solution if the data is of critical importance, is
authentication and sessions. This way, even if someone acutally writes
such a script/program, they would have to supply the proper login data
anyway. :)

Cheers
Mike

[R. Rajesh Jeba Anbiah]

Marcus wrote:
<snip>

I have error checks on all user submitted data, but I was wondering if there is anything else that I should do to make accepting these
variables more secure.

Probably Captcha.

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

[Andy Hassall]

On 2 Apr 2005 10:17:01 -0800, "R. Rajesh Jeba Anbiah"
<ng**********@rediffmail.com> wrote:

Marcus wrote:
<snip>

I have error checks on all user submitted data, but I was wondering

if

there is anything else that I should do to make accepting these
variables more secure.

Probably Captcha.

But that wouldn't do anything for the condition the OP asked for, namely that
"the page sending the form resides on the same server as the destination page
specified in the form action.", since it doesn't stop someone reading the
captcha, and creating their own form elsewhere with the appropriate value
filled in.

--
Andy Hassall / <an**@andyh.co.uk> / <http://www.andyh.co.uk>
<http://www.andyhsoftware.co.uk/space> Space: disk usage analysis tool

[Chung Leong]

"Andy Hassall" <an**@andyh.co.uk> wrote in message
news:ok********************************@4ax.com...

If you check the data, does it matter where it comes from?

Sometimes, yes. The form submission could be triggered by Javascript
contained in a malious page that the user went to. The best example is
probably message forums. If users are allowed to post hyperlinks, then an
attacker could link to a page which automatically posts back into the forum.
Anyone who clicks on the link could end up posting a message of the
attacker's choosing under his/her name.

This is really a flaw in the HTTP specs. The referer field should be defined
as a must-sent when referring page is in the same domain (or whatever
criteria for determing when a cookie is sent). The fact that you can omit
the field makes it useless.

[R. Rajesh Jeba Anbiah]

Andy Hassall wrote:

On 2 Apr 2005 10:17:01 -0800, "R. Rajesh Jeba Anbiah"
<ng**********@rediffmail.com> wrote:

I have error checks on all user submitted data, but I was

wonderingif

there is anything else that I should do to make accepting these
variables more secure.
Probably Captcha.

But that wouldn't do anything for the condition the OP asked for,

namely that "the page sending the form resides on the same server as the destination page specified in the form action.", since it doesn't stop someone reading the captcha, and creating their own form elsewhere with the appropriate value filled in.

I think, it depends upon the implementation of the Captcha--if the
random string is generated in the Captcha script itself, it will easily
break as you say. But, if the random string is generated in the image
embedding script, it could help here. Something like:

<?php
//main.php
//...
$_SESSION['random_str'] = rand(100, 999);
?>
<img src="captcha.php" />
<!--end main.php-->

and

<?php
//captcha.php
DrawString($_SESSION['random_str']);
?>

Also, strongly agreeing that anything can be easily broken--as long
as we have cookie handling spiders and libraries like cURL.

If OP is interested in some dirty (broken) referrer based hack, he
may fiddle with $_SERVER['HTTP_REFERER'] and alternatively
http://in.php.net/session#ini.session.referer-check

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

[Malcolm Dew-Jones]

Chung Leong (ch***********@hotmail.com) wrote:
: "Andy Hassall" <an**@andyh.co.uk> wrote in message
: news:ok********************************@4ax.com...
: > If you check the data, does it matter where it comes from?

: Sometimes, yes. The form submission could be triggered by Javascript
: contained in a malious page that the user went to. The best example is
: probably message forums. If users are allowed to post hyperlinks, then an
: attacker could link to a page which automatically posts back into the forum.
: Anyone who clicks on the link could end up posting a message of the
: attacker's choosing under his/her name.

: This is really a flaw in the HTTP specs. The referer field should be defined
: as a must-sent when referring page is in the same domain (or whatever
: criteria for determing when a cookie is sent). The fact that you can omit
: the field makes it useless.

Oh dear, the above statement is so bogus, please figure out how to
understand this.

The HTTP specs are irrelevent. You do not control the client and
therefore cannot trust the data.

[R. Rajesh Jeba Anbiah]

R. Rajesh Jeba Anbiah wrote:

Andy Hassall wrote: <snip> I think, it depends upon the implementation of the Captcha--if the random string is generated in the Captcha script itself, it will easily break as you say. But, if the random string is generated in the image
embedding script, it could help here. Something like:

<snip>
Doh! In that case why Captcha, better a session-form based random
string alone.

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

[Tim Roberts]

Marcus <Ju********@aol.com> wrote:

To the best of my understanding, if I use POST and the user say, selects
an item from a menu or an array of radio buttons or something, there is
no way to fake this info as one could using GET, provided that user is
using my interface.

The only difference between a GET request and a POST request is where the
parameters are placed. One is at the end of the GET line, one is after the
headers. No other difference.

However, I'm not sure it is useful to think of this as a "faked" request.
Your web page is offering services. If those services depend on earlier
context, you will need to provide somoe kind of session identification so
you can associate them. If not, why should you care whether the request
was generated from a page you wrote, or from a script that I happen to be
using to make my job easier?
--
- Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.