One way I can think of is to have all dml pages (i.e. ???-2.tcl) check to see that it was called from its expected url.
Yeah, I think so...recently I added a page to acs-subsite/www/shared that will update a session property when referred by a link or "yes/no" confirmation page.
Check it out:
# acs-subsite/www/shared/session-update.tcl
ad_page_contract {
@author Don Baccus (dhogaza@pacifier.com)
@creation_date 2-Feb-2002
@param session_property The array which describes the new session
property. The required elements are package, key, value, and
referrer. The referrer element should be set [ad_conn url].
@param return_url The page to return to
Update the given session parameter with the given value and
redirect to the caller.
Note that a session property should never be used alone to drive
any action in the system. Always use permissions or an equivalent
check!
In order to reduce the potential for harm that might follow from
forgetting this principle the session_property array passed to this page
is signed and verified.
} {
session_property:array,verify
return_url
} -validate {
referrer_error {
if { ![string equal $session_property(referrer) [get_referrer]] } {
ad_complain "Expected referrer does not match actual referrer"
}
}
}
ad_set_client_property $session_property(package) $session_property(key) $session_property(value)
ad_returnredirect $return_url
Note that it checks to make sure the AOLserver referrer value matches the one signed and passed in (and it's only called internal to the toolkit). And other things are signed, too.
Now ... can one spoof referrer values in a way that breaks this?
We should make more use of signing/verification and checking that we're called from reasonable URLs.
Still, it's basically a client-side weakness. The fact that the user's machine can read things the user is allowed to read isn't the problem, the problem is that the hacker is allowed to send the resulting informatino back to themselves.
