RE: [PHP] Munging hidden/form variables
> 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 will let me know.
Well, if there is a GET and a POST variable of the same name,
the POST value will be used instead. This is a built in security
measure of either PHP, Apache or both.
However, what you suggest does not prevent someone from
viewing and saving the source to their machine, modify the
form variables and submit the version of the form on their local
machine. Doing this will set everything as a POST and will
bypass the check suggested above.
This goes back to what I said initially. I can check to see if
the REQUEST_METHOD is POST and check the HTTP_REFERER
to see if it is from our host (which it wouldn't be if the user
submitted the form from their local machine. However, the
problem arises in that the HTTP_REFERER isn't always set
because some browsers do not send that information to the
server.
So this leads me to the (another) question I had, but am not
sure anyone said, at what time and/or in what instances and/or
what browsers/versions do not send the HTTP_REFERER
information?
I really appreciate all the help and information everyone has
given with regards to this issue. You guys are great.
Chris
RE: [PHP] Munging hidden/form variables
'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. Nevermind if somebody makes a copy of your
> > form. Never never never trust the client.
>
> 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 where my
> description of what I was thinking of doing came from.
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 will let me know.
--
Curt Seeliger
OAO Corporation, EPA/WED contractor
541/754-4638
[EMAIL PROTECTED]
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP] Munging hidden/form variables
It's probably a good idea to stop using hidden form fields. Save your state data securely, use sessions etc. Then you only have the usual problem of validating the data you wanted the user to send you , instead of also the hidden data you were hoping they would leave alone! HTH Cheers 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 Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] Munging hidden/form variables
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 then don't process the form. > Of course this can be faked quite easily if this person knows > what (s)he doing. And it would prevent people who don't sent Referrer headers from using the form -- Christian Reiniger LGDC Webmaster (http://sunsite.dk/lgdc/) The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence. - Edsger W. Dijkstra -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] Munging hidden/form variables
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 period T. 3. Have the form page refresh itself every T minutes/seconds etc. (for the convenience[1] of a genuine user). 4. Ensure that a form with a particular session id can be submitted only once. 1. Deleting the session id from the session id cache the first time a form is submitted should ensure this. This would lead to the concept of "using up" or "consuming" a session id. 5. Don't process any form that doesn't have a corresponding valid session id stored in the session id cache. While the approach I have outlined above will be susceptible to eavesdropping (session ids can be sniffed out), that can easily be taken care of by sending out the form over an HTTPS session. Of course, if the attacker sets up a robot to request forms from the actual server and then keeps on submitting spurious data, you're in trouble. There's very little that can be done against an attack of this sort. You could perhaps try to keep track of the time difference between the serving of the form and its submission. This too, is open to subversion. Please do point out any loopholes you find in the approach mentioned above. [1] If a "genuine" user stops to do something else after partially filling out the form, then this setup could become a nuisance. "Boget, Chris" wrote: > Well, this was part of what I was going to do. I was going to check > to see if the request method was post and if the referer was from > our host (not just the form/page). If all that was true, then process > the form. If not, don't. > However, I know that the $HTTP_REFERER variable is not at all > reliable. On that note, what browsers/versions would not send this > information for Apache/PHP to set? I know it is because of the browser > that the client is using that this variable is unreliable. But what those > browsers/versions are, I don't know and am hoping someone can > answer. > > Chris -- Regards, Harshdeep Singh Jawanda. ~~~ Member of Technical Staff, [O]+91-020-5676700 X-474 Persistent Systems Pvt. Ltd., [R]+91-020-5890053 [EMAIL PROTECTED] [EMAIL PROTECTED] ~~~ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] Munging hidden/form variables
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 other ID? You just have to keep reverifying that the client is allowed > to do what they're doing. > I suggest it is time to take a look at sessions: http://www.php.net/manual/en/html/ref.session.html Things get easier if you only allow a small group of people into the site. You won't be able to keep someone who knows a valid username and password from exploiting things, but you can limit the possible exploits to what you allow a user to do. I suggest you use a SSL secured server any time you are sending passwords across the net. That way they can only be intercepted by someone with access to the authorized user's machine, or someone with access to your machine. SSL is not magic, all it does is prevent someone along the way from snooping. When someone enters a valid username and password, create a session and store all the temporary data on the server. If it is never sent to the browser, there is no way for someone on the other end to modify it. A PHP session ID is a reasonably secure random number that is hard to guess. It is even harder to guess the session ID, user name and password all at the same time. That still does not stop me, a valid user who can use the system from a browser, from being able to write a script that fakes my user action. It does allow you much more control to make sure that neither me or my robot are able to do anything you don't want me to do. > It's a chore I know - security usually is :( Yep! Rick Widmer Internet Marketing Specialists http://www.developersdesk.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] Munging hidden/form variables
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? > > 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 delete any files in case they never bothered to submit the form. > > Can anyone see a problem with this? That makes it a little harder, but I can just view source and hit the page a couple of times, and I will see that the Action="" in the tag changes and know I have to go back one step to get it. If I have to I can emulate a person coming in from the home page, walking all the links to the form, then entering it. I hit the page that generates the random name. It returns the random name. I use it in my following request to get the form. I fill in the form and send it. Maybe you can make it 'not worth the effort' for a hacker, but be careful you don't make it 'not worth the errort' for your legitimate visitors. The big problem you have, is if I can fill it in by hand, I can watch what passes over the network and write a program to emulate it. What a browser can do is very limited, and even things like headers that are not normaly visible when you view source are visible to a network sniffer. Rick Widmer Internet Marketing Specialists http://www.developersdesk.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] Munging hidden/form variables
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 with the action then have the > recipient compare. Presents other challenges but should give you that > comforting feeling he was looking for. ALl that means is that I have to load your form, identify your magic number, and send it when I return the form data. That makes it a little harder, but only a little. The magic number will be in a hidden field, but hidden fields are not all that 'hidden' when you View Source. Rick Widmer Internet Marketing Specialists http://www.developersdesk.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] Munging hidden/form variables
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 form to post to it as well. > Yes, but that's not going to do me any good because it is > valid for one user to act on behalf of another (as a broker, > if you will). So the currently logged in user might not be > the one who's ID is in the hidden field... So how do you verify that the logged in user is allowed to act on behalf of the other ID? You just have to keep reverifying that the client is allowed to do what they're doing. It's a chore I know - security usually is :( Cheers Simon Garner -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] Munging hidden/form variables
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 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 delete any files in case they never bothered to submit the form. > > > > Can anyone see a problem with this? > > > > > > > > That is not going to solve the problem, because a cracker can just copy and > paste the random filename of the script page into their form page. > > Bogus form data is a problem for everyone working with html forms. You're > trying to find an esoteric solution to the problem, while overlooking the > obvious: just check if the data is valid. > > > Regards > > Simon Garner > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] Munging hidden/form variables
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 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 delete any files in case they never bothered to submit the form. > > > > Can anyone see a problem with this? > > > > > > > > That is not going to solve the problem, because a cracker can just copy and > paste the random filename of the script page into their form page. > > Bogus form data is a problem for everyone working with html forms. You're > trying to find an esoteric solution to the problem, while overlooking the > obvious: just check if the data is valid. > > > Regards > > Simon Garner > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP] Munging hidden/form variables
> > 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 where my description of what I was thinking of > > doing came from. > Does the user have a password? You need to check if the > password matches as well. Yes, but that's not going to do me any good because it is valid for one user to act on behalf of another (as a broker, if you will). So the currently logged in user might not be the one who's ID is in the hidden field... Chris
Re: [PHP] Munging hidden/form variables
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 that has happened. That's where my > description of what I was thinking of doing came from. > > Chris > Does the user have a password? You need to check if the password matches as well. Cheers Simon Garner -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] Munging hidden/form variables
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 proccessed. You would also want > a cron to delete any files in case they never bothered to submit the form. > > Can anyone see a problem with this? > > That is not going to solve the problem, because a cracker can just copy and paste the random filename of the script page into their form page. Bogus form data is a problem for everyone working with html forms. You're trying to find an esoteric solution to the problem, while overlooking the obvious: just check if the data is valid. Regards Simon Garner -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP] Munging hidden/form variables
> 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 of your > form. Never never never trust the client. 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 where my description of what I was thinking of doing came from. Chris
Re: [PHP] Munging hidden/form variables
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 delete any files in case they never bothered to submit the form. Can anyone see a problem with this? > > 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 be faked quite easily if this person knows > > what (s)he doing. > > Well, this was part of what I was going to do. I was going to check > to see if the request method was post and if the referer was from > our host (not just the form/page). If all that was true, then process > the form. If not, don't. > However, I know that the $HTTP_REFERER variable is not at all > reliable. On that note, what browsers/versions would not send this > information for Apache/PHP to set? I know it is because of the browser > that the client is using that this variable is unreliable. But what those > browsers/versions are, I don't know and am hoping someone can > answer. > > Chris > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] Munging hidden/form variables
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 submitted, modify the values for the form > variables to be anything you want and submit the form > that resides on your site. This will basically submit totally > fabricated data to the foriegn site and possibly screw them > up somehow and/or in some way. > > 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? > > Any help would be greatlyl appreciated. > > Chris > 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! I.e. if you're expecting $foo to be an integer from 2 to 5, look at intval($foo) and see if it's >=2 and <=5. You should be doing this anyway, since who knows what the user could type in your input box. Nevermind if somebody makes a copy of your form. Never never never trust the client. Cheers Simon Garner -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP] Munging hidden/form variables
> 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 be faked quite easily if this person knows > what (s)he doing. Well, this was part of what I was going to do. I was going to check to see if the request method was post and if the referer was from our host (not just the form/page). If all that was true, then process the form. If not, don't. However, I know that the $HTTP_REFERER variable is not at all reliable. On that note, what browsers/versions would not send this information for Apache/PHP to set? I know it is because of the browser that the client is using that this variable is unreliable. But what those browsers/versions are, I don't know and am hoping someone can answer. Chris
Re: [PHP] Munging hidden/form variables
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 with the action then have the recipient compare. Presents other challenges but should give you that comforting feeling he was looking for. On Thu, 1 Mar 2001 [EMAIL 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 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) 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 be anything you want and submit the form > > that resides on your site. This will basically submit totally > > fabricated data to the foriegn site and possibly screw them > > up somehow and/or in some way. > > > > 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? > > > No. There is no way to tell a clever programmer from a live human on > the other end of an Internet connection. You may be able to make it > harder, say making sure your form page is hit before the results are > returned, but that is easy to defeat. > > > > > > Rick Widmer > Internet Marketing Specialists > http://www.developersdesk.com > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > To contact the list administrators, e-mail: [EMAIL PROTECTED] > Kelly 303-444-1671 Boulder, Colorado -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP] Munging hidden/form variables
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 be faked quite easily if this person knows what (s)he doing. > > 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 be anything you want and submit the form > > that resides on your site. This will basically submit totally > > fabricated data to the foriegn site and possibly screw them > > up somehow and/or in some way. > > > > 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? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] Munging hidden/form variables
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) 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 be anything you want and submit the form > that resides on your site. This will basically submit totally > fabricated data to the foriegn site and possibly screw them > up somehow and/or in some way. > > 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? No. There is no way to tell a clever programmer from a live human on the other end of an Internet connection. You may be able to make it harder, say making sure your form page is hit before the results are returned, but that is easy to defeat. Rick Widmer Internet Marketing Specialists http://www.developersdesk.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP] Munging hidden/form variables
> 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)? Chris
[PHP] Munging hidden/form variables
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 be anything you want and submit the form that resides on your site. This will basically submit totally fabricated data to the foriegn site and possibly screw them up somehow and/or in some way. 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? Any help would be greatlyl appreciated. Chris
