Forum OpenACS Q&A: Re: RFC: Security policy for OpenACS (Security hole in OpenACS 5.1!)

As for nonces, I do this on Carnage Blender--

confirmation page:
set security_key [ns_rand 1000000000]
nsv_set user_transfer_approval $user_id $security_key
# send $security_key with form

action page:
# read $security_key from form
catch {
    set t [nsv_get user_transfer_approval $user_id]
}
if {![info exists t] || $t != $security_key} {
    ad_return_error "Transfer not approved" "
    Go back and approve the transfer first.
    "
    return
}

I figure there's better odds than 1 in a billion that an attacker will find some security hole I haven't patched, so this is "secure enough" for me.

Anyway, if you limit this to POST (which I didn't think of), it seems to me you don't even need to bother with this, as long as you're having util_close_html_tags strip out FORM tags.  I'm reasonably sure you can't use javascript to POST w/o a FORM.  Certainly adding util_close_html_tags calls will be easier than adding code like mine here.  (Besides, it should be done anyway since users are stupid and don't, well, close their tags which is what that proc was originally for.)

This is a great solution, one I proposed for forms in general: pass some information along via nsv, which ties the form to the form processing script. I also recommend tying to a user session, which expires on a regular basis, but limiting to a certain user is a good first step.