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
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 your host
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 Mailing List
'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 box.
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 someone
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 submitted, modify the values for the form
variables to
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 it)?
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 done it)
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
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]
[EMAIL PROTECTED]
** Reply to not
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
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
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 copy
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 is
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 like
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.
That's
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
handles
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?
The form page
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 their
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 variable
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 filenames?
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 of
the
22 matches
Mail list logo
