I was looking at basic-info-update-2.tcl in acs 4.2 and it appears if you know a valid user_id you can change that users info. User_id is an input to the page and there is no check to see that it is either the logged in user or an admin.

I looked and the CVS head and I think the problem is mostly fixed by

ad_require_permission $user_id "write"

but it seems like there should also be a check to make sure that the user_id is in fact a user_id and not some other kind of id that user might have write access to.

Would it be usefull to have a page contract filter that could do this? It might also be nice to validate attributes. Perhaps

ad_page_contract {
} {
   {user_id:object.user ""}
   last_name:attribute.person.last_name
}

Barry -

I don't think this is a problem. The ad_require_permission *is* a check that the account doing the update has the right to make changes to the object specified by user_id (and if your system permission hierarchy isn't reflecting reality you've probably got bigger problems).

Although the user_id parameter could in theory be the object_id of something other than a user, the updates that are actually carried out (in the db_transaction block at the end of the file) are restricted to tables and attributes that are appropriate for "user" entities.

The only way I can see that this page could be used outside it's designed purpose would be to change the recorded email address of a group that the person doing the update has write but not admin access to (I'm assuming that changing the email address of a group normally requires admin access).

Well the current scheme assumes you know the type of what you're passing, and that you'll say "user_id:integer,notnull" when you write your page contract.  If you find pages not doing that, submit patches to your heart's content.

Using db attributes would add some additional security, relieving the programmer of some the burden, but the db hit would be too expense IMO ... I think ad_page_contract, properly used, is a reasonable compromise.