Jon,
I think the problem is that the javascript can execute anything in the context of the admin user, thus this script can first grab the page which creates the random value in the db. You have only made the attack slightly more difficult. The guy that broke the security of the sites above would probably not be detered by this, just add another half hour to write the javascript to extract the form variable.
The most secure solution is the AltaVista method. If Jonathan would provide the code, I would like to take a hack at a solution.
Also, the problem of passing object_id's around that are unused has a neat solution. The signed variable solution is not good, because although it validates the data, it still allows these values to be generated before they are used. I came up with a single page solution that prevents duplicate data from being inserted into the db, here it is:
# Test of uniqueness constraint
proc uniqueness_protection { input_value {property_name "form" } {module "up"} {error_message "Data Already Entered"} } {
set session_id [ad_conn -get session_id]
set sha_of_data [ns_sha1 $input_value]
set session_form_p [db_0or1row session_property_query "select property_value from sec_session_properties
where session_id = :session_id AND
module = :module AND
property_name = :property_name"]
if {$session_form_p && [string match $property_value $sha_of_data]} {
ad_return_complaint 1 $error_message
return -code return
}
# guess data is unique enough
if {$session_form_p} {
db_dml update_property_dml "update sec_session_properties
set property_value = :sha_of_data
where session_id = :session_id AND
module = :module AND
property_name = :property_name"
} else {
db_dml insert_property_dml "insert into sec_session_properties
(session_id,module,property_name,property_value) values
(:session_id,:module,:property_name,:sha_of_data)"
}
return
}
uniqueness_protection $package_name $property_name $module $error_message
