> Well, anything you get back from the client will be as GET
> variables, I think. So, if your forms only use POST variables,
> and you've turned on track_vars, then you can get your variables
> through $HTTP_POST_VARS() like $foo=$HTTP_POST_VARS('foo');
> If I'm wrong on this, I'm sure some
'Boget, Chris' wrote:
>
> > Don't bother with checking the HTTP_REFERER - it can be easily forged.
> > There is a very simple solution to this problem -- validate the data from
> > the form!
> [snip]
> > You should be doing this anyway, since who knows what the user could
> > type in your input
Bruce
ps I may be a little late with this since I'm reading the digest!
Bruce Molyneux
emeraldsoft.co.uk
-Original Message-
From: Chris [mailto:[EMAIL PROTECTED]]
Sent: Friday, March 02, 2001 12:03 AM
To: php
Subject: Re: [PHP] Munging hidden/form variables
--
PHP General Ma
On Friday 02 March 2001 00:22, you wrote:
> I can think of one way that you can take in an attempy to prevent
> this.
> It is not totally fool proof but it will make it more difficult
> to send spoof data:
>
> 1) Check your HTTP refereer when the form is submitted. If the
> referer is not from you
Hi,
How about the following:
1. Assign a session id to the form every time you generate it.
2. Maintain that session id on the server side in a sort of cache for a
specific amount of time (say, T) only. Time-out and delete session id
entries that haven't been used within time perio
Addressed to: "Simon Garner" <[EMAIL PROTECTED]>
"Chris" <[EMAIL PROTECTED]>
"php" <[EMAIL PROTECTED]>
** Reply to note from "Simon Garner" <[EMAIL PROTECTED]> Fri, 2 Mar 2001 13:05:00
+1300
>
> So how do you verify that the logged in user is allowed to act on behalf
Addressed to: "Chris" <[EMAIL PROTECTED]>
[EMAIL PROTECTED]
** Reply to note from "Chris" <[EMAIL PROTECTED]> Thu, 1 Mar 2001 15:43:25 -0800
>
> Would it not be possible to have both the form page and the script page that
> handles the form be generated o the fly with random filenam
Addressed to: Kelly Corkill <[EMAIL PROTECTED]>
[EMAIL PROTECTED]
** Reply to note from Kelly Corkill <[EMAIL PROTECTED]> Thu, 1 Mar 2001 16:27:21 -0700
(MST)
>
>
> I would think you should be able to write a random string to a file when the
> form page is accessed, and carry a var
From: "Chris" <[EMAIL PROTECTED]>
> Not really,
> because the script filename is deleted and changed all the time, it
doesn't
> matter if they paste the name into the form, since the file will no longer
> exist.
>
It has to exist long enough for your form to post to it, which is long
enough for
No wait,
I see what you mean. You're right, sometimes the obvious is missed, but it
sounded cool.
> From: "Chris" <[EMAIL PROTECTED]>
>
> > Would it not be possible to have both the form page and the script page
> that
> > handles the form be generated o the fly with random filenames?
> >
> > Th
Not really,
because the script filename is deleted and changed all the time, it doesn't
matter if they paste the name into the form, since the file will no longer
exist.
> From: "Chris" <[EMAIL PROTECTED]>
>
> > Would it not be possible to have both the form page and the script page
> that
> > h
> > I'm already doing this. However, if I have a hidden
> > variable containing a value of the current user I'm
> > working with, that value can be changed to something
> > else and it would pass the test. However, I need to find a
> > way to determine if something like that has happened.
>
From: "Boget, Chris" <[EMAIL PROTECTED]>
> I'm already doing this. However, if I have a hidden variable containing
> a value of the current user I'm working with, that value can be changed
> to something else and it would pass the test. However, I need to find a
> way to determine if something
From: "Chris" <[EMAIL PROTECTED]>
> Would it not be possible to have both the form page and the script page
that
> handles the form be generated o the fly with random filenames?
>
> The form page would point to the random generated script page, and the
> script page could delete itself after it i
> Don't bother with checking the HTTP_REFERER - it can be easily forged.
> There is a very simple solution to this problem -- validate the data from
> the form!
[snip]
> You should be doing this anyway, since who knows what the user could
> type in your input box. Nevermind if somebody makes a c
Would it not be possible to have both the form page and the script page that
handles the form be generated o the fly with random filenames?
The form page would point to the random generated script page, and the
script page could delete itself after it is proccessed. You would also want
a cron to
From: "Boget, Chris" <[EMAIL PROTECTED]>
> It is possible (I've done it) to find out all the variables
> that make up a form on a particular site, generate a
> similar form on your site with that form's action being
> the CGI/PHP script that the particular site uses to process
> the form once sub
> I can think of one way that you can take in an attempy to prevent
> this. It is not totally fool proof but it will make it more difficult
> to send spoof data:
> 1) Check your HTTP refereer when the form is submitted. If the
> referer is not from your host then don't process the form.
> Of cours
PROTECTED] wrote:
> Date: Thu, 1 Mar 2001 16:18:08 MST
> From: [EMAIL PROTECTED]
> To: "Boget, Chris" <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> Subject: Re: [PHP] Munging hidden/form variables
>
> Addressed to: "Boget, Chris" <[EMAIL PROTECTED]>
>
I can think of one way that you can take in an attempy to prevent
this.
It is not totally fool proof but it will make it more difficult
to send spoof data:
1) Check your HTTP refereer when the form is submitted. If the
referer is not from your host then don't process the form.
Of course this can
Addressed to: "Boget, Chris" <[EMAIL PROTECTED]>
[EMAIL PROTECTED]
** Reply to note from "Boget, Chris" <[EMAIL PROTECTED]> Thu, 1 Mar 2001 14:26:16
-0600
>
> --_=_NextPart_001_01C0A28D.E2F45248
> Content-Type: text/plain;
> charset="iso-8859-1"
>
> It is possible (I've d
> Is there any way to defend against this? Is there any way
> to ensure that when a form is submitted that the submission
> request originated from your site/domain and not somewhere
> else?
Knowing that $HTTP_REFERER cannot be relied on as containing
valid data (as some browsers don't support i
22 matches
Mail list logo
