Forum OpenACS Q&A: Securing form submissions

Collapse
1: Securing form submissions
Posted by Ravi Gadad on 12/21/00 03:18 PM
How do I ensure that the form submission to a script on my
server is coming from my server, and not from a form someone
else pieced together (in an attempt to hack my system)?  I
assume I need to check the referer information, but beyond that,
I'm not sure where to start.

Thanks!

Collapse
2: Response to Securing form submissions (response to 1)
Posted by Ben Adida on 12/21/00 04:28 PM
There is no way to figure that out unless you add significant
cryptographic tricks with unique form tokens and such (I don't
know anyone who has done that).

In general, you need to consider that every page on your web site
is a program with inputs that can be manipulated by a
mischievous individual. You *cannot* trust any of the inputs to
your web page. Thus, you must check that supposed integers
are indeed integers. You must ensure that you don't send the
user_id back and forth as a hidden form variable. Etc.... Every
input to your web page should be considered insecure.

Web security is hard....

Collapse
3: Response to Securing form submissions (response to 1)
Posted by carl garland on 12/22/00 04:47 PM
One approach could be generate an nsv id that would consist of a list containing the referer page and time created. Example on your form input page: <P>

set tag_id [nsv_incr . security_tag_id] <BR>
nsv_set form_security_tags $tag_id [list [ns_time] [ns_conn url]]<P>

Also send the tag_id in the form as a hidden variable

Then in your target page call a validify proc that would check for the existence of the tag_id form variable, the existence of the nsv array variable, and confirm that the referer matches up.
<P>
You time stamp in the nsv_array makes it easy to schedule a procedure to cycle through the array and flush out any values that you may wish to expire after a certain time period.

Collapse
4: Response to Securing form submissions (response to 1)
Posted by Ben Adida on 12/22/00 04:51 PM
Remember that the referer information is still sent by the client,
and thus cannot be trusted (unless you assume that a cracker
would *only* use a compliant browser to attack your system). If
someone is trying to crack your site, this approach will not fully
prevent them from doing so.
Collapse
5: Response to Securing form submissions (response to 1)
Posted by carl garland on 12/23/00 07:05 PM
Yes the referer can be faked but the tag id  that is generated on the server is the main part of the security. Since it is generated and exists only for a limited time and if you purge the id as soon as used in addition to frequent purging of all expired tags it will buy you a little more security than nothing.  This approach could also be extended for a simple double click protection.