Preventing saved web pages submitting data

[-__Brad__-]

Hi,

whilst someone was messing around with a simple site I built (literally just a guestbook thing using all the DW behaviours) they found something I hadn't really thought about.

They could save the web page with the form on, to their desktop. They could then use this saved form to submit data to the webserver.

This got me thinking. If I was to use hidden form elements to control the behaviour of the submitted data (for example, <input name="dataaction" value="add">), in theory someone could save the page, change the value to 'delete' and I don't really need to say any more!

So my question is this - what's the best way to make sure only pages served by the webserver can do anything (to disable pages being able to be saved and edited)? I guess this can also apply to URL tampering...

HTTP_REFERRER seems to be a little unreliable!

I'd rather know how to do this using DW behaviours or something, but if not then any solution will do.

I'm interested in solutions for ASP and PHP.

Thanks in advance.

[Newsgroup_User]

they shouldn't be able to download your whole page- just the html part.
Hence- No functionality.

-= Brad =- wrote:
> Hi,
>
> whilst someone was messing around with a simple site I built (literally just a
> guestbook thing using all the DW behaviours) they found something I hadn't
> really thought about.
>
> They could save the web page with the form on, to their desktop. They could
> then use this saved form to submit data to the webserver.
>
> This got me thinking. If I was to use hidden form elements to control the
> behaviour of the submitted data (for example, <input name="dataaction"
> value="add">), in theory someone could save the page, change the value to
> 'delete' and I don't really need to say any more!
>
> So my question is this - what's the best way to make sure only pages served by
> the webserver can do anything (to disable pages being able to be saved and
> edited)? I guess this can also apply to URL tampering...
>
> HTTP_REFERRER seems to be a little unreliable!
>
> I'd rather know how to do this using DW behaviours or something, but if not
> then any solution will do.
>
> I'm interested in solutions for ASP and PHP.
>
> Thanks in advance.
>

[-__Brad__-]

quote:

---

Originally posted by: Newsgroup User
they shouldn't be able to download your whole page- just the html part.
Hence- No functionality.

---

Hi,

yes they can only download the HTML (including the form) but with a slight tweak to the action parameter (say change in from action="result.php" to action=" http://website/result.php") they can still submit the form to the page that performs the action on the submitted form.

That's what I'm trying to understand - how to get result.php to say "this hasn't come from the web server so I'm ignoring it".

[Newsgroup_User]

New Guy wrote:
> they shouldn't be able to download your whole page- just the html part.
> Hence- No functionality.

Not true. All that the attacker needs to do is to change the value of
the action attribute to the URL, and the form data will be accepted.

Using a hidden field that would permit anyone to change the SQL query
from from INSERT to DELETE is simply asking for trouble. Permission to
delete should be restricted to registered users on a password-protected
part of the site.

--
David Powers, Adobe Community Expert
Author, "Foundation PHP for Dreamweaver 8" (friends of ED)
Author, "PHP Solutions" (friends of ED)
http://foundationphp.com/

[-__Brad__-]

quote:

---

Originally posted by: Newsgroup User
New Guy wrote:
> they shouldn't be able to download your whole page- just the html part.
> Hence- No functionality.

Not true. All that the attacker needs to do is to change the value of
the action attribute to the URL, and the form data will be accepted.

Using a hidden field that would permit anyone to change the SQL query
from from INSERT to DELETE is simply asking for trouble. Permission to
delete should be restricted to registered users on a password-protected
part of the site.

--
David Powers, Adobe Community Expert
Author, "Foundation PHP for Dreamweaver 8" (friends of ED)
Author, "PHP Solutions" (friends of ED)
http://foundationphp.com/

---

David,

I agree with the permissions thing and I think for the most part what I'm thinking about is probably redundant.

I guess this is more of an exercise to see if there's a way to make sure form submissions only come from the "correct" place as a means of adding extra security.

Thinking about the original example I gave, using hidden form fields to change the query type is not really an issue as a) all query types would only execute depending upon user credentials (login, user level, session, etc), and b) I tend to use different database connections depending upon the userlevel and query type.

But I do still have an interest in resolving how to make sure forms only "work" when submitted from a certain place.

Cheers,
- B

[Newsgroup_User]

-= Brad =- wrote:
> But I do still have an interest in resolving how to make sure forms only
> "work" when submitted from a certain place.

The method suggested by Gareth is one that I have often heard of,
although in a slightly different form. It involves generating a random
token, which is saved both as a hidden field and as a session variable.
If the two don't match when the form is submitted, reject the form.

--
David Powers, Adobe Community Expert
Author, "Foundation PHP for Dreamweaver 8" (friends of ED)
Author, "PHP Solutions" (friends of ED)
http://foundationphp.com/

[Newsgroup_User]

One solution to this, used by the banks for ecommerce is to create a hash
value of the hidden fields, using a secret key.

On the server, you run the hidden fields through the hash function, and put
the value returned in the hidden fields as well.

When the page is submitted to the server, the hidden fields are again run
through the hash function, and the value is compared to the hash value in
the hidden field on the form.

If the two hash values differ, then you know the fields have been tampered
with, and can reject the data.

This is used often on ecommerce sites, as the order total, or product price
is usually included as a hidden field. Without the hash check, people could
order from the website, but save the checkout page, alter the order value,
and then submit the page themselves. If the merchant isn't vigilant and
doesn't check every order, you can buy the goods for a fraction of the
value. I have actually seen this been done in real life (although not on
sites I`ve created 🙂 ).

--
Gareth
http://www.phploginsuite.co.uk/
PHP Login Suite V2 - 34 Server Behaviors to build a complete Login system.